Zranitelnost PHP2Shell a jak ji zablokovat

Co je PHP2Shell

„PHP2Shell" je jméno, které se uchytilo u dvojice zranitelností v jádru PHP, zveřejněných 21. října 2026 a vedených jako CVE-2026-109618 a CVE-2026-109619. Obě jsou hodnocené jako kritické (CVSS 9.2), obě jsou neautentizované a obě vedou ke vzdálenému spuštění kódu — útočník, který dokáže poslat HTTP požadavek na zranitelný web, může bez přihlášení a bez interakce uživatele spustit na vašem serveru vlastní kód. To je nejhorší třída webové zranitelnosti, jaká existuje, a proto si vysloužila přezdívku.

Chyba je v samotném PHP, ne ve WordPressu, Laravelu, šabloně nebo pluginu. V ohrožení je cokoli, co běží na PHP a přijímá odeslání formuláře. Zasažené verze sahají od PHP 5.4 až po 8.5.11, což je prakticky každé nasazení PHP na internetu, které od zveřejnění nedostalo záplatu. Opravená vydání jsou 8.2.35, 8.3.36, 8.4.27 a 8.5.12 — pokud běžíte na starší řadě 5.x, 7.x nebo rané 8.x bez backportu, jste zranitelní, dokud neupgradujete.

Jak exploit funguje

Zranitelný kód je vestavěný obslužný kód PHP pro multipart/form-data — formát, který každý prohlížeč používá k odeslání formuláře s nahráním souboru, definovaný v RFC 1867. Tentýž parser zpracovává i běžná URL-kódovaná těla formulářů.

CVE-2026-109618 funguje takto: útočník pošle požadavek, jehož tělo je záměrně upravené tak, aby parser formulářů alokoval víc paměti, než proces smí, takže alokace uprostřed zpracování selže. PHP se pak pokusí uklidit požadavek, který sestavovalo — jenže ten je jen napůl inicializovaný a úklid uvolní a sáhne na paměť, která nikdy nebyla plně nastavená. To poškození je opora. Při dostatečně pečlivě tvarovaném těle útočník nasměruje poškozenou paměť ke spuštění kódu podle své volby.

CVE-2026-109619 je doprovodná chyba: use-after-free v mechanismu session a upload-progress, kde se stav zbylý po jednom požadavku znovu použije při pozdějším požadavku na témž worker procesu. Dlouho žijící worker PHP-FPM obsluhuje požadavek za požadavkem; pokud po sobě jeden z nich nechá visící odkaz, další o něj zakopne.

Detail, který tohle dělá v praxi nebezpečným, je ten, co poráží zřejmou obranu. Škodlivé tělo zůstává pod běžným limitem post_max_size — výchozích 8 MiB. Útok nefunguje tím, že pošle obří požadavek; funguje tím, že pošle strukturálně extrémní požadavek. První instinkt — „prostě omezím, jak velký smí POST být" — tedy nic nezmůže, protože exploit si uvnitř toho limitu už beztak žil.

Proč je to těžké pro běžný WAF

Většina pravidel webového aplikačního firewallu hledá řetězec: SQL klíčové slovo, značku <script>, cestu jako /etc/passwd. PHP2Shell žádný takový řetězec nemá. Exploit je tvar a přichází ve dvou podobách, přičemž v jednom požadavku se může objevit kterákoli nebo obě:

• Záplava částí s prázdným jménem souboru. Legitimní multipart formulář má hrstku částí. Exploit pošle stovky částí, každou s deklarací filename="" — prázdným jménem souboru. Každá taková část nutí parser nastavit a zbořit slot pro nahrávání a právě tahle zátěž pohání vyčerpání paměti.
• Patologicky hluboké zanoření polí. PHP umožňuje, aby pole formuláře popisovala jménem pole typu array — user[address][city]. Exploit to zneužije názvy zanořenými absurdně hluboko — name="f[a][b][c][d][e]..." opakované daleko za cokoli, co skutečný formulář použije — a nutí parser sestavit hluboko zanořenou strukturu.

