PHP2Shell: neautentizované RCE v PHP a jak zjistit, zda se týká vašich buildů

PHP2Shell jsou dvě kritické zranitelnosti přímo v PHP, CVE-2026-109618 a CVE-2026-109619, které mohou neautentizovanému webovému požadavku umožnit spustit kód v jakékoli instalaci PHP, která obsluhuje webové požadavky: PHP-FPM, Apache s mod_php, php-cgi, FrankenPHP a LiteSpeed. Obě jsou zneužívány v praxi a jsou v katalogu KEV od CISA. Opravou je PHP 8.5.12, 8.4.27, 8.3.36 nebo 8.2.35; PHP 8.1 a starší žádné vydání upstream nedostanou. Aktualizujte a pak znovu sestavte a nasaďte každou image kontejneru, která obsahuje PHP, včetně starých tagů, které stále běží, a image, které jste dodali zákazníkům.

Opravit server, o kterém víte, je ta snadná část. Expozice, která přetrvává, je PHP, na které jste zapomněli: runtime zkompilovaný do základní image, loňský tag image, který stále běží v produkci, image pro CI nebo produkt dodaný zákazníkům s PHP po konci podpory. Tato stránka vám nejdřív pomůže s opravou a pak ukáže, jak najít zbytek.

Co se stalo

Datum (2026)	Událost	Zdroj
11. a 21. srpna	Calif nahlásí obě chyby projektu PHP	Calif
17. října	První pokus o zneužití, který Amazon zaznamenal ve svých honeypotech, ještě před zveřejněním	Amazon Threat Intelligence
20. října	PHP ohlásí na 21. října, 14:00 UTC, bezpečnostní vydání, které opravuje dvě zranitelnosti se skóre CVSS 4.0 9,2	php.net
21. října	PHP vydá 8.5.12, 8.4.27, 8.3.36 a 8.2.35 a zveřejní bezpečnostní upozornění; záznamy CVE se zveřejní; NCSC-NL otevře repozitář php2shell	Upozornění PHP, NCSC-NL
21. října	Oficiální Docker image php jsou aktualizovány na opravené verze	docker-library/php
21. října	watchTowr nahlásí zneužívání obou CVE v praxi; CISA zveřejní výstrahu	watchTowr, CISA
22. října	Searchlight Cyber zveřejní php2shell-scanner	GitHub
23. října	PHP doporučí nastavit session.upload_progress.enabled=0 kvůli samostatnému, málo pravděpodobnému vektoru RCE, CVE-2026-115560	php.net
26. října	CISA přidá obě CVE do katalogu KEV s termínem 29. října pro federální úřady USA	CISA KEV

Název PHP2Shell pochází z rozboru od Calif a používá se napříč odbornými médii; vlastní bezpečnostní upozornění PHP ho nepoužívají. Záznamy CVE uvádějí zásluhy Calif, Wiz a OpenAI.

Koho se to týká

Jakéhokoli PHP, které obsluhuje webové požadavky. Bezpečnostní upozornění PHP jmenuje PHP-FPM, Apache s mod_php, php-cgi, FrankenPHP a LiteSpeed a riziko označuje za nejvyšší u mod_php, „s demonstrovaným exploitem, kdy neautentizovaný požadavek může spustit útok dříve, než se provede jakýkoli kód aplikace“. Protože chyby jsou přímo v PHP, aplikace postavené na Laravelu, Symfony nebo WordPressu jsou ohroženy vždy, když je ohrožené PHP pod nimi.

Větev	Dotčené	Opraveno ve	Podpora upstream
8.5	před 8.5.12	8.5.12	Aktivní
8.4	před 8.4.27	8.4.27	Aktivní
8.3	před 8.3.36	8.3.36	Jen bezpečnostní opravy, do 31. prosince 2027
8.2	před 8.2.35	8.2.35	Jen bezpečnostní opravy, do 31. prosince 2026
8.1, 8.0, 7.4	všechny verze, podle Calif a watchTowr	žádné vydání; minimální backporty zdrojového kódu v php-src	Konec podpory
7.3 a starší, včetně PHP 5	všechny verze, podle Calif a watchTowr	bez opravy upstream	Konec podpory

