Přeskočit na hlavní obsah
Radek HřebečekTvůrce digitálních řešení

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.

Radek Hřebeček7 min čtení

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=-1 tak, aby ho aplikace nemohla přepsat, ideálně přes php_admin_value v FPM poolu nebo v konfiguraci Apache. Zkontrolujte, že žádný pool, adresář ani aplikace nevrací konečný limit.
  • Snižte post_max_size: na 8M u aplikací bez nahrávání souborů, na 32M tam, kde upload potřebujete. upload_max_filesize držte pod post_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_AS ani RLIMIT_DATA, ty naopak mohou zranitelnou chybu vyvolat.

Proti CVE-2026-109619 (zastaralý globální stav):

  • Nastavte session.upload_progress.enabled=0 v php.ini, FPM poolu nebo konfiguraci serveru a restartujte všechny workery. ini_set() ani .user.ini nestačí, nastavení musí platit už před parsováním požadavku.
  • Na PHP 8.5 nastavte fatal_error_backtraces=0 a 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_errors nebo @ 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 exhausted a pády workerů (SIGSEGV), zvlášť v kombinaci s neobvykle velkými multipart požadavky nebo velkým počtem polí,
  • podezřele dlouhé hodnoty PHPSESSID v 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.

Další krok

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.