Kritické zranitelnosti PHP CVE-2026-109618 a 109619: co udělat dnes

Bezpečnostní tým PHP vydal ve středu 21. října 2026 v 16:00 našeho času mimořádné verze PHP 8.5.12, 8.4.27, 8.3.36 a 8.2.35, které opravují dvě kritické zranitelnosti CVE-2026-109618 a CVE-2026-109619, obě s hodnocením CVSS 9,2 z 10. Podle PHP umožňují spuštění kódu na serveru bez přihlášení, a to ještě předtím, než se vůbec spustí kód vaší aplikace. Identifikátory a nástroj přezdívaný PHP2Shell unikly už den před vydáním, takže útočníci měli náskok a hostingy nasazovaly provizorní opatření. Tenhle článek shrnuje, co je oficiálně potvrzené, jak reagují provideři a co má kdo udělat. Aktualizováno 21. 10. 2026 ve 20:30 SELČ: doplněné oficiální detaily z vydání, čísla verzí, backporty a postup nasazení u CloudLinuxu a nextHostingu.

Co se stalo: oprava vyšla, detaily unikly o den dřív

Oficiální oznámení na php.net z pondělí 20. října bylo stručné: vydání ve středu ve 14:00 UTC, dvě kritické zranitelnosti CVSS v4.0 9,2, žádné identifikátory ani postižené komponenty. Identifikátory a slovo „RCE" tak zazněly nejdřív jinde. Evropský CERT-EU vydal 20. října večer advisory 2026-018 o možném vzdáleném spuštění kódu bez přihlášení ve všech verzích od PHP 5 a na Hacker News se objevil příspěvek odkazující na „spolehlivý zdroj" s hodnocením až 10,0 a zveřejněním 22. října. PHP termín stáhlo na 21. října, oficiální skóre je 9,2.

Vydání přišlo přesně podle plánu. Vedle čtyř opravených stabilních verzí vyšel i PHP 8.6.0 RC4 s týmiž opravami pro ty, kdo testují příští větev, a PHP zveřejnilo bezpečnostní advisory s detaily obou chyb. Chyby nahlásili čtyři výzkumníci uvedení pod přezdívkami v advisories na GitHubu, mezi nimi lidé z Wiz a OpenAI; opravu psali čtyři členové core týmu PHP včetně Jakuba Zelenky. Záznamy MITRE a NVD byly v době psaní stále jen rezervované.

Co chyby dělají: paměť v nekonzistentním stavu, ne jedna konkrétní funkce

Komunita den před vydáním hádala, že problém sedí v session.upload_progress. Oficiální popis je širší a zajímavější. Obě chyby jsou v jádru PHP, ne v konkrétním rozšíření, a týkají se toho, jak PHP zachází s pamětí požadavku při fatální chybě.

CVE-2026-109618, „RCE via OOM corruption" (GHSA-w8hw-w9fx-j79w). Když PHP narazí na vyčerpání paměti (out of memory), vyskočí z aktuálního kontextu přes longjmp(). V některých situacích je paměť požadavku dosažitelná dřív, než je plně inicializovaná, a úklid požadavku pak zpracuje neplatná data jako platná. Útočník dokáže požadavek do stavu OOM dotlačit přes multipart parser, aniž by překročil nastavené limity.

CVE-2026-109619, „RCE via stale global state" (GHSA-6wmf-4rv5-p3rp). Worker PHP si mezi požadavky drží globální stav (chyby, session, objekty, stav rozšíření), který ukazuje do paměti předchozího požadavku. Když fatální chyba nebo timeout požadavek přeruší dřív, než stav vynuluje, další požadavek zpracovaný týmž workerem může ten uvolněný stav použít, klasický use-after-free. Potvrzené cesty jsou dvě: diagnostika INI nastavení před inicializací požadavku a právě obsluha session.upload_progress. Na PHP 8.5 se k tomu přidává stav funkce fatal_error_backtraces.

