Stručne: Mnohé tipy k PHP2Shell, ktoré práve kolujú vo fórach a na sociálnych sieťach, nechránia alebo dokonca škodia: blokovať požiadavky so session cookie, skrývať chybové hlásenia, nastavovať hodnoty cez .user.ini alebo aktualizovať len CMS. php.net je jednoznačný: neexistujú úplné prechodné opatrenia, aktualizácia PHP s reštartom všetkých procesov je jediná bezpečná cesta.
Prečo sú falošné tipy v tejto situácii nebezpečné
Pri kritickej zraniteľnosti s veľkou pozornosťou vzniká trh s rýchlymi riešeniami. Rady sa zdieľajú, skracujú a odovzdávajú ďalej, často bez obmedzení pôvodného zdroja. Pri PHP2Shell k tomu pristupuje, že podrobnosti sa podľa správ stali známymi už pred oficiálnym termínom a situácia bola v prvých dňoch neprehľadná.
Falošný tip škodí dvojnásobne. Necháva zraniteľnosť otvorenú a vyvoláva pocit, že sa niečo urobilo. Práve tento pocit vedie k tomu, že skutočná aktualizácia zostane ležať. Niektoré rady navyše ochromia vlastný web.
Deväť rád pod lupou
Nasledujúca tabuľka zhŕňa, čo sme v posledných dňoch často čítali, a stavia proti tomu tvrdenia primárnych zdrojov.
| Kolujúci tip | Prečo neobstojí | Čo platí namiesto toho |
|---|---|---|
Blokovať všetky požiadavky s PHPSESSID |
Odborní autori ho výslovne odmietajú; ochromí prihlásenia a nákupné košíky | Aktualizovať PHP |
session.upload_progress.enabled=0 stačí |
Podľa odborných správ neuzatvára obe zraniteľnosti | Zmysluplné prechodné opatrenie, aktualizácia zostáva povinná |
Nastaviť hodnoty cez ini_set() alebo .user.ini |
php.net od toho výslovne odrádza | Na strane servera v php.ini, poole FPM alebo konfigurácii servera |
| Skrývať chybové hlásenia | Podľa php.net nepomáhajú error_reporting, display_errors ani @ |
Aktualizácia; výpis chýb napriek tomu verejne neukazovať |
Obmedziť pamäť cez RLIMIT_AS alebo RLIMIT_DATA |
php.net varuje, že práve to môže vyvolať zraniteľnú situáciu | Limit cez kontajner alebo cgroup |
| Aktualizovať WordPress alebo zásuvné moduly | Zraniteľnosť je v interpreteri PHP, nie v CMS | Aktualizovať runtime PHP |
| Cloudflare alebo iný WAF stačí | Ochrana len pre prevádzku cez službu; priamo dostupné servery zostávajú otvorené | WAF ako doplnková vrstva, nie náhrada |
| Službu načítať znova namiesto reštartu | Podľa Red Hat reload nestačí, existujúci workeri si môžu ponechať starý stav | Všetkých workerov úplne reštartovať |
| Zaplátané znamená čisté | Záplata neodstráni škodlivý softvér zavlečený predtým | Zálohovať logy od 20. 10. a skontrolovať stopy |
Tri najčastejšie omyly podrobnejšie
Zákaz cookies
Tip odmietať všetky požiadavky so session cookie PHPSESSID znie technicky a rozhodne. Odborní autori ho výslovne odmietajú. V praxi rozbije všetko, čo potrebuje reláciu: zákaznícke účty, nákupné košíky, administrátorské oblasti, formuláre s ochranou proti falšovaniu. Ochranou proti zraniteľnosti nie je.
Jedno nastavenie, ktoré všetko vyrieši
session.upload_progress.enabled=0 stojí v odporúčaniach php.net a je uvedenou nápravou proti CVE-2026-115560. V niektorých príspevkoch sa z toho stalo „PHP2Shell vypnuté“. Podľa odborných správ však toto nastavenie samotné neuzatvára obe zraniteľnosti. Ani memory_limit=-1 podľa php.net neodstráni nič iné než ovládateľný spúšťač; chyba pamäte na hlbšej úrovni môže zraniteľnú cestu naďalej dosiahnuť. Na PHP 8.5 blokuje fatal_error_backtraces=0 podľa php.net len potvrdenú cestu cez backtraces.
Ako nastavenie napriek tomu správne a trvalo nastaviť, popisuje príspevok Vypnutie session.upload_progress. Úplný zoznam prechodných opatrení nájdete pod Okamžité opatrenia bez záplaty.
Ochranný štít pred tým
Cloudflare má podľa vlastných údajov od 21. októbra aktívne ochranné pravidlá, aj pre zákazníkov v bezplatnom tarife. Cloudflare sám však upozorňuje na hranice: ochrana zaberá len pre prevádzku, ktorá prechádza cez Cloudflare. Ak je pôvodný server dostupný priamo, obíde sa. Okrem toho Cloudflare kontroluje navyše aj odpoveď servera, pretože samotná požiadavka nie vždy stačí. Prečo WAF aktualizáciu nenahrádza, vysvetľuje príspevok WAF alebo aktualizácia.
Tip s rizikom: filtrovať požiadavky uploadu na okraji
Nie každá nepohodlná rada je nesprávna. Odborní autori navrhujú ako dočasné, neoficiálne opatrenie blokovať požiadavky multipart/form-data mimo skutočných ciest uploadu na proxy alebo vo WAF. Môže to zmenšiť útočnú plochu, ale rozbije formuláre a uploady, ak je zoznam povolených ciest neúplný.
Kto túto cestu zvolí, mal by ju vopred preveriť v testovacom prostredí, dohodnúť s odbornými oddeleniami a zdokumentovať ako časovo obmedzené opatrenie. Ani ona nie je náhradou aktualizácie.
Mnohé riešenia WAF ponúkajú na to režim pozorovania, v ktorom pravidlá najprv iba zaznamenávajú namiesto blokovania. Nechajte nové pravidlo niekoľko dní bežať takto a vyhodnoťte, ktoré legitímne požiadavky by boli dotknuté. Až potom prepnite na blokovanie. Tak sa vyhnete tomu, že sa nepozorovane prestanú dať odosielať formuláre uchádzačov, zákaznícke portály alebo upload obrázkov v e-shope.
Ako tip preveriť, kým ho zrealizujete
Štyri otázky oddeľujú použiteľné rady od nebezpečných:
- Zdroj: Pochádza odporúčanie z php.net, vašej distribúcie, BSI alebo od menovite uvedeného odborného autora?
- Nárok: Opisuje sa opatrenie ako prechod, alebo ako riešenie? Pri PHP2Shell je riešením len aktualizácia.
- Vedľajší účinok: Čo sa pokazí, keď opatrenie zaberie? Tip bez upozornenia na vedľajšie účinky je neúplný.
- Miesto realizácie: Nastavuje sa nastavenie na strane servera a tak, aby sa nedalo prepísať, s následným reštartom všetkých workerov?
Zaznamenajte, ktoré prechodné opatrenia ste kedy nastavili. Tak ich môžete neskôr cielene skontrolovať a rozpoznať, či domnelá ochrana nezdržala skutočnú aktualizáciu.
Ako konkrétne pomáha PHP SOS?
- Kontrolujeme opatrenia, ktoré už boli u vás realizované, a oddeľujeme účinné od neúčinných.
- Nasadzujeme aktualizáciu PHP, reštartujeme všetky procesy a doložíme stav.
- Kde aktualizácia ešte nie je možná, nastavujeme prechodné opatrenia podľa php.net na strane servera a zdokumentované.
- Pomocou WAF a virtuálneho záplatovania dopĺňame ochranu na okraji, bez toho, aby sme nahradili aktualizáciu.
Časté otázky
Chráni blokovanie požiadaviek s PHPSESSID?
Nie. Odborní autori tento kolujúci tip výslovne odmietajú. Ochromí prihlásenia, nákupné košíky a formuláre bez toho, aby uzavrel zraniteľnosť v interpreteri.
Stačí session.upload_progress.enabled=0 proti PHP2Shell?
Nie. Nastavenie je jedným z viacerých prechodných opatrení a podľa odborných správ neuzatvára obe zraniteľnosti. Je zmysluplné, ale aktualizáciu PHP nenahrádza.
Pomôže vypnúť display_errors?
Pre PHP2Shell nie. php.net upozorňuje, že skrývanie diagnostiky cez error_reporting, display_errors alebo operátor @ nepomáha. V produkcii by malo byť display_errors vypnuté z iných dôvodov aj tak.
Podľa čoho spoznám serióznu radu?
Seriózna rada uvádza svoj zdroj, popisuje hranice a prechodné opatrenia za také označuje. Kto sľubuje, že jediné nastavenie urobí aktualizáciu zbytočnou, sa pri PHP2Shell mýli.