PHP2Shell: kritické chyby v PHP

PHP vydalo 21. října 2026 mimořádné bezpečnostní aktualisace kvůli dvěma kritickým zranitelnostem označovaným jako PHP2Shell: CVE-2026-109618 a CVE-2026-109619. Za určitých podmínek umožňují spustit cizí kód na serveru bez přihlášení nebo získat citlivá data z paměti. Obě mají hodnocení CVSS 4.0: 9,2 z 10. CERT-EU doporučuje okamžitě nasadit opravy.

Článek zachycuje stav k 26. říjnu 2026. Vzdálené spuštění kódu je prokázané v testech i při útocích z internetu na honeypoty, tedy návnadové servery určené ke sledování útočníků. Doložené zneužití na honeypotu ale ještě nepotvrzuje napadení běžné produkční oběti.

Koho se problém týká

Podle oficiálního upozornění PHP prověřte všechny instalace obsluhující webové požadavky: PHP-FPM (správce samostatných PHP procesů), Apache s mod_php (webový server spouštějící PHP přímo ve svém procesu), php-cgi (program pro spouštění PHP přes CGI či FastCGI), FrankenPHP (aplikační server s vestavěným PHP) i LiteSpeed (webový server s podporou PHP). Způsob provozu ovlivňuje dostupné cesty útoku; rozdíly popisuje technický rozbor.

Nezapomeňte na interní služby, obrazy kontejnerů a PHP přibalené k jiným produktům. NCSC-NL vede přehled dotčených zařízení a aplikací. Aktualisace systémového PHP nemusí opravit přibalenou kopii; u ní postupujte podle oznámení výrobce.

Postižené a opravené verse

Pro dvojici chyb z 21. října platí následující tabulka běžných vydání projektu PHP, bez dodatečných záplat od dodavatele:

Větev	Postižená vydání	První vydání s opravami
PHP 8.5	8.5.0–8.5.11	8.5.12
PHP 8.4	8.4.0–8.4.26	8.4.27
PHP 8.3	8.3.0–8.3.35	8.3.36
PHP 8.2	8.2.0–8.2.34	8.2.35

Pro nové nasazení zvolte nejnovější stabilní vydání PHP 8.5, pokud ho aplikace podporuje; k 26. říjnu 2026 je to PHP 8.5.12. U existujícího projektu nasazujte nejnovější opravné vydání jeho podporované větve, nejméně versi uvedenou v tabulce. Tabulka uvádí první opravy konkrétních chyb, nikoli obecnou záruku bezpečnosti webu. Doporučené nastavení sessions doplňte podle upozornění níže.

Na Windows použijte nové balíčky 8.5.12-1, 8.4.27-1, 8.3.36-1 nebo 8.2.35-1. PHP je vydalo 26. října kvůli samostatné chybě knihovny Brotli (CVE-2026-111497). Přípona -1 označuje nové sestavení balíčku se závislostmi; číslo verse za běhu zůstává stejné. Tabulku prvních oprav PHP2Shell to nemění. Chybný dekompresor lze použít přes rozšíření cURL při zapnuté automatické dekompresi HTTP odpovědí; výchozí nastavení cURL ji vypíná, aplikace a knihovny ji však mohou zapnout.

Kvůli doplňujícímu upozornění z 23. října PHP do příštího běžného opravného vydání doporučuje také:

session.upload_progress.enabled=0

Nastavení vypne sledování průběhu uploadu přes PHP sessions. Samotné nahrávání souborů ani běžné fungování sessions a přihlášení tím nevypínáte. Přestat fungovat může ukazatel průběhu nahrávání, pokud využívá právě tuto funkci PHP. Zadejte nastavení do php.ini nebo serverové konfigurace platné před parsováním požadavku a restartujte příslušné PHP procesy. Na sdíleném hostingu požádejte poskytovatele o úpravu tohoto nastavení.

Toto doplnění se týká CVE-2026-115560: vyžaduje zapnutý upload progress a přepnutí session.serialize_handler z php_binary nebo php_serialize na php za běhu, před session_start(). Aplikace, které handler takto nemění, podle upozornění mohou funkci ponechat zapnutou. Jde o další scénář vedle původní dvojice chyb.

Podle výzkumu Wiz zasahuje alespoň jedna z chyb vydání až k PHP 5.4, tedy i staré větve 5.6, 7.x, 8.0 a 8.1. U distribučních balíčků může být oprava přenesena do starší verse: rozhoduje potvrzení dodavatele o konkrétním balíčku, nikoli jen číslo PHP. Možnosti pro nepodporované větve popisuje část o starých projektech.