Kdo je ohrožený nejvíc, říká PHP přímo: Apache s mod_php, kde byl předveden exploit bez přihlášení a bez účasti aplikace. FrankenPHP je pravděpodobně zranitelný ze stejných důvodů, PHP-FPM je zranitelný v principu (u druhé chyby byl exploit přes upload progress ověřen i na FPM, u první se kompletní exploit nepodařilo sestavit) a LiteSpeed/LSAPI je pravděpodobně zranitelný, ale neověřený. Útok typicky vyžaduje víc pokusů a oba požadavky, ten, který stav rozbije, a ten, který ho zneužije, musí obsloužit stejný worker.

Praktický závěr obou advisories je stejný: aktualizace je jediná úplná oprava. Vypnutí upload progress nebo nastavení memory_limit jsou podle PHP jen částečná opatření a žádná kombinace nastavení instalaci nezabezpečí.

Koho se to týká: všechny větve, včetně těch bez podpory

Týká se to každé instalace PHP, která obsluhuje webové požadavky, tedy WordPressu, PrestaShopu, Joomly i většiny e-shopových platforem na českém trhu. Rozdíl je v tom, kdo opravu dostane a jak.

Oficiální opravu dostaly podporované větve 8.2, 8.3, 8.4 a 8.5. Větve 7.4, 8.0 a 8.1 jsou po konci životnosti a běžně by nedostaly nic. PHP ale kvůli závažnosti udělalo výjimku: zveřejnilo minimální zdrojové backporty pro 7.4, 8.0 a 8.1. Jsou určené pro ty, kdo si PHP staví ze zdrojů nebo nemají LTS dodavatele; hotové balíčky nejsou. Linuxové distribuce a LTS dodavatelé dostali opravy předem, takže balíčky mají vycházet rychle. Proč není stará verze PHP jen pomalá, ale hlavně riziková, jsme rozebírali v průvodci PHP verze na hostingu. Tahle středa je toho učebnicový příklad.

Zneužívá se to? Cloudflare, CloudLinux i Patchstack hlásily první pokusy odpovídající uniklému vzoru už ve středu dopoledne, tedy před vydáním opravy. Katalog CISA KEV chyby v době psaní neobsahoval. U zářijové chyby ve WordPressu uběhly mezi zveřejněním a plošnými skeny hodiny; tady měli útočníci nástroj dřív než správci opravu.

Jak reagují provideři: nextHosting, CloudLinux a Cloudflare

Nejkonkrétněji z českých hostingů komunikuje nextHosting (značka Exon.io) na své stavové stránce. Časová osa středy 21. října podle providera:

CloudLinux, jehož Alt-PHP a Imunify360 používá velká část sdílených hostingů v Česku i ve světě, vede vlastní incident. Ráno nasadil do Imunify360 pravidla ModSecurity blokující známý tvar exploitu (během dne sady 8.83 až 8.85) a od 14:39 UTC průběžně vydává opravené balíčky alt-php pro všechny verze od 5.2 do 8.5. Zajímavé je pořadí: jako první šly ven balíčky pro alt-php74 (postupně EL6 až EL10, Debian 10 a 11, Ubuntu 16.04 až 26.04), pak alt-php80 a alt-php81, tedy právě ty verze, pro které PHP žádné hotové balíčky nedělá. Balíčky pro cPanel ea-php74 až ea-php85 mají vyjít v EasyApache4 v25.91 a TuxCare ELS vydal opravené PHP 7.0, 7.2, 7.4 a 8.0 pro staré distribuce. V době psaní (18:22 UTC) incident ještě nebyl uzavřený a balíčky pro 8.2 až 8.5 v hlášení chyběly.

Cloudflare podle svého CTO nasadil WAF pravidla proti známým vektorům na všechny tarify včetně bezplatného. Pomůže to jen webům, jejichž server přijímá provoz výhradně z adres Cloudflare. Ostatní čeští a slovenští provideři se veřejně nevyjádřili; u větších z nich lze předpokládat stejný postup jako u CloudLinuxu, protože na jeho technologii stojí.

