PHP2Shell: co dělat po CVE-2026-109618 a CVE-2026-109619

PHP2Shell: co dělat na svém serveru po CVE-2026-109618 a CVE-2026-109619

21. října 2026 vydal tým PHP nouzové aktualizace na dvě kritické zranitelnosti v jádru jazyka: CVE-2026-109618 a CVE-2026-109619. Obě mají skóre 9.2 podle CVSS v4.0, obě umožňují neautentizované vzdálené spuštění kódu a obě se netýkají konkrétní aplikace, ale samotného enginu PHP. Dvojice už dostala neformální jméno PHP2Shell.

Podrobnosti se dostaly na veřejnost dřív, než byly vydány opravy. Podle výzkumníků se na internetu už objevují pokusy o zneužití. Zároveň k okamžiku publikace nejsou hlášeny potvrzené úspěšné útoky, i když se to má brzy změnit. Takže nejde o "velký kompromitační incident, který se už stal", ale o okamžik, kdy útočníci mají funkční nástroj a administrátoři ještě mají čas dveře zavřít. Rozestup mezi těmito dvěma stavy se počítá na hodiny.

Tento článek není shrnutím novinek. Je to pracovní akční plán pro každého, kdo odpovídá za VPS nebo vyhrazený server: jak najít všechny instance PHP na stroji (obvykle je jich víc, než byste čekali), jak správně aktualizovat, co dělat, když okamžitá aktualizace nejde, a jak zkontrolovat, zda už k vám nikdo nepřišel. Kontejnery probereme samostatně, protože tento příběh má v Docker stacích svá specifika.

2. Co je o zranitelnostech známo

2.1 Dvě chyby, jeden výsledek

Výzkumníci popisují mechanismus s mírně odlišným důrazem (někteří jednu z chyb spojují s obslužnou rutinou upload-progress v relacích), ale praktický závěr je stejný: zranitelnost sedí ve vnitřním zpracování požadavků v PHP. Zneužití nevyžaduje zranitelný plugin ani formulář pro upload souborů ve vaší aplikaci. Útok putuje přes HTTP požadavky typu multipart/form-data a podle výzkumníků se může spustit dřív, než se k slovu vůbec dostane kód vašeho webu.

2.2 Co to znamená pro ochranu aplikace

Obvyklá reakce "aktualizovali jsme WordPress a pluginy" tady nefunguje. Zranitelný je samotný interpretr, takže nepomůže ani plugin WAF v CMS, ani režim údržby: PHP požadavek zpracuje ještě dřív, než ho aplikace dostane k posouzení. Jediný způsob, jak problém plně uzavřít, je aktualizace PHP.

2.3 Které konfigurace jsou ohrožené

Podle analytiků je ohrožený každý způsob zpracování webových požadavků: PHP-FPM, Apache s mod_php, php-cgi, FrankenPHP a LiteSpeed. Nejvyšší riziko se přiřazuje mod_php, protože tam se exploit může spustit nejdříve. To neznamená, že FPM je bezpečné; je to jen pořadí priorit pro situaci, kdy není čas pokrýt všechny servery najednou.

2.4 Opravené verze a ty bez opravy

Pro větve 7.4, 8.0 a 8.1 projekt publikoval minimální backport patche jako zdrojový kód, vhodné pro ty, kdo si PHP sestavují sami. Některé distribuce a dodavatelé dlouhodobé podpory (CloudLinux, Ubuntu ESM a další) dodávají vlastní opravené balíčky pod starými číslami verzí, takže u distribučních balíčků se nespoléhejte jen na číslo verze: zkontrolujte poznámky k balíčku (changelog) vašeho dodavatele.

3. "My PHP nemáme": proč tuto odpověď stojí za to prověřit

Nejčastější první reakce na takovou zprávu zní: "náš hlavní produkt je napsaný v jiném jazyce, tohle se nás netýká." Pro hlavní produkt to často platí. Na reálném serveru se ale PHP má tendenci objevovat tam, kde to nečekáte. Bezpečnostní výzkumníci upozorňují, že počet míst, kde je potřeba hledat zranitelné verze PHP, roste velmi rychle.