WordPress, Drupal, Joomla a další systémy

Aktuální CMS může běžet na zranitelném PHP. Wiz předvedl vzdálené spuštění kódu na WordPressu, Drupalu a Joomle. WordPress oznámil, že pro tyto chyby nechystá vlastní aktualisaci: opravit se musí PHP, které aplikaci spouští.

Jaké škody hrozí a jak velké je risiko

RCE znamená remote code execution, tedy vzdálené spuštění kódu. Útočníkův kód běží s oprávněními PHP procesu, který obsluhuje web. Rozsah škod závisí na přístupu tohoto procesu k souborům, databasi a dalším službám. Wiz předvedl také únik hesel, tokenů a jiných citlivých dat z paměti bez dosažení RCE.

Může útočník získat data z database?

Ano. Pokud ovládne PHP proces, může za vhodných podmínek využít přístup aplikace:

Získá připojovací údaje dostupné aplikaci, například z konfigurace. Ve WordPressu je obsahuje wp-config.php.
Z napadeného webového serveru se připojí k databasi pod účtem aplikace.
Čte tabulky v rozsahu oprávnění tohoto účtu; pokud má účet právo zápisu, může data také měnit nebo mazat.

Nepotřebuje k tomu oprávnění správce operačního systému ani database. Omezení databasových připojení jen na webový server tuto cestu samo nezastaví, protože útok probíhá právě z něj. Samostatný únik dat z paměti může odhalit přihlašovací údaje či právě zpracovávaná data, automaticky ale neumožňuje stáhnout celou databasi.

Co je prokázané a jak velké je risiko?

Funkční útok v testovacím prostředí, internetový pokus, úspěch na honeypotu a napadení běžné oběti jsou různé závěry. U PHP2Shell je potřeba rozlišovat:

RCE v testech je prokázané. Popisují ho oficiální rozbory PHP a výzkumné týmy. CrowdStrike (společnost zaměřená na kybernetickou bezpečnost) 23. října potvrdila vlastní reprodukci RCE s oprávněními obslužného procesu PHP.
Pokusy o útok jsou zaznamenané. Amazon Threat Intelligence zachytil pokus už 17. října, ale výslovně uvádí nejistotu, zda by tyto časné pokusy uspěly na skutečných systémech. Imperva za prvních 24 hodin sledované aktivity zaznamenala 482 342 požadavků proti 21 998 webům ve 103 zemích. Jde o počty požadavků a cílů v jejím měření, nikoli napadených webů.
Úspěšné útoky na honeypoty jsou doložené. Adel Karimi zveřejnil rozbor 35 spuštění shellu na třech návnadových serverech z 24. října. Záznamy síťových požadavků propojuje s telemetrií skutečně spuštěných procesů; nejde jen o odhad z pádů PHP. Servery používaly PHP 8.4.26 a Apache s mod_php, každý s jediným obslužným procesem. To útoku usnadňuje opakované zasažení stejného procesu. Pozorovaná cesta odpovídá CVE-2026-109618; rozbor nedokládá samostatné využití druhé chyby ani spolehlivost napříč jinými konfiguracemi.
Úspěšné napadení běžné produkční oběti přes tyto CVE není v prověřených veřejných zdrojích k 26. říjnu doložené. Jde o rozsah dostupných důkazů, nikoli potvrzení, že k takovému napadení nikde nedošlo.

Dvě původní zprávy o úspěšném zneužití byly následně opraveny:

Sophos 22. října ve 21:21 UTC opravil své dřívější tvrzení: zjistil skenování a neúspěšné pokusy, bez důkazu úspěšné kompromitace. Popisovaný malware se kvůli zablokovanému pokusu nedostal na cílový systém.
Unit 42 dne 25. října stáhl aktualisaci z 23. října o útoku na evropskou vládní instituci. Napadená aplikace používala zranitelné PHP, ale tým nedokázal potvrdit, že vstupní cestou bylo právě PHP2Shell.

Jednotlivé veřejné demonstrace (PoC) mají různou úroveň funkčnosti. CrowdStrike 23. října u mnoha zkoumaných ukázek zjistila pouze vyvolání pádu PHP. Novější záznamy z honeypotů už dokládají funkční útok odpovídající veřejně popsané metodě. Dosažení spolehlivého RCE přesto závisí na konkrétní versi PHP, aplikaci a prostředí. Samotný repozitář označený „PHP2Shell exploit“ není důkazem ovládnutí serveru.