Bezpečnostní upozornění PHP uvádějí jen podporované větve. U starších Calif uvádí, že „nejstarší dotčená cesta, kterou jsme našli, sahá až k PHP 5.4.0“, a watchTowr uvádí PHP 7 a PHP 5 jako dotčené a bez opravy. PHP uvádí, že větve 8.1 a starší „už od projektu PHP nedostávají aktualizace“, ale pro ty, kdo sestavují ze zdrojového kódu, zveřejnilo minimální backporty pro 7.4, 8.0 a 8.1. Některé distribuce a komerční dodavatelé dlouhodobé podpory dodávají backportované opravy pro větve po konci podpory; zeptejte se toho svého. Pokud testujete další hlavní verzi, opravy obsahuje i PHP 8.6.0 RC4, vydané týž den.

Jak to funguje

Obě CVE jsou chyby bezpečnosti paměti ve způsobu, jakým PHP připravuje a ukončuje požadavek, pod veškerým kódem aplikace. Záznamy CVE obě klasifikují jako use after free (CWE-416) a k tomu jako nesprávné zpracování výjimečných stavů, přístup k neinicializovanému ukazateli, nekontrolovanou alokaci paměti a nesprávnou inicializaci (CWE-755, CWE-824, CWE-1325, CWE-1419). Slovy PHP:

• CVE-2026-109618, RCE přes poškození při nedostatku paměti (OOM): „zpracování nedostatku paměti může PHP přerušit ve chvíli, kdy jsou interní data požadavku inicializována jen částečně. Úklid po požadavku pak může s neplatnými daty zacházet jako s platnými.“ Toto ukončení může vyvolat tělo požadavku sestavené tak, aby během parsování v PHP vyčerpalo paměť. Apache s mod_php provádí úklid i tehdy, když spuštění požadavku selhalo, a proto tam útok funguje dříve, než se spustí jakýkoli kód aplikace. U PHP-FPM upozornění PHP uvádí, že analýza zdrojového kódu podporuje závěr, že je zranitelné, i když úplný exploit pro FPM předveden nebyl.
• CVE-2026-109619, RCE přes zastaralý globální stav: „interní stav patřící požadavku může přetrvat i poté, co byla uvolněna paměť, o kterou se opírá. Pozdější požadavek obsluhovaný stejným workerem může tento zastaralý stav použít dříve, než ho běžná inicializace resetuje.“ Jsou potřeba dva požadavky, které dorazí ke stejnému workeru: jeden, který stav zanechá, například fatální chybou, a druhý, který ho použije. Upozornění PHP potvrzuje cestu přes session upload progress u mod_php i FPM a cestu přes backtrace fatálních chyb v PHP 8.5 u mod_php.

Proto se dočasná nastavení PHP zaměřují na limity paměti, velikost těla požadavku, session upload progress a backtrace fatálních chyb: každé z nich uzavírá jednu cestu k chybám, ne chyby samotné. PHP jako CNA hodnotí obě v CVSS 4.0 skóre 9,2. Vlastní hodnocení NVD v CVSS 3.1 jsou 9,8 pro CVE-2026-109618 a 8,1 pro CVE-2026-109619.

Jak zjistit, zda jste dotčeni

Začněte hosty, o kterých víte, a pak hledejte PHP ve všem, co sestavujete a dodáváte.

Na hostu nebo virtuálním stroji zkontrolujte verzi, kterou PHP hlásí. Zkontrolujte i webové SAPI, protože php-fpm nebo modul Apache mohou pocházet z jiného balíčku než příkazová řádka:

php -v
php-fpm -v

Balíčky distribucí (Debian, Ubuntu, Alpine, RHEL) často dostávají opravu jako backport bez nové verze upstream: Ubuntu 24.04 například dodává opravu jako 8.3.6-0ubuntu0.24.04.13. Samotná kontrola verze tu klame. Vypište nainstalovaný balíček a porovnejte ho s opravenou verzí balíčku v bezpečnostním trackeru své distribuce:

