PHP2Shell: dvě kritické chyby v PHP umožňují spustit kód na serveru bez přihláš…

Co se stalo

PHP je programovací jazyk, na kterém běží většina webů včetně WordPressu, Drupalu, e-shopů a mnoha firemních aplikací. V jeho jádru byly nalezeny dvě kritické zranitelnosti s označením CVE-2026-109618 a CVE-2026-109619, kterým se říká PHP2Shell. Obě mohou útočníkovi z internetu umožnit spustit na serveru vlastní kód bez jakéhokoli přihlášení.

Tým PHP vydal opravy 21. října 2026 ve verzích 8.2.35, 8.3.36, 8.4.27 a 8.5.12. Technické podrobnosti unikly na veřejnost ještě před vydáním oprav a brzy poté začaly kolovat ukázky útoku. Podle The Hacker News potvrdil výzkumník Adel Karimi ze společnosti Perplexity 24. října 2026 úspěšné útoky na návnadové servery. Americká agentura CISA zařadila 26. října 2026 obě chyby do katalogu aktivně zneužívaných zranitelností.

Na zranitelnosti upozorňuje slovenský SK-CERT, český NÚKIB i evropský CERT-EU. Podle NÚKIB jsou veřejně dostupné i informace umožňující jejich zneužití. Palo Alto Networks hlásí aktivní útoky na správcovské webové rozhraní firewallů s PAN-OS dostupné z internetu, které na pozadí používá PHP.

Proč je to nebezpečné

Obě chyby patří do skupiny „použití po uvolnění“ (use-after-free). Představte si hotel, kde host odjede, pokoj uklidí a přidělí dalšímu hostovi, ale v knize na recepci zůstane starý záznam. Kdo ho později použije, vstoupí do cizího pokoje. V PHP takto zůstane odkaz na paměť, kterou už mezitím může ovládat útočník.

U CVE-2026-109618 PHP násilně ukončí požadavek, který vyčerpá paměťový limit. Pokud k tomu dojde v nevhodnou chvíli, například při zpracování formuláře s nahrávaným souborem, zůstanou po něm napůl připravená data a PHP s nimi při úklidu zachází jako s platnými. U CVE-2026-109619 zůstanou po předchozím požadavku vnitřní záznamy PHP, které ukazují do už uvolněné paměti. Další požadavek, který obslouží stejný proces, je pak použije.

Útočník nepotřebuje přihlášení, stačí mu posílat upravené požadavky přes internet. U CVE-2026-109618 a Apache s mod_php k tomu podle týmu PHP dochází ještě před spuštěním jakéhokoli kódu aplikace, takže nezáleží na tom, jaký web na serveru běží. U CVE-2026-109619 tým PHP předvedl útok na Apache s mod_php i PHP-FPM. Úspěšnost útoku závisí na konfiguraci, rozšířeních a aplikaci. Útočník pak může spouštět kód s právy účtu webového serveru a pracovat se vším, k čemu má web přístup, například s konfiguračními soubory nebo obsahem webu.

Skóre CVSS hodnotí závažnost na stupnici od 0 do 10. Databáze NVD uvádí 9,8 pro CVE-2026-109618 a 8,1 pro CVE-2026-109619, tým PHP hodnotí obě chyby podle CVSS 4.0 na 9,2. Katalog CISA KEV obsahuje jen chyby, které útočníci prokazatelně zneužívají. EPSS odhaduje pravděpodobnost zneužití v příštích 30 dnech a u obou chyb je téměř na maximu stupnice.

Koho se to týká

PHP 8.2 před verzí 8.2.35, PHP 8.3 před 8.3.36, PHP 8.4 před 8.4.27 a PHP 8.5 před 8.5.12
nepodporované větve PHP 8.1 a starší, které už od projektu PHP nedostávají běžné aktualizace (podle slovenského SK-CERT jsou zranitelné všechny verze od PHP 5.0)
zařízení a produkty, které PHP obsahují ve svém správcovském rozhraní

Podle CERT-EU je ohrožena každá instalace PHP, která obsluhuje webové požadavky: Apache s mod_php (podle týmu PHP nejrizikovější), PHP-FPM, php-cgi, FrankenPHP i LiteSpeed. Typicky jde o webhostingy, firemní weby a e-shopy, intranetové aplikace a služby v kontejnerech Docker.

PHP se skrývá i v zařízeních. U PAN-OS (firewally PA-Series, VM-Series a Panorama) je zasaženo jen správcovské webové rozhraní, GlobalProtect ne. Cisco mezi zasaženými produkty uvádí Expressway, Duo Access Gateway, Ultra-Reliable Wireless Backhaul a ISE Portal Builder. Vlastní upozornění vydali i další výrobci, například Citrix, QNAP, Synology nebo Veeam. Pozor, aktualizace WordPressu, pluginu či frameworku nestačí. Opravit je potřeba samotné PHP.

Jak zjistit, zda jste zasaženi