U neopraveného veřejného webu jde o naléhavý problém. Možnost RCE je skutečná a útočníci mohou postupy dále zdokonalovat. CVSS 9,2 vyjadřuje závažnost, nikoli 92% pravděpodobnost napadení. Úspěch závisí na konfiguraci, aplikaci a rozložení paměti; tým PHP označuje za nejrisikovější mod_php. Aktualisaci proto neodkládejte.

Jak zajistit opravu svého webu

Opravené PHP musí skutečně obsluhovat danou doménu; příkazová řádka může používat jinou instalaci. Po nasazení zajistěte restart příslušných procesů a prověřte předchozí provoz. Při podezření na napadení koordinujte zásahy s uchováním důkazů.

Pokud nelze opravu nasadit včas, NCSC doporučuje zvážit odstavení služby. Dočasné omezení přístupu musí fungovat před spuštěním PHP.

Jak zjistit versi PHP na sdíleném hostingu

Potřebujete zjistit PHP, které skutečně obsluhuje konkrétní web. Přístup k příkazové řádce k tomu není nutný:

Administrace hostingu. Přihlaste se do zákaznického účtu, otevřete konkrétní doménu či webhosting a hledejte položku jako Verse PHP nebo Nastavení PHP. Pokud panel ukazuje jen „PHP 8.3“, vyžádejte si od podpory přesné vydání a potvrzení oprav. Více domén či subdomén může používat různé PHP.
WordPress. V administraci otevřete Nástroje → Zdraví webu → Informace → Server. Najdete zde versi PHP i způsob jeho spouštění. Název obrazovky se podle překladu může objevit také jako Stav webu.
Vlastní diagnostický soubor. Máte-li přístup k souborům webu přes správce souborů hostingu, SFTP nebo FTPS, vytvořte v jeho veřejném adresáři soubor overeni-php.php s následujícím obsahem. Otevřete ho v prohlížeči přes svou doménu, například https://vas-web.example/overeni-php.php, kde ukázkovou doménu nahraďte vlastní.

<?php
header('Content-Type: text/plain; charset=utf-8');
header('Cache-Control: no-store');

echo 'PHP: ', PHP_VERSION, "\n";
echo 'SAPI: ', PHP_SAPI, "\n";

První řádek výstupu ukáže přesnou versi, například PHP: 8.5.12. Druhý označuje SAPI (Server Application Programming Interface), tedy rozhraní, přes které PHP běží: fpm-fcgi znamená PHP-FPM a apache2handler modul PHP v Apache. Po kontrole soubor smažte.

Výsledek porovnejte s tabulkou opravených vydání; u backportovaného balíčku potřebujete potvrzení dodavatele. Ověření zopakujte po přepnutí či aktualisaci PHP. Příkaz php -v přes SSH může ukazovat jiné PHP než web a samotný výpis verse nepotvrzuje správné nastavení sessions ani nevyvrací dřívější napadení.

Omezení nouzových opatření

Dočasná opatření PHP omezují jen některé cesty útoku. Před použitím posuďte jejich dopad na konkrétní prostředí:

Opatření	Podstatné omezení
Vypnutí session upload progress	Blokuje potvrzené session cesty. Nastavení přes `ini_set()` ani FPM `.user.ini` pro tento účel nestačí.
`memory_limit=-1`	Musí být vynuceno správcem tak, aby aplikace nemohla konečný limit vrátit. Odstraňuje předvídatelné překročení limitu PHP. Selhání přidělení paměti ale zůstává možné a zrušení limitu zvyšuje risiko vyčerpání prostředků.
`fatal_error_backtraces=0` na PHP 8.5	Po restartu blokuje potvrzenou cestu přes backtrace fatální chyby, nikoli všechny varianty.

Další vrstvou je webový firewall (WAF). Cloudflare popsal ochranu zahrnující i analysu odpovědí. WAF chrání provoz, který jím prochází; stejně jako uvedená nastavení nenahrazuje aktualisaci PHP.

Co zajišťují hostingy

U webhostingu PHP obvykle aktualisuje poskytovatel, u VPS záleží na sjednané správě. Například Hostinger oznámil opravy hostingových služeb, zatímco PHP na VPS spravují zákazníci. Veřejná oznámení českých poskytovatelů, znovu ověřená 26. října 2026, ukazují rozdílné postupy:

Poskytovatel	Zveřejněný postup
Webglobe	Opravy včetně PHP od 5.5 výše. Webhosting aktualisuje poskytovatel, samostatně spravovaný server zákazník.
WP Hosting	Dokončení aktualisace 21. října v 16:31 a převedení webů z PHP 8.1 a starších na PHP 8.2. Nekompatibilní aplikace mohou vyžadovat úpravu.
ZonerCloud	Doplnění z 21. října ve 21:40 hlásí dokončení aktualisací webhostingu i všech spravovaných serverů. Pro webhosting potvrdil opravy PHP 8.2 a novějšího; PHP 8.1 a starší z této aktualisace vyjmul. VPS bez správy aktualisuje zákazník.
Český hosting	Uvádí opravné balíčky pro PHP 8.4 a 8.2 i LTS opravy pro 7.4, 7.3 a 5.6. U PHP 7.0 a 5.2–5.5 popisuje pouze dočasná opatření s omezením nahrávání dat; u nejstarších větví požaduje přechod alespoň na 5.6. Dlouhodobě doporučuje PHP 8.4.
WEDOS – odpověď podpory	U PHP 8.1 a staršího podpora uvádí preventivní vypnutí zranitelné funkce na úrovni serveru a doporučuje přechod na podporované PHP. Jde o opatření ke zmírnění risika, nikoli potvrzení opravy starého PHP.

Podpoře pošlete název své domény a tři otázky:

Jaké přesné vydání PHP moje doména používá a jaké opravené verse mohu zvolit?
Obsahuje balíček opravy CVE-2026-109618 i CVE-2026-109619 a byly po aktualisaci restartovány obslužné procesy?
Týká se mé aplikace upozornění CVE-2026-115560 a je potřeba změnit nastavení sessions?

Obecné oznámení nemusí pokrývat každý tarif a každou versi.

Co udělat se starou aplikací

Pokud aplikace potřebuje staré PHP, oddělte okamžitou opravu od dlouhodobé modernizace. Opravená stávající větev může umožnit pokračování provozu, zatímco připravíte přechod na novější prostředí.

Domluvte cílovou versi s hostingem. Využijte dotaz výše a ověřte, kterých webů se přepnutí týká. Záplata stejné větve nemusí vyžadovat změnu kódu; přechod například ze 7.4 na 8.5 může vyžadovat úpravu aplikace i závislostí.
Připravte zálohu a testovací kopii. Zálohujte soubory, databasi a konfiguraci a ověřte obnovu. Kopii chraňte před veřejným přístupem, nastavte cílové PHP a vypněte skutečné e-maily, produkční úlohy i reálné platby.
Upravte a otestujte aplikaci. Aktualisujte závislosti a opravte nekompatibilní části. Ověřte přihlášení, formuláře, uploady, databasi a případně testovací objednávky. Zkontrolujte chybové logy. Opuštěný plugin či knihovna mohou vyžadovat náhradu.
Nasaďte ověřenou změnu. Přepněte web na opravené PHP, nasaďte úpravy a ověřte doporučené nastavení i provoz. Při problému službu dočasně omezte; nevracejte ji na veřejně dostupné zranitelné PHP.

AI může pomoci s rozborem kódu, návrhy oprav a testy. Při zadávání práce se hodí prompty pro ověřování oprav a prevenci regresí. Mechanické změny umí automatisovat také Rector. Testy by měly zachytit dosavadní správné chování aplikace: mezi versemi se mění i význam některých operací, například porovnávání hodnot, takže samotné odstranění chybových hlášek nestačí.

Pokud migraci nelze dokončit včas, ptejte se na backport, tedy opravu přenesenou do starší větve. Například Plesk (webový administrační panel pro správu domén, webů, e-mailů, databasí a versí PHP bez příkazové řádky) pro Linux nabízí opravené PHP 7.4.33, 8.0.30 a 8.1.34 se stejným číslem verse, ale datem sestavení 21. října 2026. PHP 8.1 a starší už nemají běžnou podporu projektu; jednotlivá záplata ji neobnovuje.

Bez vhodného balíčku zvažte se správcem jiný hosting nebo vlastní spravované prostředí. Přechodným řešením může být vlastní sestavení PHP 7.4 z oficiální větve s opravami obou CVE. Na sdíleném hostingu vyžaduje součinnost poskytovatele; nahrání binárky samo nenahradí PHP obsluhující web.

Port oprav do ještě starší větve vyžaduje odbornou úpravu a ověření. Vlastní sestavení znamená převzít testování i další údržbu. Pro dlouhodobý provoz plánujte podporované prostředí; PHP 8.2 končí bezpečnostní podporu 31. prosince 2026.

Jak poznat možné zneužití

Jednoduchý test, který zpětně vyloučí napadení, neexistuje. Porovnávejte požadavky, chyby PHP a změny na serveru v čase. Aplikační log nemusí děj zachytit, protože může proběhnout ještě před spuštěním aplikace.

