Stručně: Zranitelnost Laravelu, kterou nyní hledá mnoho vývojářů, je PHP2Shell a je v samotném PHP. Aktualizace Laravelu ji neuzavře. Důležité jsou záplatované PHP, restart všech procesů včetně queue workerů a Octane a kontrola .env, storage a public.
Co PHP2Shell znamená pro aplikace Laravel
Laravel je základem mnoha vlastních vývojů: zákaznických portálů, interních nástrojů, rezervačních systémů, API pro aplikace. Zranitelnosti PHP CVE-2026-109618 a CVE-2026-109619 umožňují podle týmu PHP spuštění škodlivého kódu na dálku bez přihlášení. Jak čistý je kód Laravelu, přitom nehraje roli.
Postiženy jsou provozní režimy PHP-FPM, Apache s mod_php, php-cgi, FrankenPHP a LiteSpeed. Laravel Octane může jako server používat FrankenPHP; pak je PHP součástí programu FrankenPHP nebo image kontejneru a aktualizuje se s ním. Jak to vypadá u FrankenPHP, popisuje článek Zabezpečení FrankenPHP.
Zranitelnost Laravelu: kontrola verze PHP a procesů
Na příkazové řádce zobrazuje php artisan about verzi PHP, verzi Laravelu a důležitá nastavení, jako je prostředí a režim ladění. To je ovšem verze CLI PHP. Webové požadavky zpracovává PHP-FPM nebo Octane, a to může být jiná verze. V případě pochybností nechte provozovatele potvrdit, jaký stav balíčků běží na všech cestách.
Opravené verze upstreamu jsou 8.5.12, 8.4.27, 8.3.36 a 8.2.35, backporty mohou nést starší čísla. Které verze PHP vaše verze Laravelu podporuje, ověříte podle systémových požadavků v dokumentaci na laravel.com.
Po aktualizaci přichází část, na kterou se u Laravelu nejčastěji zapomíná: dlouho žijící procesy.
# Zobrazit verze a konfiguraci
php artisan about
# Dát queue workerům pokyn, aby se po aktuální úloze ukončili
php artisan queue:restart
# Ukončit Horizon, aby jej správce procesů znovu spustil
php artisan horizon:terminate
Workery se poté znovu spustí jen tehdy, pokud je hlídá správce procesů, například Supervisor nebo systemd. Servery Octane a kontejnery se musí úplně restartovat, resp. nasadit s novým image. Pro nastavení s kontejnery platí Záplatování PHP v kontejnerech Docker.
Kde jsou aplikace Laravel zranitelné
| Místo | Obsah | Bod kontroly |
|---|---|---|
.env |
APP_KEY, databáze, pošta, klíče API |
nikdy nesmí být dostupný přes web |
bootstrap/cache/config.php |
Konfigurace v cache s tajnými údaji | Práva, datum změny |
public/ |
Kořen dokumentů s index.php |
Další soubory PHP |
storage/app/public |
Nahrávky, dostupné přes public/storage |
Žádné soubory PHP |
storage/logs/ |
laravel.log, často s daty požadavků |
Zálohovat, nesmí být veřejný |
vendor/ |
Balíčky Composeru | composer audit, porovnání s composer.lock |
Složka storage/app/public je dostupná přes symbolický odkaz pod public/storage. Soubor PHP tam uložený může být podle konfigurace serveru přímo spuštěn. Zablokujte to na úrovni webového serveru.
APP_DEBUG musí být v produkci nastaveno na false. Chybová stránka s ladicím výstupem může ukázat proměnné prostředí, cesty a části kódu a každému útočníkovi usnadňuje práci.
Administrační rozhraní a balíčky jako riziko
Aplikace Laravel nemají jednotné administrační rozhraní. Často jsou to vlastní oblasti nebo balíčky jako Filament či Nova. Zkontrolujte, kdo má práva administrátora, zda má přihlášení dvoufázovou úroveň a zda musí být administrační trasy dostupné zvenčí. Také tokeny API, například ze Sanctum nebo Passport, by se po podezření měly odvolat a vydat znovu.
Zkontrolujte rovněž, zda nejsou v produkci dostupné nástroje z vývoje, například ladicí lišty, Telescope nebo testovací trasy. Často zobrazují požadavky, dotazy a konfiguraci a patří za přihlášení, nebo úplně pryč z produkčního prostředí.
Balíčky Composeru jsou druhým velkým blokem. Každá závislost přináší vlastní kód a balíčky bez péče později blokují upgrady PHP. composer audit ukazuje známé zranitelnosti, ale nenahrazuje kontrolu vlastního kódu.
Co aktualizace Laravelu zvládne a co ne
Aktualizace Laravelu nebo jednotlivých balíčků uzavře známé chyby v tomto kódu. Nezáplatuje PHP, nerestartuje workery, neobnoví uniklý APP_KEY a neodstraní soubory ze storage nebo public. Zda se před záplatou něco stalo, lze zjistit jen kontrolou logů, souborů a databáze.
Pro týmy s pipeline pro nasazování platí: aktualizace PHP patří i do sestavovacího prostředí a do základních image, jinak další nasazení opět přinese starou verzi. Zkontrolujte také, zda nejsou veřejně dostupná stagingová nebo review prostředí. Často běží s APP_DEBUG=true a skutečnými daty a při bezpečnostních aktualizacích se snadno přehlédnou.
Jak konkrétně pomáhá PHP SOS?
- Kontrolujeme webové, CLI i worker PHP vaší aplikace Laravel a provedeme vás uspořádaným restartem všech procesů.
- Zálohujeme logy od 20. 10. 2026, databázi a stav kódu a porovnáme jej s vaším repozitářem.
- Kontrolujeme
.env, cache konfigurace,storage,public, účty správců a tokeny API. - Pro hlubší kontrolu vlastního kódu zprostředkujeme bezpečnostní audit nebo penetrační test prostřednictvím specializovaných partnerů.
Časté dotazy
Musím kvůli PHP2Shell aktualizovat Laravel?
Aktualizace Laravelu PHP2Shell neuzavře, protože zranitelnost je v interpretu PHP. Laravel přesto udržujte aktuální. Pro PHP2Shell potřebujete záplatované PHP a restart všech procesů PHP, včetně workerů.
Proč u Laravelu často nestačí restart PHP-FPM?
Queue workery, Horizon, Octane a scheduler běží jako samostatné procesy PHP z příkazové řádky. PHP načtou jednou při startu a dál pracují se starou verzí v paměti, dokud se nerestartují.
Co dělat, když mohl soubor .env uniknout?
Pak byste měli obnovit APP_KEY, heslo k databázi a všechny klíče k externím službám. Berte na vědomí, že nový APP_KEY ukončí stávající relace a data zašifrovaná starým klíčem už nepůjde přečíst; naplánujte to se svými vývojáři.