Stručne: Zraniteľnosť Laravel, ktorú teraz hľadá veľa vývojárov, je PHP2Shell a je v samotnom PHP. Aktualizácia Laravel ju neuzatvorí. Dôležité sú záplatované PHP, reštart všetkých procesov vrátane queue workerov a Octane a kontrola .env, storage a public.
Čo PHP2Shell znamená pre aplikácie Laravel
Laravel je základom mnohých vlastných vývojov: zákaznícke portály, interné nástroje, rezervačné systémy, API pre aplikácie. Zraniteľnosti PHP CVE-2026-109618 a CVE-2026-109619 podľa tímu PHP umožňujú spustenie škodlivého kódu na diaľku bez prihlásenia. Aký čistý je kód Laravel, na tom nezáleží.
Dotknuté sú režimy prevádzky PHP-FPM, Apache s mod_php, php-cgi, FrankenPHP a LiteSpeed. Laravel Octane môže ako server používať FrankenPHP; PHP je potom súčasťou programu FrankenPHP alebo obrazu kontajnera a aktualizuje sa spolu s ním. Ako to vyzerá pri FrankenPHP, popisuje stránka Zabezpečiť FrankenPHP.
Zraniteľnosť Laravel: skontrolovať verziu PHP a procesy
V príkazovom riadku zobrazuje php artisan about verziu PHP, verziu Laravel a dôležité nastavenia, ako je prostredie a režim ladenia. Je to však verzia CLI PHP. Webové požiadavky vybavuje PHP-FPM alebo Octane a to môže byť iná verzia. Pri pochybnostiach si nechajte od prevádzkovateľa potvrdiť, aký stav balíkov beží na všetkých cestách.
Opravené upstream verzie sú 8.5.12, 8.4.27, 8.3.36 a 8.2.35, backporty môžu niesť staršie čísla. Ktoré verzie PHP vaša verzia Laravel podporuje, skontrolujte podľa systémových požiadaviek v dokumentácii na laravel.com.
Po aktualizácii prichádza časť, na ktorú sa pri Laravel najčastejšie zabúda: dlhodobo bežiace procesy.
# Zobraziť verzie a konfiguráciu
php artisan about
# Nariadiť queue workerom, aby sa po aktuálnej úlohe ukončili
php artisan queue:restart
# Ukončiť Horizon, aby ho správca procesov znovu spustil
php artisan horizon:terminate
Workery sa potom reštartujú len vtedy, ak ich sleduje správca procesov, ako je Supervisor alebo systemd. Servery Octane a kontajnery sa musia úplne reštartovať, resp. nasadiť s novým obrazom. Pre nastavenia s kontajnermi platí Záplatovanie PHP v kontajneroch Docker.
Kde sú aplikácie Laravel zraniteľné
| Miesto | Obsah | Bod kontroly |
|---|---|---|
.env |
APP_KEY, databáza, pošta, kľúče API |
Nikdy nesmie byť dostupný cez web |
bootstrap/cache/config.php |
Konfigurácia v cache s tajnými údajmi | Práva, dátum zmeny |
public/ |
Koreň dokumentov s index.php |
Ďalšie súbory PHP |
storage/app/public |
Nahrávky, dostupné cez public/storage |
Žiadne súbory PHP |
storage/logs/ |
laravel.log, často s údajmi požiadaviek |
Zálohovať, nie verejne |
vendor/ |
Balíky Composeru | composer audit, porovnanie s composer.lock |
Priečinok storage/app/public je dostupný cez symbolický odkaz pod public/storage. Súbor PHP uložený tam sa môže podľa konfigurácie servera vykonať priamo. Zablokujte to na úrovni webového servera.
APP_DEBUG musí byť v produkcii nastavený na false. Chybová stránka s ladiacim výstupom môže ukázať premenné prostredia, cesty a časti kódu a každému útočníkovi uľahčuje prácu.
Administračné rozhrania a balíky ako riziko
Aplikácie Laravel nemajú jednotné administračné rozhranie. Často ide o vlastné oblasti alebo balíky, ako sú Filament alebo Nova. Skontrolujte, kto má práva admina, či prihlásenie má dvojfaktorový stupeň a či musia byť administračné trasy dostupné zvonku. Aj tokeny API, napríklad zo Sanctum alebo Passport, by sa mali pri podozrení zrušiť a vydať nanovo.
Skontrolujte tiež, či sú v produkcii dostupné nástroje z vývoja, ako ladiace lišty, Telescope alebo testovacie trasy. Často ukazujú požiadavky, dotazy a konfiguráciu a patria za prihlásenie alebo úplne preč z produkčného prostredia.
Balíky Composeru sú druhým veľkým blokom. Každá závislosť prináša vlastný kód a balíky bez údržby neskôr blokujú aktualizácie PHP. composer audit zobrazuje známe zraniteľnosti, nenahrádza však kontrolu vlastného kódu.
Čo aktualizácia Laravel dokáže a čo nie
Aktualizácia Laravel alebo jednotlivých balíkov uzatvára známe chyby v tomto kóde. PHP nezáplatuje, nereštartuje workery, neobnoví uniknutý APP_KEY a neodstráni súbory zo storage alebo public. Či sa pred záplatou niečo stalo, dá sa vyjasniť iba kontrolou logov, súborov a databázy.
Pre tímy s deployment pipeline platí: aktualizácia PHP patrí aj do build prostredia a do základných obrazov, inak ďalší deployment opäť prinesie starú verziu. Skontrolujte navyše, či sú staging alebo review prostredia verejne dostupné. Často bežia s APP_DEBUG=true a skutočnými údajmi a pri bezpečnostných aktualizáciách sa ľahko prehliadnu.
Ako konkrétne pomáha PHP SOS?
- Kontrolujeme webové, CLI a worker PHP vašej aplikácie Laravel a sprevádzame usporiadaný reštart všetkých procesov.
- Zálohujeme logy od 20. 10. 2026, databázu a stav kódu a porovnávame ho s vaším repozitárom.
- Kontrolujeme
.env, cache konfigurácie,storage,public, admin účty a tokeny API. - Pre hlbšiu kontrolu vlastného kódu sprostredkujeme bezpečnostný audit alebo penetračný test cez špecializovaných partnerov.
Časté otázky
Musím kvôli PHP2Shell aktualizovať Laravel?
Aktualizácia Laravel PHP2Shell neuzatvorí, pretože zraniteľnosť je v interpreteri PHP. Laravel napriek tomu udržiavajte aktuálny. Pre PHP2Shell potrebujete záplatované PHP a reštart všetkých procesov PHP, aj workerov.
Prečo pri Laravel často nestačí reštart PHP-FPM?
Queue workery, Horizon, Octane a plánovač bežia ako samostatné procesy PHP cez príkazový riadok. PHP načítajú raz pri štarte a potom pracujú so starou verziou v pamäti, kým sa nereštartujú.
Čo robiť, ak mohol uniknúť súbor .env?
Potom by ste mali obnoviť APP_KEY, heslo databázy a všetky kľúče k externým službám. Majte na pamäti, že nový APP_KEY ukončí existujúce relácie a údaje zašifrované starým kľúčom už nebude možné prečítať; naplánujte to so svojimi vývojármi.