dpkg -l 'php*' | grep '^ii'    # Debian, Ubuntu
apk info -v | grep '^php'      # Alpine
rpm -qa 'php*'                 # RHEL, Fedora, Rocky, Alma

V image kontejnerů. Oficiální image php: kompilují PHP ze zdrojového kódu, takže verze je uložená přímo v image, ne v seznamu balíčků distribuce. Zeptejte se přímo image:

docker run --rm --entrypoint php php:8.3-fpm -v

Chcete-li zkontrolovat každou image, kterou skutečně provozujete, vypište je a zeptejte se každé z nich. Pro Kubernetes:

kubectl get pods -A \
  -o jsonpath='{range .items[*]}{range .spec.containers[*]}{.image}{"\n"}{end}{end}' \
  | sort -u \
  | while read -r image; do
      version=$(docker run --rm --entrypoint php "$image" -r 'echo PHP_VERSION;' 2>/dev/null)
      printf '%s\t%s\n' "${version:-no php}" "$image"
    done

Image sestavené FROM debian nebo FROM alpine s PHP nainstalovaným správcem balíčků potřebují výše uvedenou kontrolu balíčků, spuštěnou uvnitř image.

Ve vašich repozitářích vyhledejte všechna místa, kde se PHP volí:

git grep -nE '^FROM[[:space:]]+(.*/)?php:' -- '*Dockerfile*' '*.dockerfile'
git grep -nE 'php-version|image:.*php' -- .github/workflows '*.yml' '*.yaml'

Připnuté tagy jako php:8.3.30-fpm zůstanou zranitelné, dokud je někdo nezmění. Plovoucí tagy jako php:8.3-fpm byly od 21. října znovu sestaveny s opravenými verzemi, ale image sestavená předtím si staré PHP ponechá, dokud ji znovu nesestavíte. Omezení php v composer.json říká, které verze váš kód přijímá, ne která skutečně běží.

V CI. Joby pro build a testy často používají vlastní PHP: kontejner služby php:, akci setup se vstupem php-version nebo image runneru. Neobsluhují produkční provoz, ale ukazují, jaké image a verze vaše pipeline vytváří.

Exponované hosty. php2shell-scanner od Searchlight Cyber testuje URL velkými multipart požadavky, zhruba 29 MiB na cestu. Spouštějte ho jen proti hostům, které máte oprávnění testovat. Jeho README varuje před falešně pozitivními nálezy u opraveného PHP s nízkým memory_limit, a když PHP svou verzi neprozrazuje, skener nedokáže opravený server odlišit od zranitelného. Berte ho jako vodítko, ne jako důkaz. Repozitář NCSC-NL shromažďuje detekční pravidla a seznam produktů, které obsahují PHP, s jejich stavem.

Co dnešní sken neřekne. Skenování image ve vašem registru dnes pokrývá to, co byste dnes nasadili. Nepokrývá dřívější vydání, které jste dodali zákazníkovi, starý tag, který zákazník stále provozuje, ani to, které z vašich buildů vytvořily image se zranitelným PHP. K tomu potřebujete záznam toho, co každý build obsahoval, pro každé vydání. Viz týká se nás to? Jak posoudit nové CVE napříč vašimi buildy.

Jak to opravit a co dělat, když zatím opravit nemůžete

1. Aktualizujte na 8.5.12, 8.4.27, 8.3.36 nebo 8.2.35, případně na opravený balíček své distribuce. Na 8.1 nebo starší přejděte na podporovanou větev; backporty PHP a buildy dodavatelů jsou jen provizorium.
2. Znovu sestavte každou image z opraveného základu (znovu stáhněte základní image nebo sestavujte bez cache) a znovu ji nasaďte. Image, které už běží, si staré PHP ponechají, dokud nejsou nahrazeny, takže restartujte i workloady.
3. Ověřte opravu podle kontrolního seznamu níže, a to na běžících kontejnerech, ne jen na nové image.

