Stručne: Virtuálne záplatovanie PHP premosťuje čas, kým sa nenasadí skutočná aktualizácia. Spájame na to pravidlá Web Application Firewall s prechodnými opatreniami, ktoré php.net zverejnil k PHP2Shell, a rovno určíme cestu k riadnej záplate. Úplnú ochranu to neposkytuje, v prechodnom období však znižuje riziko.
Kedy je virtuálne záplatovanie PHP zmysluplné
BSI (nemecký Spolkový úrad pre informačnú bezpečnosť) pri PHP2Shell odporúča okamžitú aktualizáciu a, ak to nejde, webové servery dočasne odpojiť od siete. Pre mnohé firmy nie je ani jedno možné hneď: obchod musí zostať dostupný, vlastný vývoj potrebuje pred aktualizáciou test, alebo server beží s PHP 8.1 a staršími, pre ktoré už neexistujú oficiálne aktualizácie.
V týchto prípadoch je virtuálne záplatovanie mostom. Nenahrádza rozhodnutie, či by nebola primeranejšia prevádzka offline. Toto zváženie robíte vy, my dodáme technické posúdenie.
Prečo samotná WAF nestačí
Cloudflare hlásil pozorované pokusy o útok a nasadil ochranné pravidlá, varuje však, že pravidlá založené iba na údajoch požiadavky nestačia. Dôvod je v povahe zraniteľností. Pri CVE-2026-109618 môže stav out-of-memory prerušiť PHP v čase, keď sú údaje požiadavky iba čiastočne inicializované. Pri CVE-2026-109619 môže interný stav po uvoľnení pamäte zostať zachovaný a môže ho využiť neskoršia požiadavka v tom istom workerovi. Takéto chyby závisia od stavu servera, nielen od obsahu jedinej požiadavky.
Preto sa spoliehame na viac vrstiev: pravidlá WAF pred serverom, prechodné opatrenia v samotnom PHP a zosilnené sledovanie servera. Každá vrstva zachytí časť, samotná žiadna nestačí. Spolu vám dajú čas nasadiť aktualizáciu usporiadane.
Prechodné opatrenia podľa php.net
php.net uvádza viaceré nastavenia, ktoré znižujú riziko, výslovne bez úplnej ochrany. Dôležité je, aby tieto hodnoty aplikácie nemohli prepísať. Príklad pre pool PHP-FPM s nahrávaním súborov:
; Prechodné opatrenia PHP2Shell (nie úplná ochrana), potom reštartovať všetkých workerov
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
; iba PHP 8.5:
php_admin_flag[fatal_error_backtraces] = off
Bez nahrávania súborov php.net odporúča post_max_size = 8M. Keďže sa memory_limit zruší, patrí k tomu hranica pamäte na úrovni kontajnera alebo cgroup, nie cez RLIMIT_AS alebo RLIMIT_DATA. Nastavenie session.upload_progress.enabled=0 patrí do php.ini, poolu FPM alebo konfigurácie servera, nie do ini_set() ani .user.ini. Zároveň je to náprava k upozorneniu o CVE-2026-115560. Všetky opatrenia v prehľade nájdete na stránke Okamžité opatrenia, ak ešte nemôžete záplatovať.
Prechodné opatrenia začnú pôsobiť až po reštarte všetkých workerov PHP. A chránia iba pred budúcimi útokmi: či sa niekto dostal dnu už predtým, nevysvetlia.
Kedy je prevádzka offline lepšou voľbou
Virtuálne záplatovanie nie je v každej situácii správnou odpoveďou. Pri niektorých konštaláciách radíme riadiť sa BSI a webový server dočasne odpojiť od siete, kým sa nezáplatuje:
- server beží s Apache a mod_php, kde tím PHP hodnotí riziko ako najvyššie a kde bol exploit ukázaný ešte predtým, než sa vôbec spustí kód aplikácie
- na serveri ležia obzvlášť chránené údaje, napríklad zdravotné, klientske alebo platobné údaje
- neexistuje možnosť nastaviť prechodné opatrenia pevne v konfigurácii servera, napríklad pri niektorých balíkoch zdieľaného hostingu
- už existujú príznaky, že server bol napadnutý
Dočasná prevádzka offline neznamená, že váš web bol hacknutý. Niektorí poskytovatelia z opatrnosti odpojili weby od siete. Krátka, vecná informačná stránka pre návštevníkov je potom zvyčajne lepším riešením než nevysvetlený výpadok.
Ako konkrétne pomáha PHP SOS?
- Preveriť situáciu: Zaznamenáme verzie PHP, spôsoby prevádzky a existujúce ochranné vrstvy, ako CDN, WAF alebo reverzný proxy. Pri mod_php upozorníme na zvýšené riziko, ktoré tam tím PHP vidí.
- Vybudovať vrstvy: Aktivujeme alebo doplníme pravidlá WAF, nastavíme prechodné opatrenia pevne v konfigurácii servera a obmedzíme pamäť cez kontajner alebo cgroup. Pri nastaveniach Nginx sa riadime stránkou Zabezpečenie Nginx s PHP-FPM.
- Reštart a test: Všetky procesy PHP sa reštartujú, potom skontrolujeme nahrávanie, formuláre, prihlásenie a pokladňu.
- Sledovať: V prechodnom období zvýšene sledujeme pády workerov, špičky pamäte a nezvyčajné procesy.
- Naplánovať záplatu: Určíme, kedy a ako príde riadna aktualizácia, a zrealizujeme ju cez službu záplatovania PHP.
Čo dostanete, čo potrebujeme a čo nesľubujeme
Dostanete dokumentáciu všetkých nastavených pravidiel a nastavení s odôvodnením, výsledky testov a plán termínov a opatrení ku skutočnej záplate. Od vás potrebujeme prístup na server alebo do panelu, prístup k CDN alebo WAF, ak existuje, technickú kontaktnú osobu a údaje o funkciách nahrávania vo vašich aplikáciách.
Nesľubujeme, že virtuálne záplatovanie zabráni útoku. Znižuje riziko na obmedzený čas. Pri PHP 8.1 a starších to nie je trvalý stav; sem patrí do plánu migrácia na podporovanú verziu.
Časté otázky
Čo je virtuálne záplatovanie?
Virtuálne záplatovanie znamená odtienenie známej zraniteľnosti pred aplikáciou namiesto zmeny samotného kódu. Deje sa to väčšinou cez Web Application Firewall alebo zmeny konfigurácie. Je to premostenie, nie náhrada aktualizácie.
Stačí proti PHP2Shell WAF môjho poskytovateľa CDN?
Samotná spravidla nie. Cloudflare nasadil ochranné pravidlá, sám však varuje, že pravidlá založené iba na údajoch požiadavky nestačia. WAF je dodatočná vrstva popri prechodných opatreniach a záplate.
Ako dlho sa môžem spoliehať na virtuálne záplatovanie?
Čo najkratšie. Má premostiť čas do riadnej aktualizácie, napríklad dokým nie je voľné servisné okno alebo kým sa aplikácia otestuje. Pri PHP 8.1 a starších k tomu patrí plán migrácie.
Môžu prechodné opatrenia narušiť môj web?
Áno, je to možné. Nižšie limity nahrávania môžu zabrániť nahrávaniu veľkých súborov a vypnutie session upload progress sa dotkne ukazovateľov priebehu pri nahrávaní. Po každej zmene otestujeme najdôležitejšie funkcie.