Co hledat	Jak nález posuzovat
Neobvyklé `multipart/form-data` požadavky následované vyčerpáním paměti nebo HTTP 500	Porovnejte logy webového serveru, proxy či WAF s chybami PHP. Vyčerpání paměti může mít i běžnou příčinu.
Nečekaně velké či poškozené hodnoty `PHPSESSID` v odpovědi, nevysvětlené pády nebo výměny PHP procesů	Prověřte telemetrii odpovědí a procesů. Jde o vodítka, nikoli automatický důkaz RCE.
Nové či změněné soubory, neobvyklé spouštění dalších procesů z PHP	Porovnejte soubory s důvěryhodným nasazením. Nález webshellu je závažná známka napadení.
Neznámí administrátoři, pluginy, přesměrování nebo změny obsahu	Prověřte účty, konfiguraci a databasi CMS a odlište změny od plánované správy.

Webshell je škodlivý skript, který útočník umístí na webový server a ovládá ho na dálku přes webové požadavky. Může mu umožnit číst a měnit soubory nebo spouštět příkazy s oprávněními webové aplikace. Například podvržený soubor PHP může útočníkovi zachovat přístup i po opravě původní zranitelnosti.

Vodítka popisují Wiz a AWS, který doporučuje vyšetřovat alespoň od 17. října 2026. Ani dřívější provoz nelze automaticky považovat za bezpečný. Hosting požádejte o uchování a vyhodnocení logů.

Běžný access log obvykle neobsahuje tělo požadavku ani obsah odpovědi. Blokovaný požadavek ve WAF potvrzuje jen blokování daného požadavku. Chybějící nálezy nebo čistý antivirový scan nevylučují únik dat z paměti. Nález napadení naopak sám neurčuje, zda vstupní cestou bylo právě PHP2Shell.

U WordPressu porovnejte soubory jádra, pluginů a šablon s důvěryhodnými balíčky a prověřte účty i konfiguraci. Oficiální postup WordPressu doporučuje kombinovat více způsobů kontroly a zapojit hosting.

Co dělat po napadení

Pokud se napadení potvrdí, samotná aktualisace PHP nestačí. Uzavře zranitelnost, ale neodstraní webshell, podvržený účet ani jiná zadní vrátka. Odcizené přístupy mohou dál fungovat a uniklá data nevezme zpět. NCSC proto doporučuje hledat i následky kompromitace.

Omezte pokračující útok. Se správcem či hostingem izolujte službu a omezte přístupy útočníka. Stránka údržby uvnitř CMS nemusí blokovat ostatní PHP skripty.
Uchovejte důkazy. Zajistěte logy, kopii souborů a database a zaznamenejte časy i zásahy. Potřebnou analysu paměti domluvte před restartem. Napadenou kopii uchovejte odděleně od čistých záloh.
Zjistěte rozsah. Prověřte aplikaci, účty, databasi, plánované úlohy a další služby dostupné napadenému procesu.
Obnovte důvěryhodný provoz. Odstraňte neoprávněné přístupy a obnovte aplikaci z ověřených zdrojů. Prověřte data i zálohy. Pokud nelze důvěřovat serveru, sestavte ho znovu v čistém prostředí. Potřebné aktualisace včetně PHP nasaďte před zpřístupněním služby.
Zneplatněte ohrožené přístupy. Z bezpečného prostředí změňte databasová a administrátorská hesla, odvolejte ohrožené API tokeny a ukončete sessions. Nové přístupy nevkládejte do stále napadeného prostředí. Ve WordPressu obnovte autentizační klíče a salts pro zneplatnění přihlašovacích cookies.
Ověřte obnovu. Zkontrolujte integritu, oprávnění a funkčnost webu. Sledujte podezřelé události a samostatně posuďte možný únik dat.

Jak se z požadavku stane spuštění kódu

Kdo chyby objevil a proč oprava přišla až teď

Tým PHP se problémem zabýval už v roce 2024. Podle PHP Foundation na něj narazil vývojář PHP při opravách navazujících na externí audit společnosti Quarkslab, organisovaný přes OSTIF. Šlo o problém s nedostatkem paměti (OOM); tehdy ale nebyla doložena konkrétní cesta ke vzdálenému spuštění kódu.

Zásadní průlom přinesl Ryan Austin z bezpečnostní společnosti Calif. Podle časové osy Calif tým objevil několik cest ke spuštění kódu 1. srpna 2026. První chybu nahlásil PHP 11. srpna, funkční demonstraci dodal 14. srpna a PHP ji následující den potvrdilo. Druhou chybu Calif nahlásil 21. srpna. Nezávislá zjištění a další možnosti zneužití přidaly také týmy OpenAI a Wiz; objev tedy nelze připsat jedinému týmu.