3.1 Kde se PHP nejčastěji skrývá

• Administrační nástroje. phpMyAdmin, Adminer, webmailové klienty jako Roundcube, monitorovací dashboardy, staré hostingové panely.
• Fakturace a CRM. WHMCS a podobné systémy, skladové systémy (DCIM), fóra, interní wiki.
• Staré stránky. "Dočasná" landing page, nasazená před třemi lety a zapomenutá, ale stále dostupná z venku.
• Kontejnery. Image, kde je PHP jen závislostí jednoho build skriptu nebo nástroje.
• Cizí projekty na vašem serveru. Vlastní projekty klientů nebo dodavatelů, za které administrátor formálně nenese odpovědnost, ale které běží na stejném stroji.

3.2 Proč je "kontrola jen čtením" správný přístup

Úvodní fáze nevyžaduje na serveru žádné změny: verze, procesy, balíčky, image, logy. Je bezpečná, rychlá a je to smysluplný začátek dřív, než se cokoliv restartuje nebo aktualizuje.

4. Krok 1: najít všechny instance PHP na serveru

4.1 Balíčky a verze na hostu

php -v
php-fpm -v 2>/dev/null || ls /usr/sbin | grep php-fpm
apachectl -M 2>/dev/null | grep -i php
dpkg -l | grep -i php      # Debian / Ubuntu
rpm -qa | grep -i php      # RHEL / AlmaLinux / Rocky

Důležitý detail: verze zobrazená v příkazové řádce (php -v) a verze, která reálně odpovídá na webové požadavky, se mohou lišit. Na serveru často běží několik verzí PHP najednou (třeba 7.4 pro starý web a 8.3 pro nový), a ta, co obsluhuje webový provoz, nemusí být ta v $PATH. Zkontrolujte CLI, FPM pooly a moduly Apache samostatně.

4.2 Co reálně poslouchá na síti

ps aux | grep -E 'php-fpm|php-cgi|apache2|httpd|litespeed' | grep -v grep
ss -tlnp | grep -E ':80|:443|:9000'

4.3 Kontejnery

docker ps --format '{{.Names}}\t{{.Image}}'
docker images --format '{{.Repository}}:{{.Tag}}' | grep -i php
docker exec <container> php -v

Nespoléhejte na název image: jeho tagy se vždy neshodují se skutečným obsahem. Spolehlivá kontrola je jen jedna: spustit php -v přímo uvnitř kontejneru. Image postavené na jiných image (vnořené Dockerfily) mohou nést kopii PHP, na kterou už nikdo nepamatuje.

4.4 Co si zaznamenat

Pro každou nalezenou instanci si zapište čtyři věci: server, aplikace, verze PHP a zda je dostupná z internetu. To je váš seznam priorit: veřejné systémy první, interní pak. Tento registr se později stane základem pravidelného patch managementu, ne jen jednorázové reakce na titulek.

5. Krok 2: aktualizujte PHP

5.1 Distribuční balíčky

Nejlepší cesta: vzít opravený balíček z repozitáře své distribuce. K 21. říjnu jsou aktualizace k dispozici pro Ubuntu, Debian 13, RHEL 9 (modul php:8.2), CloudLinux a cPanel (backporty pro 7.4, 8.0 a 8.1). U ostatních systémů zkontrolujte bezpečnostní tracker své distribuce.

sudo apt update && sudo apt upgrade     # Debian / Ubuntu
sudo dnf upgrade 'php*'                  # kompatibilní s RHEL

5.2 Restart procesů je povinný

Samotná aktualizace balíčku nemění PHP, které už běží: živé procesy si starou verzi drží v paměti. Pro aplikaci opravy je restart nutný:

sudo systemctl restart php8.3-fpm     # název unitu závisí na verzi a distribuci
sudo systemctl restart apache2        # pokud používáte mod_php

