Stručne: Kto chce mať zraniteľnosť PHP2Shell uzavretú ešte dnes, potrebuje štyri veci: správnu aktualizáciu, reštart všetkých procesov PHP, kontrolu už zavlečeného škodlivého kódu a doklad. Ste postihnutý? Zavolajte. Pomôžeme vám. Preberáme to na diaľku, od prvej správy.
Teraz nič nemažte a nič neinštalujte odznova. Aj pri záplatovaní platí: najprv zabezpečiť, potom meniť. Ak sa už niečo dostalo dnu, potrebujeme stav súborov a logov. Nahláste núdzový prípad, poradie krokov objasníme s vami.
Prečo zraniteľnosť nemôže čakať
Obe zraniteľnosti, CVE-2026-109618 a CVE-2026-109619, sú v samotnom PHP a umožňujú spustenie škodlivého kódu na diaľku bez prihlásenia. BSI vyhlásilo stupeň varovania 3 (oranžový) a odporúča okamžitú aktualizáciu. Ak to nejde hneď, webové servery sa majú dočasne odpojiť od siete. Podľa správ médií sa prvé pokusy o útok pozorovali už pred zverejnením záplat 21. 10. 2026. Cloudflare pozoroval pokusy a nasadil ochranné pravidlá, ale varuje, že pravidlá založené len na údajoch požiadavky nestačia.
Dôležité pre prevádzkovateľov: Aktualizácia CMS zraniteľnosť PHP neuzavrie. Ani WordPress.org podľa správ neplánuje proti nej aktualizáciu, pretože zraniteľnosť je v interpreteri. Uzavrieť sa dá iba na úrovni PHP, teda v tom, čo váš server skutočne vykonáva.
Čo urobiť hneď
- Poznať cieľovú verziu. Opravené sú PHP 8.5.12, 8.4.27, 8.3.36 a 8.2.35. PHP 8.2 dosiahne 31. 12. 2026 koniec podpory, zahrňte to do plánovania.
- Zachytiť všetky systémy. Aj testovacie servery, obrazy kontajnerov a staré systémy dostupné z internetu.
- Objasniť zodpovednosť. Pri hostingových balíkoch a managed serveroch aktualizuje poskytovateľ. Opýtajte sa písomne na verziu a reštart.
- Uchovať logy. Od 20. 10. 2026, ako radí odborná tlač.
- Dohodnúť okno. Reštart na krátko preruší prebiehajúce požiadavky. Určte čas, keď môže niekto rozhodovať.
- Nečakať, ak je otvorené. Ak sa nedá záplatovať hneď, preverte s nami odpojenie alebo prechodné opatrenia.
Ako PHP SOS konkrétne pomáha?
- Zmapovať situáciu: Zachytíme systémy, verzie PHP, režimy prevádzky, poskytovateľov hostingu a dostupnosť a určíme poradie: najprv najviac exponované systémy.
- Zabezpečiť a uzavrieť: Zabezpečíme aktuálny stav, nasadíme aktualizáciu alebo privedieme hosting na preukázateľne záplatovaný stav a reštartujeme všetky procesy. Pri kontajneroch obraz zostavíme znova a nasadíme.
- Skontrolovať a vyčistiť: Keďže záplata škodlivý kód neodstráni, hľadáme znaky predchádzajúceho vniknutia a podľa potreby vyčistíme.
- Spevniť a podať správu: Dostanete písomný doklad pre každý systém a odporúčania, aby ďalšia aktualizácia prebehla rýchlejšie. Rozsah služieb popisuje služba PHP-Patch.
Aktualizácia, reštart, doklad: na čom záleží
Najčastejšou chybou je aktualizácia bez reštartu. Kým v pamäti bežia staré procesy, zostáva zraniteľný kód aktívny, aj keď sú súbory nové. Návod nájdete na stránke Reštart PHP-FPM a všetkých workerov. Druhou chybou je veriť zobrazeniu: distribúcie a poskytovatelia hostingu často dodávajú backporty, číslo verzie potom zostane rovnaké. Spoľahlivý je changelog balíka s číslami CVE, v rodine Debian pomocou apt-get changelog <paket>.
Okrem toho podľa príručky PHP od bezpečnostných vydaní platí nová direktíva memory_hard_limit_percent. Ak ju verzia PHP nepozná, je postihnutá. Test je krátky:
php -r 'var_dump(ini_get("memory_hard_limit_percent"));'
Musí sa spustiť osobitne pre každú verziu a režim prevádzky, pretože príkazový riadok môže používať inú verziu PHP než webový server. Na záver výsledok zaznamenáme, aby ste ho mohli ukázať svojmu poskytovateľovi hostingu, poisťovateľovi alebo zákazníkovi.
Ak aktualizácia nejde hneď
Existujú dôvody, prečo nie je aktualizácia možná ešte dnes: stará aplikácia, ktorá na novších verziách PHP nebeží, poskytovateľ hostingu bez schválenia, obraz kontajnera v pevnom pipeline. Pre tieto prípady php.net uvádza prechodné opatrenia, ktoré výslovne nie sú úplnou ochranou: nastaviť memory_limit=-1 tak, aby ho aplikácie nemohli prepísať, obmedziť post_max_size, session.upload_progress.enabled=0 a v PHP 8.5 fatal_error_backtraces=0, vždy s reštartom. K tomu pristupujú ochranné pravidlá na okraji, ktoré aktualizáciu nenahrádzajú. Kolujúci tip blokovať všetky požiadavky s PHPSESSID odborní autori výslovne odmietajú.
Ktoré opatrenia sa hodia k vášmu systému a čo môžu pokaziť, prerokujeme vopred. Viac nájdete na stránke Okamžité opatrenia, keď ešte nemôžete záplatovať a v téme WAF a virtuálne záplatovanie. Pre PHP 8.1 a staršie platí osobitná situácia, ktorá je popísaná v časti PHP 8.1 a staršie: čo teraz platí.
Čo by ste nám mali poslať
- Zoznam serverov a poskytovateľov hostingu, ak existuje
- Výstup
php -vpre každý systém a údaj o režime prevádzky - Údaj, či sa používa kontajner, Plesk, cPanel alebo managed ponuka
- Požadované časové okno a kontaktná osoba pre reštarty
- Poznámky k nápadnostiam od 17. 10. 2026
Prečo PHP SOS
Pracujeme Made in Germany a vďaka partnerskej sieti kybernetických profesionálov sa už vyše 25 rokov špecializujeme na IT bezpečnosť. Máte jedného kontaktného partnera, ktorý aktualizáciu sprevádza, skontroluje reštart a dodá doklad. Pracujeme na diaľku, bez výjazdu, a dokumentujeme každý krok. Nesľubujeme zázraky: Záplata zraniteľnosť uzavrie, ale nedokazuje, že sa predtým nič nestalo, a presne to vám aj povieme.
Ste postihnutý? Zavolajte. Pomôžeme vám.
Nenechávajte zraniteľnosť dlhšie otvorenú. Zavolajte alebo napíšte cez WhatsApp. Preberáme prípad od prvej správy a zostávame pri ňom, kým nie je incident uzavretý a zdokumentovaný. Nahlásiť núdzový prípad teraz.
Časté otázky
Môžem zraniteľnosť PHP uzavrieť sám, alebo potrebujem pomoc?
Aktualizácia je pre administrátorov zvládnuteľná, ale náchylná na chyby: musí sa aktualizovať verzia, ktorá skutočne obsluhuje požiadavky, a všetky procesy sa musia reštartovať. Kto má viac serverov, obrazy kontajnerov alebo poskytovateľa hostingu s osobitosťami, ušetrí s podporou čas aj chyby.
Musí sa PHP po aktualizácii reštartovať?
Áno. Samotné nové súbory nestačia, kým v pamäti bežia staré procesy PHP. Všetci workeri, resp. procesy sa musia reštartovať, pri mod_php webový server.
Čo robiť, ak pre moju verziu PHP ešte nie je aktualizácia?
Pre PHP 8.1 a staršie už projekt PHP nevydáva oficiálne aktualizácie. Potom je potrebný preukázateľne záplatovaný backport od poskytovateľa, migrácia na udržiavanú verziu alebo prechodné opatrenia, ktoré však neposkytujú úplnú ochranu.
Stačí nastaviť session.upload_progress.enabled na 0?
Nie. Podľa odborných správ samotné nastavenie neuzavrie obe zraniteľnosti, aktualizácia PHP zostáva povinná. Nastavte ho iba v php.ini, v poole FPM alebo v konfigurácii servera, nie cez ini_set() alebo .user.ini.
Ako zistím, že je zraniteľnosť potom naozaj uzavretá?
Dôkazom na bežiacom systéme: verzia alebo changelog balíka, test na novú direktívu memory_hard_limit_percent a potvrdenie, že sa po aktualizácii reštartovali všetky procesy.