Stručně: Mnoho rad k PHP2Shell, které právě kolují na fórech a sociálních sítích, nechrání nebo dokonce škodí: blokovat požadavky se session cookie, skrývat chybová hlášení, nastavovat hodnoty přes .user.ini nebo aktualizovat jen CMS. php.net je jednoznačný: Úplná přechodná opatření neexistují, aktualizace PHP s restartem všech procesů je jedinou bezpečnou cestou.
Proč jsou falešné rady v této situaci nebezpečné
U kritické zranitelnosti s velkou pozorností vzniká trh s rychlými řešeními. Rady se sdílejí, zkracují a předávají dál, často bez omezení původního zdroje. U PHP2Shell k tomu přistupuje, že se podle zpráv podrobnosti staly známými už před oficiálním termínem a situace byla v prvních dnech nepřehledná.
Falešná rada škodí dvojnásob. Nechává zranitelnost otevřenou a vyvolává pocit, že se něco udělalo. Právě tento pocit způsobuje, že vlastní aktualizace zůstane ležet. Některé rady navíc ochromí vlastní web.
Devět rad v kontrole faktů
Následující tabulka shrnuje, co jsme v posledních dnech často četli, a proti tomu klade tvrzení primárních zdrojů.
| Kolující rada | Proč neobstojí | Co platí místo toho |
|---|---|---|
Blokovat všechny požadavky s PHPSESSID |
Odborní autoři výslovně odmítají; ochromí přihlášení a nákupní košíky | aktualizovat PHP |
session.upload_progress.enabled=0 stačí |
Podle odborných zpráv neuzavírá obě zranitelnosti | smysluplné přechodné opatření, aktualizace zůstává povinná |
Hodnoty nastavovat přes ini_set() nebo .user.ini |
php.net to výslovně nedoporučuje | na straně serveru v php.ini, poolu FPM nebo konfiguraci serveru |
| Skrývat chybová hlášení | Podle php.net nepomáhají error_reporting, display_errors ani @ |
aktualizace; výstup chyb přesto veřejně neukazovat |
Omezit paměť přes RLIMIT_AS nebo RLIMIT_DATA |
php.net varuje, že právě to může vyvolat zranitelnou situaci | limit přes kontejner nebo cgroup |
| Aktualizovat WordPress nebo pluginy | Zranitelnost je v interpretu PHP, ne v CMS | aktualizovat běhové prostředí PHP |
| Stačí Cloudflare nebo jiný WAF | Ochrana jen pro provoz přes službu; přímo dostupné servery zůstávají otevřené | WAF jako dodatečná vrstva, ne jako náhrada |
| Službu znovu načíst místo restartovat | Podle Red Hat reload nestačí, stávající workery si mohou ponechat starý stav | všechny workery kompletně restartovat |
| Záplatováno znamená čisté | Záplata neodstraní dříve vložený škodlivý software | zajistit logy od 20. 10. a hledat stopy |
Tři nejčastější omyly podrobněji
Zákaz cookies
Rada odmítat všechny požadavky se session cookie PHPSESSID zní technicky a rozhodně. Odborní autoři ji výslovně odmítají. V praxi rozbije všechno, co potřebuje relaci: zákaznické účty, nákupní košíky, administrátorské sekce, formuláře s ochranou proti padělání. Ochranou proti zranitelnosti není.
Jedno nastavení, které vyřeší všechno
session.upload_progress.enabled=0 stojí v doporučeních php.net a je uvedenou nápravou pro CVE-2026-115560. V některých příspěvcích se z toho stalo „PHP2Shell vypnuto“. Podle odborných zpráv však toto nastavení samo o sobě neuzavírá obě zranitelnosti. Ani memory_limit=-1 podle php.net neodstraní nic víc než ovladatelnou spouštěcí podmínku; chyba paměti na hlubší úrovni může zranitelnou cestu stále dosáhnout. U PHP 8.5 blokuje fatal_error_backtraces=0 podle php.net jen potvrzenou cestu přes backtraces.
Jak nastavení přesto správně a trvale provést, popisuje článek Vypnutí session.upload_progress. Úplný seznam přechodných opatření stojí na stránce Okamžitá opatření bez záplaty.
Ochranný štít před dveřmi
Cloudflare má podle vlastních údajů od 21. října aktivní ochranná pravidla, i pro zákazníky v bezplatném tarifu. Cloudflare sám ale upozorňuje na hranice: Ochrana působí jen na provoz, který prochází přes Cloudflare. Pokud je origin server dostupný přímo, je obejita. Cloudflare navíc kontroluje i odpověď serveru, protože samotný požadavek ne vždy stačí. Proč WAF aktualizaci nenahrazuje, vysvětluje článek WAF, nebo aktualizace.
Rada s rizikem: filtrovat požadavky na nahrávání na okraji
Ne každá nepohodlná rada je chybná. Odborní autoři navrhují jako dočasné, neoficiální opatření blokovat požadavky multipart/form-data mimo skutečné cesty nahrávání na proxy nebo ve WAF. Může to zmenšit plochu pro útok, ale rozbije formuláře a nahrávání, pokud je seznam povolených cest neúplný.
Kdo touto cestou jde, měl by ji předem vyzkoušet v testovacím prostředí, dohodnout s odbornými odděleními a zdokumentovat jako dočasné opatření. Ani ona aktualizaci nenahrazuje.
Mnoho řešení WAF nabízí pozorovací režim, ve kterém pravidla zprvu jen protokolují místo blokování. Nechte nové pravidlo několik dní takto běžet a vyhodnoťte, které legitimní požadavky by byly dotčeny. Teprve poté přepněte na blokování. Tak předejdete tomu, aby formuláře pro uchazeče, zákaznické portály nebo nahrávání obrázků v obchodě nepozorovaně přestaly fungovat.
Jak radu ověřit, než ji uplatníte
Čtyři otázky oddělují použitelné rady od nebezpečných:
- Zdroj: Pochází doporučení z php.net, od vaší distribuce, BSI nebo od jmenovaného odborného autora?
- Nárok: Je opatření popsáno jako přechod, nebo jako řešení? U PHP2Shell je řešením jen aktualizace.
- Vedlejší účinek: Co se rozbije, když opatření zabere? Rada bez upozornění na vedlejší účinky je neúplná.
- Místo provedení: Nastavuje se na straně serveru způsobem, který nelze přepsat, s následným restartem všech workerů?
Zaznamenejte si, která přechodná opatření jste kdy nastavili. Tak je můžete později cíleně zkontrolovat a poznat, zda domnělá ochrana nezdržela skutečnou aktualizaci.
Jak konkrétně pomáhá PHP SOS?
- Kontrolujeme opatření, která u vás již byla provedena, a oddělujeme účinná od neúčinných.
- Nasazujeme aktualizaci PHP, restartujeme všechny procesy a doložíme stav.
- Kde aktualizace ještě není možná, nastavujeme přechodná opatření podle php.net na straně serveru a zdokumentovaně.
- Pomocí WAF a virtuálního záplatování doplňujeme ochranu na okraji, aniž bychom nahradili aktualizaci.
Časté dotazy
Chrání blokování požadavků s PHPSESSID?
Ne. Odborní autoři tuto kolující radu výslovně odmítají. Ochromí přihlášení, nákupní košíky a formuláře, aniž by uzavřela zranitelnost v interpretu.
Stačí session.upload_progress.enabled=0 proti PHP2Shell?
Ne. Nastavení je jedním z několika přechodných opatření a podle odborných zpráv neuzavírá obě zranitelnosti. Je smysluplné, ale aktualizaci PHP nenahrazuje.
Pomůže vypnout display_errors?
Pro PHP2Shell ne. php.net upozorňuje, že skrývání diagnostiky přes error_reporting, display_errors nebo operátor @ nepomáhá. V produkci by display_errors přesto mělo být vypnuto z jiných důvodů.
Podle čeho poznám seriózní radu?
Seriózní rada uvádí svůj zdroj, popisuje hranice a označuje přechodná opatření jako taková. Kdo slibuje, že jediné nastavení činí aktualizaci zbytečnou, se u PHP2Shell mýlí.