Oprava zasahovala základní mechanismy správy paměti a zpracování chyb. Jednotlivé návrhy hrozily narušením zpětné kompatibility, zhoršením výkonu, novými možnostmi odepření služby nebo nutností upravit množství rozšíření. Malý bezpečnostní tým se dlouho nedokázal shodnout na přijatelném řešení. PHP Foundation zdržení výslovně přiznává jako selhání rozhodovacího procesu a nedostatku kapacit. Po doložení RCE v srpnu 2026 se oprava stala nejvyšší prioritou; nadace také posílila bezpečnostní tým a mění rozhodování.

Týmy Calif, OpenAI a Wiz při výzkumu využívaly AI. Najít pád programu a sestavit spolehlivý exploit jsou různě náročné úkoly: útok musí propojit několik kroků a přizpůsobit se rozložení paměti konkrétního prostředí. Wiz popisuje, jak AI urychlila sestavování, ladění a přizpůsobování exploitů a pomohla tak prokázat praktický dopad dlouho přítomných chyb.

Únik identifikátorů narušil koordinované zveřejnění a vedl k posunu vydání oprav z 22. na 21. října 2026. Teprve po předběžném oznámení Calif omylem zveřejnil demonstrační video; jeho kopie pak přispěly k rychlejšímu vývoji dalších PoC.

Jak PHP obsluhuje požadavky

PHP-FPM znamená FastCGI Process Manager, tedy správce procesů pro spouštění PHP přes rozhraní FastCGI. Webový server, například Apache nebo Nginx, předá požadavek samostatnému PHP procesu. Ten vykoná aplikaci a vrátí výsledek, který server odešle návštěvníkovi.

mod_php je modul, který spouští PHP přímo uvnitř obslužného procesu Apache. Jde o historicky starší způsob propojení PHP s webovým serverem. Apache tedy může PHP vykonat sám pomocí mod_php, nebo práci předat PHP-FPM. Způsob spouštění je přitom nezávislý na versi PHP: i mod_php může používat aktuální vydání.

Nový požadavek obvykle znamená nové spuštění aplikace, ale nemusí znamenat nový proces operačního systému. PHP-FPM udržuje skupinu připravených procesů. Jeden proces může postupně obsloužit více požadavků; mezi nimi se běžně vyčistí proměnné aplikace a uvolní paměť požadavku. Aplikace tedy začíná znovu, přestože samotný proces dál existuje. Podobné opakované využití procesů funguje i u Apache s mod_php.

Právě to umožňuje jednu z popsaných cest útoku: po požadavku A se paměť uvolní, ale v procesu zůstane interní odkaz. Pokud stejný proces později obslouží požadavek B, může neplatný odkaz použít. Oba požadavky přitom probíhají postupně. Představa „jeden požadavek = jeden nový proces“ odpovídá například klasickému CGI. Rozdíl ve správě procesů ovlivňuje i reakci na chybu; PHP-FPM samo o sobě ochranu před chybou v PHP nezaručuje.

Dvě chyby při práci s pamětí

CVE-2026-109618 souvisí s nedostatkem paměti. Přerušení operace může zanechat interní data požadavku jen částečně připravená; následný úklid je přesto zpracuje jako platná. Výsledkem může být poškození paměti.

Útočník může tuto situaci vyvolat požadavkem POST typu multipart/form-data. Interní struktury pro hlavičky a vnořená pole mohou spotřebovat výrazně více paměti než přenesená data. U mod_php může chyba nastat už při parsování vstupu, takže ji kontrola přihlášení uvnitř aplikace nezastaví.

CVE-2026-109619 se týká stavu přežívajícího mezi požadavky. Jedna z cest vypadá takto:

Požadavek vytvoří interní stav například při práci se sessions.
Fatální chyba zabrání jeho správnému vyčištění.
Paměť se uvolní, ale obslužný proces si ponechá odkaz.
Další požadavek ve stejném procesu použije odkaz před jeho resetováním.

Fatální chyba není jediný možný spouštěč. Také nefatální varování při ukončování požadavku může znovu naplnit už vyčištěný stav, který pak odkazuje na uvolněnou paměť.

Jde o use-after-free, použití již uvolněné paměti. Patří do známé rodiny chyb při práci s pamětí: program dál používá neplatný odkaz a může přes něj přečíst nová, útočníkem ovlivněná data jako vlastní interní údaje. Neplatný odkaz může použít například sledování průběhu uploadu v sessions nebo diagnostika při inicialisaci. U upload progress nemusí aplikace sama volat session_start().

Proč je risiko u mod_php vyšší než u PHP-FPM

