21. října 2026 vydalo PHP mimořádné bezpečnostní verze 8.5.12, 8.4.27, 8.3.36 a 8.2.35. Opravují dvě chyby, kterým se začalo říkat PHP2Shell: CVE-2026-109618 a CVE-2026-109619. Obě mají hodnocení CVSS 9,2 a obě dovolí nepřihlášenému útočníkovi spustit na serveru vlastní kód.
Od běžné zranitelnosti v pluginu se tahle liší v jedné nepříjemné věci. Není co odinstalovat. Problém je přímo v jazyce, na kterém váš web běží, a je jedno, jestli máte WordPress, Laravel nebo aplikaci psanou na míru.
Co se vlastně rozbilo
PHP si při zpracování požadavku hlídá, kolik má paměti. Když mu dojde, ukončí rozdělanou práci skokem jinam v kódu (funkce longjmp) a pustí se do úklidu. Potíž je v tom, že v ten okamžik má část dat připravenou jen napůl. Úklid pak místo platné hodnoty čte zbytky, které v paměti zůstaly. A útočník, který umí vyvolat dojití paměti na povel, dokáže ovlivnit, co tam v tu chvíli leží.
Druhá chyba je ze stejné rodiny. Po fatální chybě zůstane v procesu, který obsluhuje požadavky, kus starého stavu. Další návštěvník se pak trefí do serveru, který si pamatuje cizí požadavek a sahá do paměti, kterou už uvolnil.
Výsledek je v obou případech stejný: webshell. Skript, přes který útočník ovládá server, jako by u něj seděl.
Koho se to týká
Prakticky každého, kdo provozuje PHP web na neaktualizované verzi. Zranitelné je všechno před 8.2.35, 8.3.36, 8.4.27 a 8.5.12. Nezáleží na způsobu provozu: zasažené je Apache s mod_php, PHP-FPM, php-cgi, LiteSpeed i FrankenPHP. A platí to ve výchozím nastavení, nemusíte mít zapnuté nic neobvyklého.
Jestli ještě jedete na 7.4, 8.0 nebo 8.1, tyhle větve oficiální podporu nemají, ale backporty opravy existují. Berte to jako dobrý důvod naplánovat upgrade, protože příště takové štěstí být nemusí.
O jakém rozsahu se bavíme: nástroj Cortex Xpanse od Palo Alto napočítal přes 22 milionů veřejně dostupných instancí PHP, které mohly být zranitelné. Není to počet napadených webů, je to počet dveří, na které šlo zkusit zaklepat. CISA obě chyby 26. října zařadila do katalogu aktivně zneužívaných zranitelností.
Jedno upřesnění, protože v prvních dnech kolem podobné zprávy koluje spousta nepřesností. Unit 42 nejdřív popsala útok na jednu evropskou vládní instituci jako možný následek PHP2Shell a 25. října to odvolala, souvislost se jí potvrdit nepodařilo. Na naléhavosti aktualizace to nemění nic.
Co jsme udělali pro naše klienty
Weby, které spravujeme, běží na spravovaném hostingu, kde se PHP aktualizuje centrálně. To je pohodlné, ale spolehnout se na stavovou stránku poskytovatele nám nepřišlo jako dost. Prošli jsme projekt po projektu, ověřili verzi, kterou server skutečně vrací (ne tu, kterou hlásí administrace), a projeli logy ze dní kolem 21. října. Nic podezřelého jsme nenašli.
Klienti s paušální údržbou o tom většinou ani nevěděli, protože přesně tohle je ta služba. Ostatním jsme napsali.
Jak si to ověříte sami
Zabere to pět minut.
- V administraci hostingu (cPanel, Plesk nebo vlastní panel) najděte volbu verze PHP. Potřebujete celé číslo. „PHP 8.3" nestačí, rozdíl mezi 8.3.35 a 8.3.36 je přesně to, o čem je tenhle článek.
- Ve WordPressu se dostanete ke stejnému údaji přes Nástroje → Zdraví webu → Informace → Server.
- Napište hostingu jednu otázku: na jaké verzi PHP běží můj web a kdy jste nasadili opravu CVE-2026-109618? Odpověď ve stylu „jste v bezpečí" bez čísla verze podle nás nestačí.
A dva dny nato přišla třetí chyba
23. října PHP oznámilo další cestu ke spuštění kódu, CVE-2026-115560. Oprava zatím není, přijde v běžném opravném vydání. Zneužít ji jde jen při dost nezvyklé kombinaci nastavení: session.serialize_handler musí být nastavený na php_binary nebo php_serialize, aplikace ho musí za běhu přepnout na php přes ini_set() ještě před session_start(), a k tomu musí běžet session.upload_progress.enabled. Vývojáři PHP to považují za kombinaci, která se v praxi skoro nevyskytuje.
Doporučená ochrana je vypnout sledování průběhu nahrávání, tedy session.upload_progress.enabled=0 v php.ini nebo v konfiguraci FPM poolu. Kdo to po 21. říjnu nechal vypnuté, má tuhle cestu zavřenou.
Když aktualizovat hned nejde
Opravit to umí jenom záplata. Datadog to ve své analýze píše natvrdo a souhlasíme s tím: přenastavením php.ini se z toho nevykroutíte. Pokud čekáte na hosting, dává smysl omezit přístup k aplikaci zvenčí a dívat se po těchhle stopách:
- chyby o vyčerpané paměti s podivným „Unknown on line 0" v logu
- neobvykle velké odeslané formuláře s poli
PHPSESSIDneboPHP_SESSION_UPLOAD_PROGRESS, případně stovky částí formuláře v jednom malém požadavku - padající workery a segmentation fault v logu serveru
- proces shellu spuštěný webovým procesem, což je z celého seznamu nejjistější stopa
Když na něco narazíte, nemažte to naslepo. Zavolejte vývojáře nebo hosting a počítejte s obnovou z čisté zálohy a výměnou hesel.
Nejste si jistí, jestli je váš web v pořádku? Projdeme ho v rámci bezpečnostního auditu.