Kritické zraniteľnosti PHP CVE-2026-109618 a 109619: čo urobiť dnes

Bezpečnostný tím PHP vydal v stredu 21. októbra 2026 o 16:00 nášho času mimoriadne verzie PHP 8.5.12, 8.4.27, 8.3.36 a 8.2.35, ktoré opravujú dve kritické zraniteľnosti CVE-2026-109618 a CVE-2026-109619, obe s hodnotením CVSS 9,2 z 10. Podľa PHP umožňujú spustenie kódu na serveri bez prihlásenia, a to ešte predtým, než sa vôbec spustí kód vašej aplikácie. Identifikátory a nástroj prezývaný PHP2Shell unikli už deň pred vydaním, takže útočníci mali náskok a hostingy nasadzovali provizórne opatrenia. Tento článok zhŕňa, čo je oficiálne potvrdené, ako reagujú provideri a čo má kto urobiť. Aktualizované 21. 10. 2026 o 20:30 SELČ: doplnené oficiálne detaily z vydania, čísla verzií, backporty a postup nasadenia u CloudLinuxu a nextHostingu.

Čo sa stalo: oprava vyšla, detaily unikli o deň skôr

Oficiálne oznámenie na php.net z pondelka 20. októbra bolo stručné: vydanie v stredu o 14:00 UTC, dve kritické zraniteľnosti CVSS v4.0 9,2, žiadne identifikátory ani postihnuté komponenty. Identifikátory a slovo „RCE" tak zazneli najprv inde. Európsky CERT-EU vydal 20. októbra večer advisory 2026-018 o možnom vzdialenom spustení kódu bez prihlásenia vo všetkých verziách od PHP 5 a na Hacker News sa objavil príspevok odkazujúci na „spoľahlivý zdroj" s hodnotením až 10,0 a zverejnením 22. októbra. PHP termín stiahlo na 21. októbra, oficiálne skóre je 9,2.

Vydanie prišlo presne podľa plánu. Popri štyroch opravených stabilných verziách vyšiel aj PHP 8.6.0 RC4 s tými istými opravami pre tých, čo testujú budúcu vetvu, a PHP zverejnilo bezpečnostné advisory s detailmi oboch chýb. Chyby nahlásili štyria výskumníci uvedení pod prezývkami v advisories na GitHube, medzi nimi ľudia z Wiz a OpenAI; opravu písali štyria členovia core tímu PHP vrátane Jakuba Zelenku. Záznamy MITRE a NVD boli v čase písania stále len rezervované.

Čo chyby robia: pamäť v nekonzistentnom stave, nie jedna konkrétna funkcia

Komunita deň pred vydaním hádala, že problém sedí v session.upload_progress. Oficiálny popis je širší a zaujímavejší. Obe chyby sú v jadre PHP, nie v konkrétnom rozšírení, a týkajú sa toho, ako PHP zaobchádza s pamäťou požiadavky pri fatálnej chybe.

CVE-2026-109618, „RCE via OOM corruption" (GHSA-w8hw-w9fx-j79w). Keď PHP narazí na vyčerpanie pamäte (out of memory), vyskočí z aktuálneho kontextu cez longjmp(). V niektorých situáciách je pamäť požiadavky dosiahnuteľná skôr, než je plne inicializovaná, a upratovanie požiadavky potom spracuje neplatné dáta ako platné. Útočník dokáže požiadavku do stavu OOM dotlačiť cez multipart parser bez toho, aby prekročil nastavené limity.

CVE-2026-109619, „RCE via stale global state" (GHSA-6wmf-4rv5-p3rp). Worker PHP si medzi požiadavkami drží globálny stav (chyby, session, objekty, stav rozšírení), ktorý ukazuje do pamäte predchádzajúcej požiadavky. Keď fatálna chyba alebo timeout požiadavku preruší skôr, než stav vynuluje, ďalšia požiadavka spracovaná tým istým workerom môže ten uvoľnený stav použiť, klasický use-after-free. Potvrdené cesty sú dve: diagnostika INI nastavení pred inicializáciou požiadavky a práve obsluha session.upload_progress. Na PHP 8.5 sa k tomu pridáva stav funkcie fatal_error_backtraces.