Na webhostingu najdete verzi PHP v administraci hostingu v nastavení webu, případně se zeptejte poskytovatele, zda už nasadil opravené PHP. Na vlastním serveru použijte následující příkazy. Nic nemění, pouze čtou. Příkaz dpkg je pro Debian a Ubuntu, rpm pro Red Hat, AlmaLinux a podobné systémy.

php -v

dpkg -l | grep -i php

rpm -qa | grep -i php

apachectl -M | grep -i php

docker exec <kontejner> php -v

Verze na příkazové řádce se může lišit od verze, kterou používá web. Linuxové distribuce navíc opravu často doplní bez změny čísla verze PHP. U balíčků z distribuce proto porovnejte verzi balíčku s bezpečnostním oznámením své distribuce. U zařízení (PAN-OS, Cisco a další) zjistěte verzi firmwaru v jejich administraci a porovnejte ji s upozorněním výrobce.

Jak to opravit

Aktualizace je jedinou spolehlivou opravou. Postupujte v tomto pořadí:

Nejprve řešte servery a správcovská rozhraní dostupná z internetu, teprve potom interní systémy.
Aktualizujte PHP na 8.2.35, 8.3.36, 8.4.27 nebo 8.5.12, případně novější verzi ve stejné větvi. Linuxové distribuce dostaly opravy předem, použijte jejich balíčky. Dobrovolnický repozitář remirepo opravy v den vydání neměl.
Restartujte všechny procesy PHP (PHP-FPM, Apache s mod_php). Kontejnery sestavte znovu z opraveného základního image, samotný restart nestačí.
Ověřte verzi postupem z předchozí sekce.
Na webhostingu si opravu nechte potvrdit od poskytovatele.
U zařízení nasaďte opravy výrobce a správcovské rozhraní zpřístupněte jen z důvěryhodných interních adres.
Staré větve PHP nahraďte podporovanou verzí nebo použijte opravu (backport) od distribuce. Tým PHP zveřejnil i zdrojové záplaty pro PHP 7.4, 8.0 a 8.1.

Pokud nemůžete aktualizovat hned, dočasná opatření sníží riziko, ale nejsou úplnou ochranou. V php.ini nebo v konfiguraci FPM poolu nastavte následující hodnoty a restartujte všechny workery (nastavení přes ini_set() ani .user.ini nefunguje):

session.upload_progress.enabled = 0
fatal_error_backtraces = 0

Oba řádky blokují potvrzené cesty útoku přes CVE-2026-109619, druhý platí jen pro PHP 8.5. U CVE-2026-109618 tým PHP jako hlavní opatření doporučuje napevno nastavit memory_limit=-1 přes php_admin_value, aby ho aplikace nemohla změnit. Dále snižte post_max_size na 8M, pokud web nenahrává soubory, jinak na 32M. Pokud web formuláře se soubory nepotřebuje, blokujte požadavky multipart/form-data už na proxy. Když systém nejde rychle opravit, odpojte ho od internetu.

23. října 2026 oznámil tým PHP další chybu CVE-2026-115560, která se týká jen neobvykle nastavených aplikací. Mimořádné vydání kvůli ní nebude. Do příštího běžného vydání před ní chrání session.upload_progress.enabled=0.

Co když už jste mohli být napadeni

Pokud server běžel se zranitelnou verzí a byl dostupný z internetu, počítejte s tím, že mohl být napaden. Kód útočníka běží pod účtem webového serveru. Podle NÚKIB mohou na pokus o útok ukazovat neobvyklé procesy spouštěné službami PHP. Sledujte hlavně:

neobvyklé procesy spuštěné službami PHP nebo webového serveru, například shell či neznámé programy
opakované pády PHP nebo webového serveru a vyčerpání paměti v chybových lozích
velké množství objemných požadavků s formuláři a soubory v přístupových lozích
nové nebo změněné soubory PHP ve webovém adresáři a neznámé účty v administraci webu

ps -ef --forest | grep -E -A5 'php-fpm|apache2|httpd'

zgrep -iE 'segfault|SIGSEGV|segmentation fault|Allowed memory size' /var/log/apache2/error.log* /var/log/php*-fpm.log*

journalctl -k | grep -i segfault

find /var/www -type f -name '*.php' -mtime -14 -ls

Na Red Hat a podobných systémech použijte v příkazu zgrep cesty /var/log/httpd/error_log* a /var/log/php-fpm/*. Samotná aktualizace útočníka ze serveru nevyžene. Pokud najdete stopy útoku, odpojte server od sítě, uložte logy mimo něj a přizvěte odborníka na řešení incidentů. Změňte hesla k databázím a klíče, které byly na serveru uloženy.

Zdroje

Články sestavuje AI agent z veřejných zdrojů (výrobci, CISA, ENISA, NVD, NÚKIB, SK-CERT) a čísla verzí i CVE proti nim automaticky ověřuje. Před zásahem do produkce si postup vždy ověřte v bulletinu výrobce.

PHP2Shell: dvě kritické chyby v PHP umožňují spustit kód na serveru bez přihlášení