Ani jedno z toho není payload, na který se dá napsat signatura. Počet částí i hloubka zanoření se útok od útoku liší a není tu žádná magická sekvence bajtů, na kterou by šlo přišpendlit regex. Přesně proto je vlastní doporučení AWS k této zranitelnosti výslovné v tom, že se obránci nemají spoléhat na signaturu konkrétního CVE — pravidlo na jediný řetězec se triviálně obejde změnou výplně. Obrana musí počítat a měřit strukturu požadavku, ne skenovat jeho bajty.

Jak ochránit PHP web

Na pořadí tu záleží, protože jen první bod skutečně zranitelnost odstraní.

1. Záplatujte PHP. To je jediná úplná oprava. Upgradujte na 8.2.35, 8.3.36, 8.4.27 nebo 8.5.12 (nebo ekvivalent s backportem od vaší distribuce). Všechno ostatní na tomto seznamu vám kupuje čas; jen záplata díru zavře.

2. Jako dočasné opatření utáhněte parser formulářů. V php.ini snižte post_max_size k tomu, co vaše formuláře opravdu potřebují, snižte max_input_nesting_level (výchozích 64 je mnohem hlouběji než jakýkoli reálný formulář), omezte max_input_vars a vypněte session.upload_progress, pokud ho nepoužíváte — to je povrch pro CVE-2026-109619. Chybu to neopraví, ale zmenší to prostor, který exploit má.

3. Vynucujte strukturální limity na edge. Před originem odmítejte požadavky, které jsou strukturálně abnormální: příliš mnoho multipart částí, názvy polí zanořené za rozumnou hloubku, nesmyslný počet vstupů nebo dekódovaná velikost, která přeroste tu syrovou. Zásadní je, že tohle musí fungovat i na chunked / bezdélkových požadavcích, protože útočník, který vynechá Content-Length, obejde jakoukoli kontrolu, která čte jen deklarovanou velikost.

4. Blokujte multipart tam, kde nikdy nepřijímáte nahrávání. Většina endpointů — přihlašovací formulář, API, vyhledávací pole — nemá důvod přijímat multipart/form-data vůbec. Jeho odmítnutí tam úplně odstraní povrch útoku pro tyto cesty.

Rozdíl mezi tímhle druhem obrany podle tvaru požadavku a objemovou mitigací rozebírá WAF vs DDoS ochrana. Tentýž edge, který počítá strukturu formuláře, vynucuje i rate limity — a konkrétně pro PHP CMS pokrývá stejnou půdu zpevnění endpointů v průvodci ochranou WordPressu.

Jak Itnetic chrání své zákazníky

Edge WAF Itnetic nasazuje strukturální filtr PHP2Shell, který běží na každém POPu jako součást WAF, jenž už stojí před každým chráněným webem. Zkoumá tvar každého požadavku dřív, než ten požadavek vůbec dorazí na váš origin: detekuje záplavy částí s prázdným jménem souboru a hluboké zanoření názvů polí, které exploit definují, a dělá to tak, že měří tvar alokace — počty a hloubku — místo porovnávání s jedinou signaturou. Protože vychází ze struktury, a ne z pevného vzorce bajtů, obstojí i proti variantám payloadu, které by pravidlu na řetězec prošly rovnou.

Je to záměrně challenge, ne tvrdý blok. Skutečný návštěvník, který náhodou odešle velký nebo neobvyklý formulář, není odříznutý — nanejvýš jeho prohlížeč vyřeší rychlý neviditelný proof-of-work, než požadavek pokračuje. Právě v téhle volbě je celá pointa: filtr může být vůči tvaru agresivní, aniž by shodil legitimní formulář nebo nahrávání, protože cena omylu u skutečného návštěvníka je zlomek sekundy CPU, ne rozbitá stránka.

Poctivé zarámování je obrana do hloubky. Filtr Itnetic zastaví exploit na edge a získá vám prostor — chrání origin, zatímco plánujete a nasazujete vlastní záplatu PHP — ale není důvodem záplatu vynechat. Záplatujte PHP; nechte edge pokrýt okno mezitím. Pokud ještě za Itnetic nestojíte, DDoS ochrana a celý WAF se spustí dvěma DNS záznamy v plánu zdarma a strukturální filtr je zapnutý od prvního požadavku.