Kto je ohrozený najviac, hovorí PHP priamo: Apache s mod_php, kde bol predvedený exploit bez prihlásenia a bez účasti aplikácie. FrankenPHP je pravdepodobne zraniteľný z rovnakých dôvodov, PHP-FPM je zraniteľný v princípe (pri druhej chybe bol exploit cez upload progress overený aj na FPM, pri prvej sa kompletný exploit nepodarilo zostaviť) a LiteSpeed/LSAPI je pravdepodobne zraniteľný, ale neoverený. Útok typicky vyžaduje viac pokusov a obe požiadavky, tú, ktorá stav rozbije, aj tú, ktorá ho zneužije, musí obslúžiť rovnaký worker.

Praktický záver oboch advisories je rovnaký: aktualizácia je jediná úplná oprava. Vypnutie upload progress alebo nastavenie memory_limit sú podľa PHP len čiastočné opatrenia a žiadna kombinácia nastavení inštaláciu nezabezpečí.

Koho sa to týka: všetkých vetiev, vrátane tých bez podpory

Týka sa to každej inštalácie PHP, ktorá obsluhuje webové požiadavky, teda WordPressu, PrestaShopu, Joomly aj väčšiny e-shopových platforiem na slovenskom a českom trhu. Rozdiel je v tom, kto opravu dostane a ako.

Oficiálnu opravu dostali podporované vetvy 8.2, 8.3, 8.4 a 8.5. Vetvy 7.4, 8.0 a 8.1 sú po konci životnosti a bežne by nedostali nič. PHP však kvôli závažnosti urobilo výnimku: zverejnilo minimálne zdrojové backporty pre 7.4, 8.0 a 8.1. Sú určené pre tých, ktorí si PHP stavajú zo zdrojov alebo nemajú LTS dodávateľa; hotové balíčky nie sú. Linuxové distribúcie a LTS dodávatelia dostali opravy vopred, takže balíčky majú vychádzať rýchlo. Prečo nie je stará verzia PHP len pomalá, ale hlavne riziková, sme rozoberali v sprievodcovi PHP verze na hostingu (po česky). Táto streda je toho učebnicový príklad.

Zneužíva sa to? Cloudflare, CloudLinux aj Patchstack hlásili prvé pokusy zodpovedajúce uniknutému vzoru už v stredu dopoludnia, teda pred vydaním opravy. Katalóg CISA KEV chyby v čase písania neobsahoval. Pri septembrovej chybe vo WordPresse ubehli medzi zverejnením a plošnými skenmi hodiny; tu mali útočníci nástroj skôr než správcovia opravu.

Ako reagujú provideri: nextHosting, CloudLinux a Cloudflare

Najkonkrétnejšie z českých hostingov komunikuje nextHosting (značka Exon.io) na svojej stavovej stránke. Časová os stredy 21. októbra podľa providera:

CloudLinux, ktorého Alt-PHP a Imunify360 používa veľká časť zdieľaných hostingov na Slovensku, v Česku aj vo svete, vedie vlastný incident. Ráno nasadil do Imunify360 pravidlá ModSecurity blokujúce známy tvar exploitu (počas dňa sady 8.83 až 8.85) a od 14:39 UTC priebežne vydáva opravené balíčky alt-php pre všetky verzie od 5.2 do 8.5. Zaujímavé je poradie: ako prvé išli von balíčky pre alt-php74 (postupne EL6 až EL10, Debian 10 a 11, Ubuntu 16.04 až 26.04), potom alt-php80 a alt-php81, teda práve tie verzie, pre ktoré PHP žiadne hotové balíčky nerobí. Balíčky pre cPanel ea-php74 až ea-php85 majú vyjsť v EasyApache4 v25.91 a TuxCare ELS vydal opravené PHP 7.0, 7.2, 7.4 a 8.0 pre staré distribúcie. V čase písania (18:22 UTC) incident ešte nebol uzavretý a balíčky pre 8.2 až 8.5 v hlásení chýbali.

Cloudflare podľa svojho CTO nasadil WAF pravidlá proti známym vektorom na všetky tarify vrátane bezplatného. Pomôže to len webom, ktorých server prijíma prevádzku výhradne z adries Cloudflare. Ostatní slovenskí a českí provideri sa verejne nevyjadrili; pri väčších z nich možno predpokladať rovnaký postup ako pri CloudLinuxe, pretože na jeho technológii stoja.

