Stručně: Bezpečnost Symfony po PHP2Shell znamená: záplatovat PHP, restartovat všechny procesy včetně workerů Messengeru a poté zkontrolovat secrets, cache a profiler. Zranitelnost je v PHP, ne v Symfony; samotná aktualizace Symfony ji neuzavře.
Proč PHP2Shell zasahuje každý projekt Symfony
Symfony je základem mnoha podnikových aplikací, API a portálů a je navíc součástí systémů jako Shopware 6 a Contao. Zranitelnosti PHP CVE-2026-109618 a CVE-2026-109619 umožňují podle týmu PHP spuštění škodlivého kódu bez přihlášení. Zda je aplikace čistě naprogramovaná, přitom nehraje roli.
Tým PHP hodnotí riziko u mod_php jako nejvyšší, postiženy jsou ale i PHP-FPM, php-cgi, FrankenPHP a LiteSpeed. Projekty Symfony provozované přes Symfony Runtime s FrankenPHP nebo jinými trvale běžícími servery potřebují po aktualizaci úplný restart nebo nový image.
Bezpečnost Symfony: kontrola verze PHP a procesů
php bin/console about zobrazuje verzi Symfony, prostředí, režim ladění a verzi PHP příkazové řádky. Webové požadavky ale běží přes PHP-FPM nebo aplikační server, a to může být jiná verze. Zkontrolujte obě cesty nebo si je nechte potvrdit provozovatelem.
Opravené verze upstreamu jsou 8.5.12, 8.4.27, 8.3.36 a 8.2.35; backporty distribucí často nesou starší čísla. Které verze PHP vaše verze Symfony podporuje, ověříte podle systémových požadavků v dokumentaci na symfony.com.
# Zobrazit prostředí, režim ladění a verzi PHP
php bin/console about
# Nechat workery Messengeru ukončit po aktuální zprávě
php bin/console messenger:stop-workers
# Známé zranitelnosti v závislostech
composer audit
Pokud běží více instancí za load balancerem nebo v kontejnerech, musí být každá jednotlivá záplatována a restartována. Zapomenutá instance dál obsluhuje část požadavků se starým PHP.
Workery Messengeru, příkazy cron a další procesy na pozadí načítají PHP jednou při startu. Dokud se nerestartují, běží se starým PHP v paměti. Správce procesů je musí po zastavení znovu spustit.
Kde jsou aplikace Symfony napadnutelné
| Místo | Obsah | Bod kontroly |
|---|---|---|
.env, .env.local, .env.local.php |
Proměnné prostředí, často databáze a klíče API | Nesmí být dostupné z webrootu, hodnoty při podezření obnovit |
config/secrets/prod/ |
Šifrované secrets | Soukromý dešifrovací klíč nepatří do repozitáře |
public/ |
Kořen dokumentů s index.php |
Další soubory PHP |
var/cache/prod/ |
Vygenerovaný kontejner a šablony jako PHP | Při podezření smazat a vytvořit znovu |
var/log/ |
Protokoly | Zálohovat |
config/packages/security.yaml |
Firewally, role, pravidla přístupu | Neočekávané změny |
Cache je podceňovaný úkryt. Symfony tam vytváří soubory PHP, které se načítají při každém požadavku. Změna těchto souborů se v repozitáři neprojeví, protože cache není verzována.
V produkci patří APP_ENV=prod a APP_DEBUG=0 a WebProfilerBundle tam nesmí být aktivní. Veřejně dostupný profiler na adrese /_profiler prozrazuje konfiguraci a data požadavků.
Administrační oblasti, bundly a závislosti
Projekty Symfony mají podle architektury vlastní administrační oblasti, často s bundly jako EasyAdmin nebo Sonata. V security.yaml zkontrolujte, které cesty vyžadují které role, a v databázi, kdo tyto role má. Administrační cesty, které se používají jen interně, by měly být na úrovni webového serveru omezeny na známé sítě.
Bundly a balíčky Composeru jsou cizí kód s vlastními zranitelnostmi. composer audit ukazuje známé problémy; podrobněji v článku Kontrola zranitelností v závislostech Composeru. Zastaralé balíčky jsou navíc nejčastějším důvodem, proč upgrade PHP u projektů Symfony trvá déle, než se plánovalo.
Co aktualizace Symfony zvládne a co ne
Aktualizace komponent Symfony uzavře chyby ve frameworku. Nezáplatuje PHP, nerestartuje workery, neobnoví uniklé secrets a neodstraní zmanipulovanou cache. Zda existují známky útoku, popisuje článek Jsem už kompromitován?. Protože neexistují potvrzené indikátory kompromitace (IoC), pomáhá hlavně sledování neobvyklého chování, například neočekávaných procesů nebo odchozích spojení.
Pokud se projekt dodává jako kontejner, patří nové PHP do základního image. Sestavte image znovu, i když se na kódu nic nezměnilo, a nasaďte jej do všech prostředí. Pohled do Dockerfile ukáže, jaký základní image se používá; pevně nastavený starý tag jinak brání tomu, aby nové sestavení záplatované PHP vůbec dostalo. Podrobnosti najdete v článku Záplatování PHP v kontejnerech Docker.
Jak konkrétně pomáhá PHP SOS?
- Zjistíme, které PHP používá web, CLI a workery vašeho projektu Symfony, a provedeme vás uspořádaným restartem.
- Zálohujeme logy od 20. 10. 2026 a porovnáme kód na serveru s vaším repozitářem.
- Kontrolujeme soubory prostředí, secrets, cache, nastavení profileru a administrační role.
- Pro průběžné sledování procesů a spojení nabízíme bezpečnostní monitoring.
Časté dotazy
Týká se PHP2Shell Symfony?
Symfony samo žádnou novou zranitelnost nemá. PHP2Shell je v PHP, tedy v běhovém prostředí každé aplikace Symfony. Zranitelnost se uzavře aktualizací PHP nebo potvrzeným backportem a restartem všech procesů PHP.
Jak po aktualizaci PHP zastavím workery Messengeru?
Příkazem php bin/console messenger:stop-workers dostanou běžící workery pokyn, aby se po aktuální zprávě ukončili. Správce procesů, například Supervisor nebo systemd, je pak znovu spustí s novým PHP.
Proč je profiler Symfony v produkci nebezpečný?
Profiler zobrazuje požadavky, konfiguraci a často i proměnné prostředí. Je-li aktivní na veřejném serveru, může tyto informace vyvolat kdokoli. Patří jen do vývojového prostředí.
Co se děje s cache po útoku?
Cache v adresáři var/cache obsahuje vygenerovaný kód PHP. Útočník tam může uložit kód, který se spouští při každém požadavku. Po podezření by se cache měla smazat a znovu vytvořit z prověřeného zdrojového kódu.