Stručne: Dočasné riešenie pre zraniteľnosť PHP2Shell môže znížiť riziko, ale aktualizáciu nenahrádza. php.net uvádza na to pevné hranice pamäte a nahrávania, vypnutie session upload progress a na PHP 8.5 fatal_error_backtraces=0. Ak nie je možné ani toto v krátkom čase, BSI odporúča webový server dočasne odpojiť od siete.
Čo dokáže dočasné riešenie a čo nie
Prechodné opatrenia php.net majú sťažiť podmienky, za ktorých sa dajú zneužiť zraniteľnosti CVE-2026-109618 a CVE-2026-109619. Výslovne nejde o úplnú ochranu. Zraniteľnosti sú opravené iba v PHP 8.5.12, 8.4.27, 8.3.36 a 8.2.35 alebo v potvrdenom backporte vášho poskytovateľa.
Opatrenia sú zmysluplné, ak aktualizácia z konkrétneho dôvodu ešte nejde: servisné okno ešte len príde, aplikácia sa musí najprv otestovať, alebo prevádzkujete PHP 8.1 či staršie, pre ktoré už neexistuje oficiálna aktualizácia. Sú potom mostom, nie cieľom.
Preto spolu s dočasným riešením plánujte aj aktualizáciu: kto ju zrealizuje, v ktorom servisnom okne a kto potom skontroluje, že sa reštartovali všetci workery? Prechod bez koncového dátumu hrozí, že sa stane trvalým stavom.
Možnosť 1: server dočasne odpojiť od siete
BSI vyhlásil výstražný stupeň 3 (oranžový) a odporúča dotknuté webové servery dočasne odpojiť od siete, ak aktualizácia nie je možná hneď. Niektorí poskytovatelia to urobili preventívne; neznamená to, že tieto weby boli hacknuté.
Pre mnohé firmy je výpadok obchodu alebo portálu drahý. Zváženie môže byť zmysluplné: prístup už iba cez VPN alebo povolené adresy IP, statická stránka údržby namiesto aplikácie PHP, alebo vypnutie jednotlivých, nepotrebných webov na serveri. Čím menej PHP je zvonka dostupné, tým menšia je plocha útoku.
Dôležité je urobiť rozhodnutie vedome a zaznamenať ho: kto kedy rozhodol nechať server online a s akými ochrannými opatreniami? To neskôr pomôže voči poisťovateľovi, ochrane údajov a vedeniu.
Prechodné opatrenia php.net
| Opatrenie | Hodnota | Poznámka |
|---|---|---|
memory_limit |
-1, nedá sa prepísať |
hranicu pamäte potom nastaviť cez kontajner alebo cgroup |
post_max_size |
8M bez nahrávania, 32M s nahrávaním |
upload_max_filesize pod touto hodnotou |
| Hranica pamäte | cez kontajner/cgroup | nie cez RLIMIT_AS alebo RLIMIT_DATA |
session.upload_progress.enabled |
0 |
v php.ini, poole alebo konfigurácii servera, nie cez ini_set() alebo .user.ini |
fatal_error_backtraces |
0 |
iba PHP 8.5 |
Nastavenie session.upload_progress.enabled=0 je zároveň náprava pre zraniteľnosť CVE-2026-115560, nahlásenú 23. októbra.
Správne nastaviť dočasné riešenie pre zraniteľnosť PHP
Rozhodujúce je miesto. Hodnoty musia byť nastavené tak, aby ich aplikácia nemohla prepísať. Cesty a názvy služieb sa líšia podľa distribúcie; príklady vychádzajú z PHP 8.3.
PHP-FPM, v poole (napr. /etc/php/8.3/fpm/pool.d/www.conf):
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 6M
php_admin_flag[session.upload_progress.enabled] = off
; iba PHP 8.5:
; php_admin_flag[fatal_error_backtraces] = off
Apache s mod_php, v konfigurácii servera alebo vo VirtualHost:
php_admin_value memory_limit -1
php_admin_value post_max_size 32M
php_admin_value upload_max_filesize 24M
php_admin_flag session.upload_progress.enabled off
Hranica pamäte cez cgroup, tu cez systemd pre službu FPM. Hodnotu prispôsobte svojmu serveru:
# sudo systemctl edit php8.3-fpm
[Service]
MemoryMax=2G
Potom reštartujte všetkých workerov, inak nezaberie nič z toho: systemctl restart php8.3-fpm alebo pri mod_php Apache. Ako overíte, že už nebeží žiadny starý proces, nájdete na stránke Reštart PHP-FPM a všetkých workerov. Všeobecné spevnenie konfigurácie popisuje stránka Bezpečná konfigurácia php.ini.
Po zmene otestujte nahrávanie súborov a veľké formuláre. Príliš malé post_max_size môže zablokovať objednávky, formuláre uchádzačov alebo nahrávanie médií. To je jeden z dôvodov, prečo aktualizáciu neodkladať dlho.
Dodatočné ochranné vrstvy
Web Application Firewall alebo virtuálne záplatovanie môže pomôcť ako ďalšia vrstva. Cloudflare nasadil ochranné pravidlá, sám však varuje, že pravidlá založené iba na údajoch požiadavky nestačia. WAF je preto doplnok, nie náhrada. Viac na stránke WAF a virtuálne záplatovanie.
Zabezpečte navyše logy servera od 20. októbra. Podľa správ médií bol prvý pokus o útok pozorovaný už 17. októbra; logy sú základom, ak neskôr budete musieť objasniť, či sa pred záplatou niečo stalo.
Ako konkrétne pomáha PHP SOS?
- Objasniť situáciu: Preveríme, či je aktualizácia krátkodobo možná alebo je potrebný prechod, a prerokujeme s vami možnosť odpojiť časti od siete.
- Nastaviť opatrenia: Hodnoty z php.net zapíšeme na správne miesto, nastavíme hranicu cgroup a reštartujeme všetkých workerov.
- Otestovať funkciu: Formuláre, nahrávanie súborov a objednávkové procesy po zmene skontrolujeme.
- Doviesť k záplate: Cez službu záplatovania PHP naplánujeme aktualizáciu a prechodné hodnoty potom riadene vrátime späť tam, kde prekážajú.
Časté otázky
Chráni dočasné riešenie úplne pred PHP2Shell?
Nie. php.net označuje opatrenia výslovne ako prechod, nie ako úplnú ochranu. Znižujú riziko, kým sa nenasadí aktualizácia. BSI (nemecký Spolkový úrad pre informačnú bezpečnosť) odporúča servery bez záplaty dočasne odpojiť od siete.
Môžem nastavenia zadať cez .htaccess alebo .user.ini?
Pre session.upload_progress.enabled php.net ini_set() a .user.ini výslovne vylučuje. Aj pre memory_limit platí: hodnota musí byť nastavená tak, aby ju aplikácia nemohla prepísať. To sa podarí v php.ini, v poole FPM s php_admin_value alebo v konfigurácii servera Apache.
Stačí ako dočasné riešenie Web Application Firewall?
Ako dodatočná vrstva môže pomôcť. Cloudflare nasadil ochranné pravidlá, sám však upozorňuje, že pravidlá založené iba na údajoch požiadavky nestačia. WAF nenahrádza ani aktualizáciu, ani prechodné opatrenia na serveri.
Čo robiť, ak mám iba zdieľaný hosting?
Potom php.ini a reštart zostávajú na poskytovateľovi hostingu. Opýtajte sa konkrétne, či sa aktualizácia nasadila alebo prechodné opatrenia nastavili a či sa reštartovali všetky procesy PHP.