PHP2Shell: kritická zranitelnost v PHP a jak se bránit
Dvě kritické RCE chyby v samotném PHP (CVE-2026-109618 a CVE-2026-109619) ohrožují téměř každý PHP server. Co se stalo, koho se to týká a co udělat hned.
Log4Shell v Javě, React2Shell v React Server Components a teď PHP2Shell. Tentokrát chyba nesedí v knihovně ani ve frameworku, ale přímo v interpretu PHP, tedy ve vrstvě, na které běží WordPress, Laravel, Symfony, Nette i většina e-shopů. PHP tým 21. října 2026 vydal mimořádné bezpečnostní verze a doporučuje okamžitou aktualizaci všem.
V článku shrnuji, co o zranitelnosti zatím víme, koho se týká a jak postupovat, pokud nemůžete aktualizovat hned.
Co je PHP2Shell#
PHP2Shell je souhrnné označení pro dvě zranitelnosti, které umožňují vzdálené spuštění kódu (RCE) bez přihlášení. Obě dostaly skóre CVSS 9.2 (v4.0) a nahlásili je výzkumníci ze společností Calif, OpenAI a Wiz.
| CVE | Typ | Co se děje |
|---|---|---|
CVE-2026-109618 |
RCE přes poškození při nedostatku paměti | Ošetření chyby „out of memory“ přeruší PHP ve chvíli, kdy jsou interní data požadavku inicializovaná jen napůl. Úklid na konci požadavku je pak považuje za platná. |
CVE-2026-109619 |
RCE přes zastaralý globální stav | Interní stav požadavku přežije uvolnění paměti, na kterou ukazuje. Další požadavek obsloužený stejným workerem ho použije dřív, než se stihne znovu inicializovat. |
Wiz je označuje za jedny z nejzávažnějších zranitelností, jaké kdy byly v PHP objeveny. A není to přehnané: útok nepotřebuje žádnou chybu ve vaší aplikaci.
Proč je to tak vážné#
Když PHP narazí na fatální chybu, třeba na překročení memory_limit, nedokončí rozpracovanou operaci, ale „vyskočí“ z ní (interně přes longjmp()) rovnou do ošetření chyby. Pokud k tomu dojde ve špatnou chvíli, například poté, co PHP někam uložilo ukazatel, ale ještě před úklidem, zůstane v paměti workeru neplatný stav.
Samo o sobě by to znamenalo nanejvýš pád jednoho procesu. Jenže PHP-FPM i Apache s mod_php používají jeden worker pro mnoho po sobě jdoucích požadavků. Útočník tak prvním požadavkem paměť „rozbije“ a dalším ji zneužije, typicky jako use-after-free, kdy si PHP splete data útočníka se svými interními strukturami.
Nejnepříjemnější je, kde k tomu může dojít. Podle analýzy Impervy funkce session.upload_progress zapisuje do session už během parsování multipart těla požadavku, tedy dřív, než se spustí jediný řádek vaší aplikace. Nepomůže tedy validace vstupů, firewall ve frameworku ani to, že máte „čistý“ kód. Podobně se dá zneužít i cache tříd v OPcache ve sdílené paměti.
Pro úplnost: zneužití není triviální. Útok má vysokou složitost a neúspěšný pokus často jen shodí worker. To je ale slabá útěcha, když je exploit už venku.
Koho se to týká#
Podle oficiálního oznámení všech instalací PHP, které obsluhují webové požadavky:
- PHP-FPM (Nginx, Caddy, Apache s
proxy_fcgi), - Apache s
mod_php, kde PHP tým vidí nejvyšší riziko - existuje funkční exploit, který zabere jediným neautentizovaným požadavkem, php-cgi, FrankenPHP a LiteSpeed.
Které větve jsou zasažené, oficiální oznámení výslovně neuvádí. Část médií píše o všech verzích od PHP 5 výš, to ale zatím nikdo oficiálně nepotvrdil. Prakticky to nehraje roli: opravu dostaly jen podporované větve, takže starší verze berte jako zranitelné.
Pozor i na „krabicová“ zařízení. Palo Alto Networks 22. října potvrdilo, že zasažené jsou všechny verze PAN-OS a Panorama, Cisco a Fortinet své produkty teprve prověřují. PHP běží i tam, kde ho nečekáte: v administraci routerů, NAS, firewallů nebo starších interních systémů.
Je to už zneužívané?#
Ano. Detaily zranitelností unikly ještě před koordinovaným zveřejněním. Honeypot Amazonu (MadPot) zachytil pokus o zneužití už 17. října, čtyři dny před vydáním oprav. Cloudflare i watchTowr potvrzují útoky v reálném provozu a britské NCSC doporučuje servery, které nejde hned opravit, zvážit odpojit od internetu.
Co dělat hned#
1. Aktualizujte PHP#
Opravené verze jsou:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
Linuxové distribuce a LTS dodavatelé dostali opravy s předstihem, takže na většině serverů stačí běžná aktualizace balíčků. Ověřte si ale, že se po ní opravdu restartovaly všechny procesy PHP-FPM, případně Apache. Starý worker v paměti zůstává zranitelný i s novou binárkou na disku.
Pokud používáte repozitář rpms.remirepo.net, PHP tým doporučuje přejít na balíčky distribuce nebo kompilaci ze zdrojáků, protože repozitář v den zveřejnění aktualizace neměl.
U Dockeru nestačí docker pull: musíte znovu sestavit image na novém base image a nasadit ho.
2. PHP 8.1 a starší#
Tyto verze už PHP projekt oficiálně nepodporuje. Vzhledem k závažnosti ale tým vydal minimální zdrojové backporty pro PHP 7.4, 8.0 a 8.1. Některé distribuce a LTS dodavatelé nabízejí opravené balíčky, zeptejte se svého hostingu. Pro PHP 5 oprava neexistuje.
Pokud ještě provozujete aplikaci na nepodporované verzi PHP, je teď nejlepší chvíle naplánovat migraci. Další taková zranitelnost přijde a oprava pro starou verzi už vyjít nemusí.
3. Pokud nemůžete aktualizovat okamžitě#
Následující opatření podle PHP týmu snižují riziko u konkrétních známých cest útoku, ale instalaci nezabezpečí. Jsou to záplaty na pár hodin, ne řešení.
Proti CVE-2026-109618 (poškození při nedostatku paměti):
- Nastavte
memory_limit=-1tak, aby ho aplikace nemohla přepsat, ideálně přesphp_admin_valuev FPM poolu nebo v konfiguraci Apache. Zkontrolujte, že žádný pool, adresář ani aplikace nevrací konečný limit. - Snižte
post_max_size: na8Mu aplikací bez nahrávání souborů, na32Mtam, kde upload potřebujete.upload_max_filesizedržte podpost_max_size. - Omezte velikost požadavků, počet polí, multipart částí a hlaviček už na úrovni webového serveru nebo proxy, a to i pro požadavky bez platné hlavičky
Content-Length. - Paměť hlídejte limitem kontejneru nebo cgroup, ideálně s politikou, která ukončí jen postižený worker. Nepoužívejte
RLIMIT_ASaniRLIMIT_DATA, ty naopak mohou zranitelnou chybu vyvolat.
Proti CVE-2026-109619 (zastaralý globální stav):
- Nastavte
session.upload_progress.enabled=0vphp.ini, FPM poolu nebo konfiguraci serveru a restartujte všechny workery.ini_set()ani.user.ininestačí, nastavení musí platit už před parsováním požadavku. - Na PHP 8.5 nastavte
fatal_error_backtraces=0a opět restartujte workery. - Odstraňte neplatná nebo zastaralá nastavení aplikovaná pro jednotlivé požadavky, která vypisují diagnostiku ještě před inicializací. Skrývání chyb přes
error_reporting,display_errorsnebo@nepomáhá. - Opravte fatální chyby a timeouty, které může útočník vyvolat, včetně callbacků, zpracování uploadů a importů.
Imperva navíc zmiňuje dočasné vypnutí opcache.enable = 0. Počítejte ale s výrazným propadem výkonu, takže ho nejdřív vyzkoušejte mimo produkci.
Pokud jste za Cloudflare, WAF pravidla proti známým vektorům jsou aktivní pro všechny zákazníky včetně bezplatného tarifu. Je to užitečná vrstva navíc, ne náhrada aktualizace.
4. Zkontrolujte, jestli už nejste kompromitovaní#
Exploit koloval dřív než oprava, takže samotný update nestačí. Projděte logy za poslední dny a hledejte:
- chyby
Allowed memory size exhausteda pády workerů (SIGSEGV), zvlášť v kombinaci s neobvykle velkými multipart požadavky nebo velkým počtem polí, - podezřele dlouhé hodnoty
PHPSESSIDv odpovědích, - neočekávané podprocesy spuštěné uživatelem webového serveru, změněné soubory aplikace, nové cron úlohy nebo webshelly,
- neobvyklá odchozí spojení ze serveru.
Pokud najdete stopy útoku, nestačí opravit PHP. Útočník měl práva webového serveru, takže vyměňte hesla k databázi, API klíče a další tajemství, ke kterým měl přístup, a zvažte reinstalaci serveru z čistého stavu.
Co si z toho vzít#
PHP2Shell je připomínka, že bezpečnost aplikace nekončí u vlastního kódu. Můžete mít dokonale ošetřené vstupy, a stejně vás shodí chyba o vrstvu níž. Proto se vyplatí:
- mít přehled o tom, kde všude PHP běží - včetně zapomenutých subdomén, testovacích prostředí a zařízení v síti,
- umět aktualizovat rychle - z automatizovaného nasazení a reprodukovatelných Docker image je oprava otázka minut, ne dní,
- nezůstávat na nepodporovaných verzích - tentokrát dostaly backport i 7.4 a 8.1, příště to být nemusí,
- omezit dopad průniku - webový server s minimálními právy, oddělená tajemství a sledování odchozího provozu.
Pokud si nejste jistí, jestli jsou vaše servery opravené, nebo potřebujete pomoct s aktualizací starší aplikace, ozvěte se. Podívejte se, jak probíhá můj bezpečnostní audit, nebo co nabízím v oblasti PHP backendu. První konzultace je zdarma.
Zdroje: oficiální oznámení PHP, BleepingComputer, Help Net Security, Imperva, watchTowr, Cloudflare.
Mohlo by vás zajímat


Hybridní vývojář: Jak kloubím rychlost AI s nekompromisní bezpečností
V roce 2026 už není otázkou, zda AI používat, ale jak ji krotit. Sdílím svůj pohled na to, proč je můj dohled kritický pro bezpečnost vašich dat.


Říše počtů: Vzdělávací hra, ve které vesnice roste s každým příkladem
Vzdělávací hra zdarma pro děti od 1. do 6. třídy. Bez reklam, nákupů i chatu - dítě počítá za dělníky ve vesnici a za správné výsledky vesnice roste.


Kolik opravdu stojí vývoj s AI: rozpočet, který vám nikdo neukáže
AI slibuje levnější vývoj. Ukazuji, kam se náklady ve skutečnosti přesunuly - od tokenů přes code review až po technický dluh, který se platí až za rok.
Líbí se vám tento článek?
Pojďme společně pracovat na vašem projektu. Nabízím konzultace i kompletní vývoj.