Pokud zatím aktualizovat nemůžete, bezpečnostní upozornění PHP uvádí opatření, která „snižují expozici vůči konkrétním cestám útoku, ale instalaci bezpečnou neudělají“. Pro CVE-2026-109618:

• „Nastavte memory_limit=-1, nejlépe způsobem, který aplikace nemohou přepsat, například php_admin_value v poolu FPM nebo v konfiguraci Apache, a zkontrolujte, že žádné nastavení poolu, adresáře ani aplikace konečný limit nevrací.“
• „U aplikací, které nevyžadují nahrávání souborů, nastavte post_max_size = 8M. Pokud je nahrávání souborů nutné, nastavte post_max_size = 32M. Udržujte upload_max_filesize pod post_max_size.“
• Jako hranici dostupnosti použijte limit paměti kontejneru nebo cgroup a nenahrazujte ho pomocí RLIMIT_AS ani RLIMIT_DATA, „protože ty mohou vyvolat zranitelné selhání alokace“.

Pro CVE-2026-109619:

• „Nastavte session.upload_progress.enabled=0 a restartujte každý worker. Použijte php.ini, pool FPM nebo konfiguraci serveru, která se uplatní před parsováním požadavku. Nespoléhejte na ini_set() ani na .user.ini u FPM.“
• „Na PHP 8.5 nastavte fatal_error_backtraces=0 a restartujte každý worker.“

Zkontrolujte, s jakými hodnotami každý worker skutečně běží:

php-fpm -i | grep -E 'memory_limit|post_max_size|session.upload_progress.enabled'

Výstraha CISA jde dál: organizace, které nemohou okamžitě aktualizovat nebo stále provozují PHP 8.1 či starší, „by měly systémy založené na PHP odpojit, dokud nebudou opraveny nebo aktualizovány“. Doporučuje také sledovat procesy workerů PHP, které spouštějí shelly nebo stahují nástroje.

Ověřte opravu

1. Ptejte se běžícího PHP, ne image, kterou jste chtěli nasadit. Spusťte php-fpm -v (nebo php -v) uvnitř každého běžícího kontejneru a na každém hostu a ověřte 8.5.12, 8.4.27, 8.3.36, 8.2.35 nebo novější.
2. U balíčků distribucí nevěřte jen řetězci verze. Debian, Ubuntu, RHEL a další distribuce opravu backportují do verze, kterou už dodávají, takže opravené PHP může stále hlásit 8.3.6: oprava pro Ubuntu 24.04 je 8.3.6-0ubuntu0.24.04.13. Porovnejte celou verzi balíčku s bezpečnostním trackerem své distribuce nebo hledejte CVE v changelogu balíčku, kde bývá obvykle uvedené. Past funguje i opačně: skener, který porovnává jen čísla verzí upstream, může backportovaný balíček označit za zranitelný.
3. Zkontrolujte, že každý workload běží na znovu sestavené image. Tag, který teď ukazuje na opravenou image, nezmění pod, který si stáhl tu starou. Porovnejte digest image, na které každý kontejner běží, s digestem, který jste sestavili:

kubectl get pods -A \
  -o jsonpath='{range .items[*]}{range .status.containerStatuses[*]}{.image}{"\t"}{.imageID}{"\n"}{end}{end}'

4. Zkontrolujte, že se každý worker restartoval. PHP-FPM a Apache drží starý kód načtený až do restartu; kontrola procesů v části „Zkontrolujte, zda nedošlo ke kompromitaci“ ukáže všechny, které ho stále spouštějí.
5. Pokud stále spoléháte na dočasná nastavení, zkontrolujte každý pool výše uvedeným příkazem php-fpm -i a ponechte je, dokud nebude aktualizace hotová všude.
6. Znovu proveďte inventuru podle části o kontrole, napříč registrem, image pro CI a vydáními, která provozují zákazníci, nejen v produkci.