Tým PHP hodnotí risiko PHP2Shell jako nejvyšší u mod_php. V testech prokázaný útok může proběhnout už při přípravě požadavku, ještě před spuštěním kódu aplikace. Kontrola přihlášení uvnitř CMS ho proto nezastaví.

U první chyby, CVE-2026-109618, je podstatné chování po selhání přípravy požadavku kvůli nedostatku paměti:

mod_php pokračuje úklidem požadavku. Úklid přitom může zpracovat částečně připravená data jako platná a umožnit zneužití poškozené paměti.
PHP-FPM ukončí příslušný obslužný proces. Tím tuto konkrétní cestu přeruší. Problém však může vzniknout i po úspěšné přípravě požadavku, během aplikace.

Oficiální rozbor první chyby potvrzuje RCE pro mod_php; kompletní exploit této chyby pro FPM nepředvádí.

PHP-FPM je však zranitelné jinými cestami. U druhé chyby, CVE-2026-109619, bylo RCE v testech potvrzeno i přes FPM: během aplikace vznikne interní stav, fatální chyba zabrání jeho vyčištění a další požadavek ve stejném procesu ho použije přes sledování průběhu uploadu v sessions. Tato cesta závisí na vhodné operaci aplikace, jak popisuje rozbor druhé chyby.

Přechod z mod_php na PHP-FPM může omezit některé možnosti zneužití. Opravené PHP je potřeba v obou případech. Z ukončení procesu při selhání přípravy nelze vyvozovat, že FPM ukončí proces po každé fatální chybě během aplikace.

Příměr s hospodou

Představte si výčepního, který má za barem stojánek na lístky. Vedoucí mu tam nechá pokyn: „Po dočepování ukliď stůl.“ Výčepní si zapamatuje, že po dokončení objednávky provede pokyn ze stojánku. Jenže:

Objednávka se zruší a původní lístek někdo vyhodí.
Výčepnímu zůstane v hlavě, že má provést pokyn ze stojánku.
Host tam mezitím podstrčí svůj lístek: „Rozdej všem pivo na účet podniku.“
Výčepní se vrátí a provede nový pokyn, protože ho stále považuje za pokyn vedoucího.

Pamatuje si místo lístku, ale neověří, jestli tam pořád leží původní důvěryhodný pokyn. Výčepní představuje stále stejný PHP proces, stojánek místo v paměti a zapomenutý úkol odkaz na toto místo. PHP může nový obsah chybně přečíst jako údaj určující, kterou funkci má zavolat. V paměti jde o binární hodnoty, nikoli doslova o textový příkaz jako na lístku.

Známý princip: od bezpečnostních útoků po GTA Vice City

Podobná manipulace s pamětí patří mezi zavedené postupy při zneužívání programových chyb. Útočník ovlivní obsah paměti a využije chybu, kvůli které ho program přečte jako vlastní řídicí údaj, například adresu funkce. Samotné use-after-free má v katalogu MITRE označení CWE-416; příklady zahrnují prohlížeče i operační systémy.

Příbuzný princip využívají speedrunneři v GTA Vice City. Trik Script Stack Underflow (SSU) přiměje herní skript použít jiný údaj z paměti jako adresu pokračování a přeskočit rovnou k závěrečné misi. Stejně jako u PHP2Shell tak nesprávná data ovlivní další běh programu. Ve hře ale jde o chybu zásobníku skriptu, v popsané cestě PHP o uvolněnou paměť; spuštění existující mise samo neznamená spuštění vlastního strojového kódu.

Příklad: podvržená adresa změní volanou funkci

Vyvolání fatální chyby ještě neznamená RCE. Exploit musí ovlivnit paměť, kterou PHP považuje za vlastní struktury. Následující animace ukazuje princip: názvy i adresy jsou vymyšlené, nejde o přesný exploit PHP2Shell.

1 / 5 · Požadavek A běží

Proces si uloží odkaz na údaje pro pozdější úklid. V paměti je adresa původní funkce.

A · právě běží B · přijde později

Jeden stále běžící proces PHP · PID 4242

Proces zůstává. Obsah paměti se mění.

Uložený odkaz stav 0x1000 Starý odkaz zůstal!

Místo v paměti 0x1000

Údaje požadavku Acallback → 0x2000adresa funkce pro úklid

Co PHP udělá při použití odkazu Původní plán: zavolat úklid na 0x2000. Zatím se žádná funkce nevolá.

Data se sama nespustí. PHP je chybně přečte jako vlastní řídicí údaje a podle nich zavolá jinou funkci.