Tohle je jedna z nejčastějších chyb při nouzovém patchování: balíček je aktualizovaný, php -v ukazuje novou verzi, ale FPM pool má v paměti pořád starý kód.

5.3 Ověření po aktualizaci

php -v
php-fpm8.3 -v                       # nebo verze odpovídající vašemu poolu
systemctl status php8.3-fpm

Výsledek porovnejte s tabulkou v kapitole 2.4: 8.5.12, 8.4.27, 8.3.36 nebo 8.2.35 (případně balíček vaší distribuce s opravou pod jiným číslováním). Pokud používáte distribuční balíček se "staře vyhlížejícím" číslem verze, zkontrolujte changelog, zda zmiňuje CVE-2026-109618 a CVE-2026-109619.

5.4 Kontejnery: rebuild, ne aktualizace na místě

Kontejner se neaktualizuje příkazy uvnitř běžící instance. Správný postup je: stáhnout čerstvý základní image s opravenou verzí PHP, sestavit image nově bez cache, nasadit a výsledek ověřit.

docker compose build --pull --no-cache app
docker compose up -d --no-deps app
docker compose exec app php -v

Znejte limit tohoto postupu: rebuild přinese opravenou verzi jen tehdy, pokud už byl publikován odpovídající základní image. Zkontrolujte výsledek příkazu php -v, ne jen tag. Pokud opravený image ještě není k dispozici, použijte dočasná opatření z další kapitoly a rebuild zopakujte později.

6. Krok 3: pokud nemůžete aktualizovat hned

Jsou situace, kdy je aplikace s novou minor verzí nekompatibilní, kdy je potřeba servisní okno, nebo kdy je PHP na větvi bez jakékoliv opravy. Níže je seznam dočasných opatření čerpaný z doporučení publikovaných po vydání. Všechna riziko snižují, ale žádné zranitelnost neodstraňuje. Jediným úplným řešením je aktualizace.

6.1 Vypnutí upload_progress a hledání správného php.ini

Toto je první a nejrychlejší krok. Nastavte ve správném souboru:

session.upload_progress.enabled = Off

Kde konfigurace leží, závisí na vaší distribuci a způsobu instalace PHP, a také na tom, co přesně požadavky zpracovává: FPM, Apache a CLI mají často každý svůj vlastní php.ini.

Po změně nezapomeňte restartovat php-fpm nebo Apache, jinak si běžící procesy ponesou staré nastavení dál. Že se nastavení promítlo do reálného webového procesu, lze ověřit takto:

php-fpm8.3 -i | grep -i "upload_progress.enabled"

Výstup by měl ukazovat Off. Mějte na paměti limity: vypnutí upload_progress uzavírá jen jeden vektor. Druhá chyba potřebuje i limity velikosti požadavku a paměti (viz další podkapitoly), a jediné úplné řešení zůstává stejné: aktualizace PHP.

6.2 Příklad pro FPM pool

; /etc/php/8.3/fpm/pool.d/www.conf
php_admin_value[session.upload_progress.enabled] = 0
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 4M

Direktiva php_admin_value je důležitá proto, že ji vlastní kód aplikace nemůže přepsat, na rozdíl od ini_set().

6.3 Příklad pro Nginx

server {
    client_max_body_size 8m;
    # ...
}

6.4 Limity paměti na úrovni kontejneru

Pro Docker funguje limit paměti kontejneru (deploy.resources.limits.memory v Compose, probíraný v článku o produkci) jako pojistka proti tomu, že jeden havarovaný proces zabere veškerou paměť hostu. Stejně funguje i limit cgroup na systemd unitu PHP-FPM. Je lepší se vyhnout RLIMIT_AS a RLIMIT_DATA: doporučení přímo radí omezovat paměť přes cgroups.

6.5 Co tato opatření nezaručují