Zkontrolujte, zda nedošlo ke kompromitaci

PHP2Shell je zneužívána v praxi a Amazon zaznamenal první pokus 17. října 2026, čtyři dny před opravou. Pokud kdykoli od té doby běželo PHP dostupné z internetu v dotčené verzi bez dočasných nastavení, zkontrolujte ho.

Jak velká je expozice. Počty bannerů ze Shodanu, které 20. října zveřejnil Mallory a o kterých informoval CybelAngel, ukázaly 2,24 milionu hostů dostupných z internetu, které ohlašují PHP; z přibližně 1,5 milionu, které ukazují verzi, jich 883 717 (59 %) provozuje větev bez oficiální opravy. Jde o počty hostů, ne potvrzených zranitelných systémů: backportované balíčky mohou vypadat staře, a přitom být opravené, a zhruba 740 000 hostů svou verzi skrývá.

Zařízení a produkty, které obsahují PHP. PHP běží i uvnitř appliance, síťových zařízení, správních rozhraní a produktů dodavatelů, kde ho možná sami aktualizovat nemůžete. Inventář NCSC-NL sledoval 9. listopadu 2026 968 takových produktů: 205 opravených, 215 zranitelných, 93 v šetření, 240 závislých na runtime a 214 nedotčených. Tyto produkty kontrolujte zvlášť a aktualizace od dodavatelů nasazujte, jakmile budou k dispozici.

Ověřte, že oprava opravdu běží. Na hostech a virtuálních strojích proces PHP-FPM, php-cgi nebo Apache, který se spustil před aktualizací, stále spouští starý kód. Jeho mapa paměti pak ukazuje nahrazenou binárku nebo libphp jako smazanou. Porovnejte také časy spuštění procesů s časem aktualizace:

for pid in $(pgrep -f 'php-fpm|php-cgi|apache2|httpd|frankenphp'); do
  grep -qE '(php|libphp)[^/]*\(deleted\)' "/proc/$pid/maps" 2>/dev/null \
    && echo "PID $pid still runs a replaced PHP"
done
ps -o pid,lstart,args -p "$(pgrep -d, -f 'php-fpm|php-cgi|apache2|httpd|frankenphp')"

Indikátory z primárních zdrojů:

• Požadavky: požadavky POST s nahráváním formulářů obsahující řetězec PHP_SESSION_UPLOAD_PROGRESS, které Amazon Threat Intelligence zaznamenal při pokusech o zneužití. Amazon uvádí i zdrojové adresy (103.216.220.92, 31.223.184.166, 37.19.200.5, 134.209.159.64, 103.114.163.188, 95.217.98.37), ale upozorňuje, že patří ke sdílené anonymizační infrastruktuře: shodu prošetřete, nepovažujte ji za důkaz.
• Procesy a soubory: procesy workerů PHP, které spouštějí shelly nebo stahují nástroje (CISA, která 23. října přidala detekční pravidlo Sigma), a neočekávané spouštění procesů nebo změny souborů na webových serverech (Amazon).
• Logy: v logech Apache, PHP-FPM, reverzní proxy a služeb opakovaná varování nebo chyby jádra před spuštěním skriptů, fatální chyby a chyby parsování a Maximum execution time exceeded. Upozornění PHP dodává, že „absence chyby v logech není důkazem bezpečnosti“.

Kdy předpokládat kompromitaci. Pokud najdete kterýkoli z těchto indikátorů, nebo pokud exponovaný server provozoval dotčené PHP bez zmírňujících opatření a vaše logy zneužití nevylučují, považujte ho za kompromitovaný. PHP popisuje dopad jako vzdálené spuštění kódu pod účtem webového workeru a tento účet obvykle může číst konfiguraci a tajné klíče aplikace.

Vyměňte vše, co mohl worker přečíst. Hesla k databázím, klíče API a tokeny v proměnných prostředí a konfiguračních souborech, klíče, které podepisují session nebo cookies (a session jimi podepsané), a jakékoli cloudové přihlašovací údaje dostupné hostu. Vyměňte je až po novém sestavení hostu, aby nové tajné klíče nikdy neležely na kompromitovaném stroji.