Zjednodušený model jedné cesty přes použití uvolněné paměti. Proces i adresa 0x1000 zůstávají stejné. Útočník musí dosáhnout vhodného obsazení paměti i podvržení dat; druhý požadavek navíc musí obsloužit stejný proces. Samotné odeslání požadavků úspěch nezaručuje.

V závěru animace podvržená data přesměrují volání na jinou, již existující funkci. Ta v modelu jen vypíše text. K dosažení RCE by útočník musel najít operaci umožňující spuštění kódu a předat jí vhodné argumenty. Adresy představují binární hodnoty v paměti, nikoli text k vložení do formuláře.

Ve skutečném výzkumu Wiz pomohl únik dat z paměti přes Set-Cookie: PHPSESSID=… zjistit adresy pro navazující RCE: PHP zaměnilo uvolněnou paměť za identifikátor session a odeslalo její obsah klientovi. Spolehlivý exploit musí trefit skutečné struktury, adresy a způsob volání; náhodné přepsání může způsobit jen pád.

Je to důvod opustit PHP?

Podle mého názoru samotný PHP2Shell není dostatečný důvod přepsat fungující projekt do jiného jazyka. Bezprostřední prioritou je oprava a prověření napadení. Přepis obvykle trvá výrazně déle a původní provoz je mezitím stále potřeba zabezpečit.

O migraci má smysl uvažovat, pokud závislosti blokují aktualisaci a tým nedokáže zajistit údržbu. Dlouhodobá správa backportů může být obtížnější než přechod na současné PHP a udržovaný framework či CMS, případně na jinou technologii.

Je Node.js vůči podobným chybám bezpečnější?

Aplikace běžící čistě na Node.js těmito konkrétními chybami PHP netrpí. Před stejnou rodinou paměťových chyb ale imunitu nemá. Běžný aplikační kód v JavaScriptu i PHP používá automatickou správu paměti. Chyba však může být v samotném běhovém prostředí nebo jeho knihovnách. Node.js používá engine V8 a nativní součásti, kde mohou vzniknout chyby v C či C++.

Například 29. července 2026 Node.js opravil use-after-free v HTTP/2 (CVE-2026-56848). 21. října pak opravoval chybu dekodéru Brotli (CVE-2026-111497), která mohla vést i k RCE, pokud aplikace rozbalovala útočníkem dodaná data přes node:zlib. Jde o jiné chyby s jinými podmínkami zneužití. Samotný přepis do Node.js tedy nezaručuje obecně bezpečnější web; dál potřebujete podporované verse, aktualisace závislostí a omezená oprávnění procesu.

Kdy zvolit statické HTML

Pro firemní presentace, dokumentaci, blogy a archivy může být vhodnější statický web. Zvlášť pokud mají roky fungovat s malými změnami a nepotřebují účty ani dynamické zpracování dat. Server předává hotové soubory bez spuštění PHP a dotazu do database, čímž tato cesta zneužití odpadá.

Generátor sestaví stránky ze šablon a obsahu při publikování; ruční psaní každého HTML souboru není nutné. Výsledek hostuje například GitHub Pages nebo Cloudflare Workers Static Assets. Cloudflare samotné statické soubory ukládá a obsluhuje zdarma; pro jednoduchý statický web tak může stačit bezplatný tarif v rámci limitů služby. Případné spouštění serverového kódu má vlastní limity a ceník.

Statická kopie webu sama neodstraní veřejně dostupné zranitelné PHP. Cache před WordPressem ani přípona .html nestačí. Zbývající administrace, PHP či externí formulářové API dál vyžadují údržbu. Chránit je potřeba také hosting, doménu, publikační účty, sestavovací nástroje a skripty v prohlížeči. Výhodou statického webu je méně veřejně dostupných součástí k průběžnému záplatování.

Odkazy jinam

PHP: nekompatibilní změny při přechodu na PHP 8.0 – příklady změn chování, které je potřeba při migraci otestovat.
PHP: zjištění verse PHP, rozhraní SAPI a sledování průběhu uploadu přes sessions.
Rector: sady pravidel pro automatické úpravy kódu.
WordPress: obrazovka Zdraví webu, konfigurace ve wp-config.php a postup při napadení webu.
Canadian Centre for Cyber Security: co dělat po napadení – isolace systému a uchování důkazů.
Britské ministerstvo školství: obnova provozu po incidentu.
MITRE: CWE-416: Use After Free – popis chyby, dopady a příklady z dalších programů.
Hugo: bezpečnostní model generátoru statických webů.
GitHub: co jsou GitHub Pages a jak hostují statické stránky.

PHP2Shell: co se stalo s PHP a proč aktualisovat