Žádná položka v tabulce obě chyby plně neuzavírá. Jde o mezistupeň do servisního okna, ne o náhradu aktualizace. Stanovte konkrétní datum, kdy se dočasná omezení zruší a PHP aktualizuje, jinak se z "dočasného" snadno stane trvalý stav.

7. Krok 4: kontrola, zda u vás už nikdo nebyl

Zneužívání bylo pozorováno ještě před vydáním oprav: podle výzkumníků byly první pokusy zaznamenány v 07:43 UTC 21. října, zatímco opravy vyšly ve 14:00 UTC. Takže stačí server aktualizovat nestačí; potřebujete také potvrdit, že se v tomto okně nikdo nedostal dovnitř. Zaměřte se na logy od 20. října.

7.1 Logy webového serveru

grep -i 'php2shell' /var/log/nginx/access.log* /var/log/apache2/access.log* 2>/dev/null
grep ' POST ' /var/log/nginx/access.log* | awk '{print $1, $7}' | sort | uniq -c | sort -rn | head -30

První řádek hledá User-Agent php2shell, který podle informací používají některé veřejné exploity. Zkušený útočník si ho ale snadno změní, takže prázdný výsledek nic nezaručuje. Druhý ukazuje, které adresy a URL dostaly nejvíc POST požadavků: výrazný nárůst požadavků na neobvyklé adresy, zejména velké multipart požadavky, stojí za bližší pohled.

7.2 Nové nebo změněné soubory

find /var/www -type f -name '*.php' -newermt '2026-10-20' -ls
find /var/www -type f -newermt '2026-10-20' ! -name '*.log' -ls | head -50

Nové PHP soubory v adresářích pro upload, cache nebo v temp adresářích, tedy tam, kde by neměly existovat vůbec, jsou standardní znak web shellu. Porovnejte je s posledním nasazením: cokoliv, co se objevilo mimo něj, si žádá vysvětlení.

7.3 Procesy a spojení

ps -eo user,pid,ppid,cmd | grep -E '^(www-data|nginx|apache|php)' | grep -vE 'php-fpm|nginx|apache2'
ss -tnp | grep -E 'ESTAB' | grep -E 'php|www-data'

Sledujte, zda proces webového serveru nespouští shell nebo nástroje jako curl, wget, nc, a zda z účtu webového serveru nejdou nevysvětlená odchozí spojení. Normální proces PHP-FPM nic z toho nedělá.

7.4 Co dělat, pokud máte podezření

1. Izolujte systém od externí sítě (nevypínejte ho, aby se zachovala paměť a stav pro analýzu).
2. Uložte kopie logů a jakýchkoliv podezřelých souborů ještě před jakoukoli změnou.
3. Rotujte hesla, tokeny a klíče, ke kterým měl proces PHP přístup: první chyba může uniknout obsah paměti, včetně hesel, tokenů a TLS klíčů.
4. Obnovte ze zálohy vytvořené před incidentem, ne "čištěním" aktuálního stavu na místě.

8. Aby to příště trvalo hodinu, ne den

Přesně v takových situacích se ukáže rozdíl mezi infrastrukturou, kterou řídí kód, a infrastrukturou, kterou má někdo v hlavě. Pokud jste prošli sérii o Dockeru na VPS a CI/CD, máte už většinu toho, co potřebujete.

8.1 Image se staví z tagu, ne z "latest"

Verzi PHP zafixujte v řádku FROM (například php:8.3-fpm-alpine místo php:latest). Pak reakce na podobnou situaci znamená jen změnit jeden řádek a spustit build, místo hádání, která verze běží na kterém serveru. Je to stejný princip reprodukovatelnosti, který byl popsán už v prvním článku série.

8.2 Pravidelný rebuild

Opravy v základních image se do vašeho vlastního image nepromítnou automaticky. Nastavte si pravidelný (třeba týdenní) rebuild s --pull --no-cache v CI a jako krok pipeline zkontrolujte php -v: pokud je verze nižší, než se vyžaduje, build spadne. Pak je "opravený image už existuje a my o tom nevěděli" nemožné.