Sestavte znovu, místo abyste čistili. Kompromitovaný host nebo kontejner nahraďte z ověřené image a nepřenášejte soubory, do kterých mohl worker zapisovat, jako jsou adresáře pro nahrávání, cache nebo generovaný kód. Nepoužívejte znovu image, cache buildů ani artefakty vytvořené na kompromitovaném hostu.

Co říct zákazníkům

Pokud dodáváte software, který běží na PHP, vaši zákazníci se budou ptát. Odpovězte verzemi a kroky, i když ještě nemáte všechny odpovědi. Odpověď, kterou si můžete upravit:

PHP2Shell (CVE-2026-109618, CVE-2026-109619) se týká verzí PHP starších než 8.5.12, 8.4.27, 8.3.36 a 8.2.35 a všech starších větví PHP. [Produkt] ve verzích [x až y] obsahuje PHP [verze] a je dotčen; verze [z], vydaná [datum], obsahuje PHP [opravená verze]. Aktualizujte prosím na [z]. Pokud nemůžete aktualizovat hned, použijte nastavení PHP z našeho bezpečnostního upozornění [odkaz] a omezte síťový přístup k aplikaci. [Produkt] ve verzích [a až b] dotčen není. Toto oznámení aktualizujeme do [datum].

Pokud stále prověřujete, řekněte to a uveďte, kdy odpovíte. První předběžné vyjádření a šablony pro každý výsledek najdete v článku jak odpovídat zákazníkům po útoku na dodavatelský řetězec.

Jak pomáhá CRACI

CRACI spouští vaše joby GitHub Actions a během buildu zaznamenává, co každý job stahuje, včetně image kontejnerů, balíčků apt a apk a balíčků Composer, a uchovává každý minulý build s jeho SBOM. Když vyjde nové CVE, průběžné přehodnocování označí minulé buildy, které dotčený balíček obsahovaly, takže vidíte, která vydání byla ohrožená a jak dlouho, ne jen to, co najde dnešní sken. Kontrolní brány politik mohou blokovat buildy, které obsahují konkrétní CVE.

Jedno omezení u tohoto incidentu: PHP zkompilované do oficiální image php: přichází uvnitř image, ne jako stažený balíček. CRACI zaznamenává referenci image, kterou každý build stáhl, takže ve svých buildech hledejte tagy php: i balíčky PHP.

Najděte každý build, který dodal zranitelné PHP

Více o záznamech buildů: SBOM z doby buildu, SBOM pro Docker image, co skenování kontejnerů přehlíží, katalog CISA KEV a trendy ve zveřejňování CVE. Další incidenty: všechny zranitelnosti.

Bezpečnost PHP nad rámec tohoto incidentu popisuje náš průvodce bezpečností PHP.

Zdroje a aktualizace

Primární zdroje:

• PHP: bezpečnostní upozornění z 21. října 2026, informativní upozornění z 23. října 2026, GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp, podporované verze
• Záznamy CVE: CVE-2026-109618, CVE-2026-109619
• CISA: výstraha z 21. října 2026, katalog KEV
• NCSC-NL: repozitář php2shell
• NVD: CVE-2026-109618, CVE-2026-109619
• FIRST: skóre EPSS

Výzkum a analýzy:

• Calif: PHP2Shell, a tale of two PHP remote vulnerabilities
• Amazon Threat Intelligence
• watchTowr
• Akamai
• CybelAngel
• Searchlight Cyber php2shell-scanner

Aktualizace:

• 2026-11-11: Do přehledu přidána skóre NVD, EPSS, třídy CWE, zásluhy, nejnovější bezpečné verze a data konce podpory, dále PHP 8.6.0 RC4 a sekce o tom, jak chyby fungují, jak ověřit opravu a jak zkontrolovat kompromitaci.
• 2026-11-11: První zveřejnění.