Čo urobiť dnes: podľa toho, kde web beží

Zákazník zdieľaného hostingu. Verziu PHP na serveri opraví provider, vy môžete toto:

1. Zistite, na akej verzii PHP web beží (v administrácii hostingu, pri WordPresse v Zdraví webu). Ak je to 7.4, 8.0 alebo 8.1, prepnite na najvyššiu verziu, ktorú hosting ponúka a web zvládne. Backport síce existuje, ale záleží od toho, či ho váš hosting nasadí.
2. Overte, že provider opravu nasadil. Opravené verzie sú 8.5.12, 8.4.27, 8.3.36 a 8.2.35; pri Alt-PHP sa číslo verzie nemení a opravu spoznáte z hlásenia providera. Ak hosting nič nepublikoval, spýtajte sa podpory konkrétne.
3. Počítajte s obmedzením nahrávania. Ak provider blokuje multipart požiadavky alebo sprísnil WAF, môžu vypadávať formuláre s prílohami, import produktov alebo nahrávanie médií. Nie je to chyba vášho webu a po nasadení opravy by to malo pominúť.
4. Majte čerstvú zálohu mimo hostingu. Ak by došlo ku kompromitácii, je to jediná rýchla cesta späť.

Správca VPS alebo vlastného servera. Tu je zodpovednosť na vás:

1. Aktualizujte hneď na 8.5.12, 8.4.27, 8.3.36 alebo 8.2.35, prípadne na balíček distribúcie s touto opravou. Distribúcie dostali záplaty vopred, takže by nemali zaostávať o dni.
2. Reštartujte každý worker. PHP-FPM, Apache, FrankenPHP aj LiteSpeed. Bez reštartu beží stále starý kód a pri druhej chybe je práve dlho bežiaci worker podstata problému.
3. Ak nemôžete aktualizovať okamžite, PHP zverejnilo dočasné opatrenia s výslovnou poznámkou, že inštaláciu nezabezpečia: memory_limit = -1 vynútené cez php_admin_value vo FPM alebo v konfigurácii Apache tak, aby ho aplikácia nemohla prepísať; nízke post_max_size (8M bez uploadov, 32M s nimi); session.upload_progress.enabled = 0 v php.ini alebo v konfigurácii poolu, nie cez ini_set() ani .user.ini; a na PHP 8.5 navyše fatal_error_backtraces = 0. Po každej zmene reštart workerov. Druhé advisory spomína aj pm.max_requests = 1, čo výrazne predraží každú požiadavku.
4. Weby na PHP bez podpory buď prestavajte z oficiálneho zdrojového backportu, alebo ich izolujte, kým nebudú k dispozícii balíčky od dodávateľa.

Vývojár a agentúra. Prejdite zoznam klientov podľa verzie PHP a hostingu. Klienti na Apache s mod_php a na starých vetvách u providerov bez CloudLinuxu sú dnes najrizikovejšia skupina a pravdepodobne ich bude treba migrovať, nie len aktualizovať.

Zhrnutie

Po vydaní opravy je obraz jasnejší, nie pokojnejší. Obe chyby sú v jadre PHP, týkajú sa každého webového SAPI a najzraniteľnejší je Apache s mod_php, ktorý je na lacnejších hostingoch stále bežný. Jediná úplná oprava je aktualizácia na 8.5.12, 8.4.27, 8.3.36 alebo 8.2.35, všetky dočasné nastavenia sú podľa PHP len čiastočné. Dobrá správa je, že PHP výnimočne zverejnilo zdrojové backporty pre 7.4 až 8.1 a CloudLinux počas popoludnia vydával balíčky pre staré vetvy ako prvé. Postup nextHostingu stojí za pozornosť nie preto, že by bol bezbolestný, ale preto, že provider transparentne opisuje aj to, čo zákazníkom dočasne rozbil. V nasledujúcich dňoch bude zaujímavé sledovať, ako rýchlo ostatní slovenskí a českí provideri opravu nasadia a kto o tom vôbec dá vedieť.