8.3 Registr a rychlé nasazení

Automatické nasazení (4. článek série) proměňuje aktualizaci z manuální operace přes SSH v jediný push. A image s tagy podle SHA umožňují rychlý rollback, pokud nová verze PHP vaši aplikaci rozbije: nebudete muset volit mezi zranitelností a výpadkem.

8.4 Limity zdrojů jako běžná hygiena

Limity paměti a CPU na kontejneru (3. článek) se zde ukázaly jako bezpečnostní opatření navíc: stav nedostatku paměti je přesně výchozí bod jedné z chyb. Rozumné trvalé limity nejsou jen ochrana proti úniku paměti; zmenšují i plochu útoku.

8.5 Inventura jako trvalý proces

Registr z kapitoly 4.4 (server, aplikace, verze, veřejná dostupnost) by měl zůstat živý trvale, aktualizovaný při každém nasazení. Až vyjde další kritická aktualizace, a vyjde, vaše odpověď nebude "musíme to zjistit", ale "tady je seznam, tady je pořadí".

9. PHP 8.1 a starší: otázka, která přežije tuto jednu opravu

Pro větev 8.1 a starší neexistuje oficiální oprava, protože je projekt PHP už nepodporuje. Podpora pro 8.2 také končí 31. prosince 2026, což je za dva a půl měsíce. To znamená, že se situace "s čím budeme patchovat" bude opakovat, dokud aplikace zůstane na nepodporované větvi.

9.1 Tři možnosti pro starší systémy

• Backport distribuce nebo LTS podpora. Někteří dodavatelé (Ubuntu ESM, CloudLinux, cPanel pro PHP 7.4/8.0/8.1) dodávají opravy pro staré větve. Rozumný mezistupeň, pokud migrace aplikace bude ještě chvíli trvat.
• Sestavení ze zdrojového kódu. Projekt PHP publikoval minimální patche pro 7.4, 8.0 a 8.1. Vhodné pro týmy, které umí udržovat vlastní build, ale je to provozní dluh.
• Migrace na podporovanou větev. Jediná možnost, která riziko dál nenavyšuje. Naplánujte si to: 8.3 má bezpečnostní podporu do konce roku 2027 a 8.5 ještě déle.

9.2 Starý web jako izolovaný projekt

Pokud nelze aplikaci rychle migrovat, izolujte ji: vyhrazený VPS nebo kontejner se striktními limity, přístup jen přes omezený reverzní proxy a žádné tajemství z jiných systémů na stejném stroji. Levný samostatný server stojí míň než incident na sdílené infrastruktuře.

10. Shrnutí

PHP2Shell není důvod k panice a není to zpráva "pro někoho jiného". Je to důvod věnovat jednu hodinu zodpovězení tří otázek, na které by měl umět odpovědět každý administrátor: kde máme PHP, jakou verzi má a kdo ji po aktualizaci restartoval.

Akční plán se dá shrnout do čtyř kroků:

1. Najít. Verze PHP na hostu i v kontejnerech, CLI a FPM samostatně; veřejné systémy první.
2. Aktualizovat. Na 8.5.12, 8.4.27, 8.3.36 nebo 8.2.35, případně na opravený balíček vaší distribuce. Restartovat FPM/Apache, ověřit php -v. U kontejnerů: rebuild s --pull --no-cache.
3. Pokud to hned nejde. Odpojit aplikaci od internetu, vypnout session.upload_progress.enabled, omezit velikost požadavků, nastavit limity paměti. Je to dočasné, s konkrétním termínem.
4. Zkontrolovat. Logy od 20. října, nové PHP soubory, podivné procesy webového serveru. Žádný nález není záruka, ale jakýkoli nález si žádá okamžitou reakci.

Situace se stále vyvíjí: sledujte oficiální oznámení projektu PHP a svého dodavatele distribuce pro nejnovější verze a doporučení.

Často kladené otázky