Co udělat dnes: podle toho, kde web běží

Zákazník sdíleného hostingu. Verzi PHP na serveru opraví provider, vy můžete tohle:

1. Zjistěte, na jaké verzi PHP web běží (v administraci hostingu, u WordPressu ve Zdraví webu). Pokud je to 7.4, 8.0 nebo 8.1, přepněte na nejvyšší verzi, kterou hosting nabízí a web zvládne. Backport sice existuje, ale záleží na tom, jestli ho váš hosting nasadí.
2. Ověřte, že provider opravu nasadil. Opravené verze jsou 8.5.12, 8.4.27, 8.3.36 a 8.2.35; u Alt-PHP se číslo verze nemění a opravu poznáte z hlášení providera. Pokud hosting nic nepublikoval, zeptejte se podpory konkrétně.
3. Počítejte s omezením nahrávání. Pokud provider blokuje multipart požadavky nebo zpřísnil WAF, mohou vypadávat formuláře s přílohami, import produktů nebo nahrávání médií. Není to chyba vašeho webu a po nasazení opravy by to mělo pominout.
4. Mějte čerstvou zálohu mimo hosting. Pokud by došlo ke kompromitaci, je to jediná rychlá cesta zpět.

Správce VPS nebo vlastního serveru. Tady je odpovědnost na vás:

1. Aktualizujte hned na 8.5.12, 8.4.27, 8.3.36 nebo 8.2.35, případně na balíček distribuce s touto opravou. Distribuce dostaly záplaty předem, takže by neměly zaostávat o dny.
2. Restartujte každý worker. PHP-FPM, Apache, FrankenPHP i LiteSpeed. Bez restartu běží stále starý kód a u druhé chyby je právě dlouho běžící worker podstata problému.
3. Pokud nemůžete aktualizovat okamžitě, PHP zveřejnilo dočasná opatření s výslovnou poznámkou, že instalaci nezabezpečí: memory_limit = -1 vynucené přes php_admin_value ve FPM nebo v konfiguraci Apache tak, aby ho aplikace nemohla přepsat; nízké post_max_size (8M bez uploadů, 32M s nimi); session.upload_progress.enabled = 0 v php.ini nebo v konfiguraci poolu, ne přes ini_set() ani .user.ini; a na PHP 8.5 navíc fatal_error_backtraces = 0. Po každé změně restart workerů. Druhé advisory zmiňuje i pm.max_requests = 1, což výrazně zdraží každý požadavek.
4. Weby na PHP bez podpory buď přestavte z oficiálního zdrojového backportu, nebo je izolujte, dokud nebudou k dispozici balíčky od dodavatele.

Vývojář a agentura. Projděte seznam klientů podle verze PHP a hostingu. Klienti na Apache s mod_php a na starých větvích u providerů bez CloudLinuxu jsou dnes nejrizikovější skupina a pravděpodobně bude potřeba je migrovat, ne jen aktualizovat.

Shrnutí

Po vydání opravy je obraz jasnější, ne klidnější. Obě chyby jsou v jádru PHP, týkají se každého webového SAPI a nejzranitelnější je Apache s mod_php, který je na levnějších hostinzích stále běžný. Jediná úplná oprava je aktualizace na 8.5.12, 8.4.27, 8.3.36 nebo 8.2.35, všechna dočasná nastavení jsou podle PHP jen částečná. Dobrá zpráva je, že PHP výjimečně zveřejnilo zdrojové backporty pro 7.4 až 8.1 a CloudLinux během odpoledne vydával balíčky pro staré větve jako první. Postup nextHostingu stojí za pozornost ne proto, že by byl bezbolestný, ale proto, že provider transparentně popisuje i to, co zákazníkům dočasně rozbil. V následujících dnech bude zajímavé sledovat, jak rychle ostatní čeští provideři opravu nasadí a kdo o tom vůbec dá vědět.