Stručně: Virtuální záplatování PHP překlenuje dobu, než bude nasazena skutečná aktualizace. Spojujeme k tomu pravidla Web Application Firewall s přechodnými opatřeními, která php.net k PHP2Shell zveřejnil, a rovnou stanovíme cestu k řádné záplatě. Úplnou ochranu to neposkytuje, ale v přechodné době to snižuje riziko.
Kdy má virtuální záplatování PHP smysl
BSI (německý Spolkový úřad pro informační bezpečnost) u PHP2Shell doporučuje okamžitou aktualizaci a, pokud ta nejde, webové servery dočasně odpojit od sítě. Pro mnoho firem není ani jedno okamžitě proveditelné: e-shop musí zůstat dostupný, vlastní vývoj potřebuje před aktualizací test, nebo server běží na PHP 8.1 či starším, pro které už neexistují oficiální aktualizace.
V těchto případech je virtuální záplatování most. Nenahrazuje rozhodnutí, zda by nebyl vhodnější provoz offline. Toto zvážení děláte vy, my dodáváme technické posouzení.
Proč samotná WAF nestačí
Cloudflare hlásil pozorované pokusy o útok a nasadil ochranná pravidla, ale upozorňuje, že pravidla jen podle dat požadavku nestačí. Důvod je v povaze zranitelností. U CVE-2026-109618 může stav nedostatku paměti (out of memory) přerušit PHP ve chvíli, kdy jsou data požadavku inicializována jen částečně. U CVE-2026-109619 může po uvolnění paměti zůstat vnitřní stav, který využije pozdější požadavek ve stejném workeru. Takové chyby závisejí na stavu serveru, ne jen na obsahu jednotlivého požadavku.
Proto sázíme na více vrstev: pravidla WAF před serverem, přechodná opatření přímo v PHP a zvýšené sledování serveru. Každá vrstva zachytí část, žádná sama nestačí. Dohromady vám dají čas, abyste aktualizaci nasadili uspořádaně.
Přechodná opatření podle php.net
php.net uvádí několik nastavení, která snižují riziko, výslovně bez úplné ochrany. Důležité je, aby aplikace tyto hodnoty nemohly přepsat. Příklad pro pool PHP-FPM s nahráváním souborů:
; Přechodná opatření PHP2Shell (není úplná ochrana), poté restartovat všechny workery
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 32M
php_admin_value[upload_max_filesize] = 30M
php_admin_flag[session.upload_progress.enabled] = off
; jen PHP 8.5:
php_admin_flag[fatal_error_backtraces] = off
Bez nahrávání souborů php.net doporučuje post_max_size = 8M. Protože se memory_limit ruší, patří k tomu limit paměti na úrovni kontejneru nebo cgroup, ne přes RLIMIT_AS nebo RLIMIT_DATA. Nastavení session.upload_progress.enabled=0 patří do php.ini, poolu FPM nebo konfigurace serveru, ne do ini_set() ani .user.ini. Zároveň je to náprava upozornění k CVE-2026-115560. Přehled všech opatření najdete na stránce Okamžitá opatření, když zatím nelze záplatovat.
Přechodná opatření začnou působit až po restartu všech workerů PHP. A chrání jen před budoucími útoky: zda se někdo dostal dovnitř už dříve, nezodpoví.
Kdy je provoz offline lepší volbou
Virtuální záplatování není v každé situaci správnou odpovědí. U některých konstelací radíme řídit se doporučením BSI a webový server dočasně odpojit od sítě, dokud nebude záplatován:
- server běží s Apache a mod_php, kde tým PHP hodnotí riziko jako nejvyšší a exploit byl předveden ještě předtím, než se vůbec spustí kód aplikace
- na serveru jsou zvlášť chráněná data, například zdravotní údaje, údaje klientů nebo platební údaje
- neexistuje možnost přechodná opatření pevně nastavit v konfiguraci serveru, například u některých balíčků sdíleného hostingu
- už existují známky, že byl server napaden
Dočasný provoz offline neznamená, že byl váš web napaden. Někteří poskytovatelé weby z opatrnosti odpojili. Krátká, věcná informační stránka pro návštěvníky je pak většinou lepším řešením než nevysvětlený výpadek.
Jak konkrétně pomáhá PHP SOS?
- Kontrola situace: Zjistíme verze PHP, provozní režimy a existující ochranné vrstvy, jako jsou CDN, WAF nebo reverzní proxy. U mod_php upozorníme na zvýšené riziko, které tam tým PHP vidí.
- Vybudování vrstev: Aktivujeme nebo doplníme pravidla WAF, nastavíme přechodná opatření pevně v konfiguraci serveru a omezíme paměť přes kontejner nebo cgroup. U nastavení s Nginx vycházíme ze stránky Zabezpečení Nginx s PHP-FPM.
- Restart a test: Všechny procesy PHP se restartují, poté zkontrolujeme nahrávání souborů, formuláře, přihlášení a pokladnu.
- Sledování: V přechodné době dáváme zvýšený pozor na zhroucení workerů, špičky paměti a neobvyklé procesy.
- Naplánování záplaty: Stanovíme, kdy a jak přijde řádná aktualizace, a provedeme ji prostřednictvím služby záplatování PHP.
Co získáte, co potřebujeme a co neslibujeme
Získáte dokumentaci všech nastavených pravidel a nastavení s odůvodněním, výsledky testů a plán termínů a opatření pro skutečnou záplatu. Od vás potřebujeme přístup k serveru nebo panelu, přístup k CDN nebo WAF, pokud existuje, technickou kontaktní osobu a údaje o funkcích nahrávání ve vašich aplikacích.
Neslibujeme, že virtuální záplatování útoku zabrání. Snižuje riziko na omezenou dobu. U PHP 8.1 a starší nejde o trvalý stav; do plánu zde patří migrace na podporovanou verzi.
Časté dotazy
Co je virtuální záplatování?
Virtuální záplatování znamená odstínit známou zranitelnost před aplikací, místo aby se měnil samotný kód. Většinou k tomu slouží Web Application Firewall nebo změny konfigurace. Je to překlenutí, ne náhrada aktualizace.
Stačí proti PHP2Shell WAF od mého poskytovatele CDN?
Samotná zpravidla ne. Cloudflare nasadil ochranná pravidla, sám ale upozorňuje, že pravidla jen podle dat požadavku nestačí. WAF je dodatečná vrstva vedle přechodných opatření a záplaty.
Jak dlouho se smím spoléhat na virtuální záplatování?
Co nejkratší dobu. Má překlenout čas do řádné aktualizace, například do uvolnění servisního okna nebo do otestování aplikace. U PHP 8.1 a starší k tomu patří plán migrace.
Mohou přechodná opatření můj web narušit?
Ano, je to možné. Menší limity pro nahrávání mohou zabránit nahrávání velkých souborů a vypnutí session upload progress se týká ukazatelů průběhu při nahrávání. Po každé změně otestujeme nejdůležitější funkce.