php2shell: kritická chyba v PHP a jak se bránit

Ve středu 21. října vydal projekt PHP mimořádné bezpečnostní aktualizace. Opravují dvě chyby, kterým bezpečnostní komunita říká php2shell: útočník přes ně může bez hesla a bez účtu spustit na serveru vlastní kód. PHP přitom podle W3Techs pohání 69,3 % webů, u kterých jde serverový jazyk zjistit, takže se zpráva týká většiny firemních webů a e-shopů v Česku. Podstatné je, že opravu neuděláte v administraci WordPressu. Musí ji dostat server.

Co se stalo?

Obě chyby jsou v jádru PHP a obě souvisejí s tím, jak PHP uklízí paměť, když se požadavek nečekaně přeruší. Podle bezpečnostního oznámení na php.net a dvou advisory v repozitáři php-src jde o tyto zranitelnosti:

• CVE-2026-109618, poškození paměti při jejím nedostatku. Když požadavek narazí na limit paměti ve špatnou chvíli, PHP nechá data rozpracovaná a při úklidu je považuje za platná. Spustit to jde podle advisory upraveným nahráváním formuláře (multipart). Na Apache s mod_php projekt PHP předvedl převzetí serveru s výchozím nastavením, ještě než se spustí jediný řádek aplikace.
• CVE-2026-109619, zbytky předchozího požadavku. Po fatální chybě může v procesu zůstat odkaz na paměť, která patřila už vyřízenému požadavku, a další požadavek na stejném procesu ji použije. Potvrzené spuštění kódu je podle advisory zatím jen na PHP 8.5 s mod_php, pád procesu a únik dat z paměti ale i jinde.

Obě chyby mají skóre CVSS v4.0 9,2 z 10. Dotčené jsou podle php.net všechny instalace, které obsluhují webové požadavky: PHP-FPM, Apache s mod_php, php-cgi, FrankenPHP i LiteSpeed. Největší riziko vidí projekt u mod_php, protože tam ochrana na úrovni aplikace nemá šanci zasáhnout.

Za zmínku stojí i to, jak se oprava dostala ven. Podle PHP Foundation první z výzkumníků nahlásil chybu už 11. srpna 2026. Vydání bylo naplánované na 22. října, jenže 20. října odpoledne se identifikátory obou CVE začaly šířit po sociálních sítích a večer jedna z výzkumných firem omylem zveřejnila video s ukázkou útoku. PHP proto vydání o den uspíšilo na 21. října v 16:00 SELČ. Foundation zpoždění sama označila za strukturální selhání bezpečnostního týmu, kterému chyběly lidi.

Útočí už někdo přes php2shell?

Zdroje se tu rozcházejí a je dobré je číst přesně. Firma watchTowr uvádí, že ve své síti návnad (honeypotů) zaznamenala zneužívání od 21. října. Podle Help Net Security zachytila Amazon Threat Intelligence pokus o útok už 17. října, čtyři dny před zveřejněním; tohle tvrzení jsme dohledali jen v tomto jednom článku. Naopak americká agentura CISA ve své výstraze z 21. října zneužití nezaznamenala a firma Huntress ho týž den odpoledne ve své klientské základně také neviděla.

Úspěšný průnik přes php2shell tedy k 22. říjnu nikdo veřejně nepotvrdil. Na rozhodnutí to ale nic nemění: chyby jsou veřejně popsané, existuje předvedený útok a pokusy už běží. S aktualizací se nečeká na první oběti.

Jak na to zareagovalo Česko?

NÚKIB vyzval všechny, kdo provozují web nebo jinou službu na PHP, aby aktualizaci neodkládali. Varování vydaly i CSIRT Masarykovy univerzity a CZ.NIC; CSIRT-MU výslovně jmenuje weby na WordPressu nebo Drupalu, Moodle, wiki a interní nástroje. Podle TN.cz Úřad vlády ve středu 21. října v 19:00 preventivně odstavil svůj web a zhruba ve 21:00 ho po instalaci oprav znovu spustil. Odstávku hlásil podle téhož článku i Český hydrometeorologický ústav; obě informace máme jen z TN.cz.

Které verze PHP jsou opravené?

Dva řádky z tabulky si zaslouží pozornost. Kdo dnes aktualizuje na PHP 8.2.35, má klid jen do konce roku: 31. prosince 2026 větev 8.2 bezpečnostní opravy dostávat přestane. Rozumnější je rovnou přejít na 8.3 nebo novější. A druhý: podle W3Techs běží na PHP 7 26,9 % a na PHP 5 7,7 % webů s PHP. Dohromady je to přes třetinu webů na verzích, pro které oficiální oprava nevyjde, a to ještě bez webů na 8.0 a 8.1, které W3Techs samostatně neuvádí.

K rozsahu dotčených verzí: php.net vyjmenovává jen opravená vydání. Že je zranitelné každé PHP od verze 5.4 (Sansec) nebo dokonce od PHP 5 (watchTowr), tvrdí bezpečnostní firmy, projekt PHP to v oznámení nepotvrdil. Pro rozhodování je to jedno: co není na opravené verzi, berte jako ohrožené.

Jak zjistit, jestli je váš web ohrožený?

1. Zjistěte verzi PHP. V administraci hostingu, nebo ve WordPressu v Nástroje › Stav webu › Informace › Server.
2. Porovnejte ji s tabulkou výše. 8.5.12, 8.4.27, 8.3.36, 8.2.35 a novější jsou v pořádku.
3. Pozor na balíčky z distribucí. Debian, Ubuntu nebo Red Hat opravu často zabalí do starší verze. Číslo pak vypadá staře, i když je server opravený. Rozhoduje changelog balíčku, ve kterém jsou obě CVE, nebo písemné potvrzení od poskytovatele.
4. Nezapomeňte na to, co není vidět. CISA upozorňuje, že PHP bývá zabudované i v jiném softwaru: v administračních panelech, síťových zařízeních, starých intranetech nebo testovacích kopiích webu, na které se zapomnělo.

Jeden konkrétní příklad, jak má vypadat odpověď poskytovatele: Hostinger 22. října oznámil, že opravu nasadil na všechny tarify kromě VPS, a radí zkontrolovat v PHP Info datum sestavení (Build Date) 21. října 2026 nebo pozdější. U českých hostingů jsme k dnešnímu dni veřejné oznámení o stavu oprav nedohledali, takže se zeptejte podpory přímo. Chcete slyšet dvě věci: že je PHP na opravené verzi a že byly restartované všechny procesy PHP.

Co dělat, když aktualizovat hned nejde?

Projekt PHP v oznámení zveřejnil dočasná opatření a sám dodává, že instalaci bezpečnou neudělají. Advisory to říká ještě přímočařeji: jediné úplné řešení je aktualizace. Pro správce serverů jsou to tato nastavení, která musí platit ještě před zpracováním požadavku, tedy v php.ini, v konfiguraci FPM poolu nebo Apache, ne přes ini_set() nebo .user.ini:

; CVE-2026-109618: limit paměti řešte mimo PHP (kontejner, cgroup)
memory_limit = -1
post_max_size = 8M        ; 32M, pokud web potřebuje nahrávat soubory
upload_max_filesize = 4M  ; vždy menší než post_max_size

; CVE-2026-109619
session.upload_progress.enabled = 0
fatal_error_backtraces = 0  ; jen PHP 8.5

• memory_limit = -1 zní obráceně, ale je to doporučení php.net. Chyba vzniká právě ve chvíli, kdy PHP narazí na vlastní limit paměti. Paměť pak hlídejte limitem kontejneru nebo cgroup. Limity RLIMIT_AS a RLIMIT_DATA advisory výslovně zakazuje, protože chybu vyvolávají.
• Po změně restartujte všechny procesy PHP. Druhá chyba žije v procesech, které obsluhují víc požadavků po sobě, takže nastavení bez restartu nic neřeší.
• Vypnutí session.upload_progress nechte i po aktualizaci, pokud ukazatel průběhu nahrávání nepoužíváte. Doporučuje to přímo advisory.
• Firewall webových aplikací pomůže, ale nenahradí opravu. Cloudflare podle Help Net Security nasadil první pravidla pro známé varianty útoku všem zákazníkům včetně bezplatného tarifu. CISA uvádí firewall jako dočasnou ochranu, než bude hotová aktualizace.
• Kde nepomůže nic z toho, web odpojte. CISA i CSIRT-MU radí neopravitelné systémy omezit na VPN nebo vybrané IP adresy, případně je dočasně vypnout. Přesně to v praxi udělal Úřad vlády.

Co to znamená pro vás?

Pro majitele firmy, který nemá vlastního správce, je hlavní otázka jednoduchá: kdo je odpovědný za PHP na mém serveru? Pokud to nevíte, je php2shell dobrá příležitost to zjistit, protože podobná zranitelnost nebyla poslední. Podle typu provozu to vypadá takhle:

Jedno upozornění k aktualizaci: přechod ze staré větve (třeba ze 7.4 nebo 8.1 na 8.3) není totéž co bezpečnostní záplata v rámci jedné větve. Starší šablony a pluginy na novějším PHP mohou přestat fungovat, proto ho nejdřív zkuste na testovací kopii webu. Kvůli tomu ale aktualizaci neodkládejte o týdny. Kde test hned udělat nejde, je lepší dočasně omezený web než web, který převezme někdo cizí.

Když už k napadení došlo, hledejte podle NÚKIB, CISA a Huntress hlavně procesy, které pod PHP nemají co dělat: shell, curl, wget nebo python spuštěné z php-fpm či apache2, nové soubory ve složce webu, nové úlohy v cronu a nové účty. Server v takovém případě odpojte a logy nemažte, budou potřeba při vyšetřování. Univerzity a školy mohou kontaktovat CSIRT-MU na csirt@muni.cz.

Co sledovat dál

Tři věci. Zda CISA zařadí obě CVE do katalogu aktivně zneužívaných zranitelností (KEV), což by potvrdilo úspěšné útoky. Zda bezpečnostní firmy zveřejní funkční exploit, po kterém obvykle přichází hromadné skenování celého internetu. A konec podpory PHP 8.2 k 31. prosinci 2026, který se po téhle aktualizaci týká o to víc webů.

Jakmile se změní stav zneužívání nebo vyjde další oprava, doplníme to sem a v článku přibude záznam o aktualizaci. Do té doby platí stav k 22. říjnu 2026.

Potřebujete se serverem pomoct?

Pokud nevíte, kdo vám PHP aktualizuje, nebo váš web běží na PHP 8.1 a starším, převezmeme to. V rámci hostingu a správy serverů spravujeme VPS včetně bezpečnostních záplat a dohledu nad provozem a starý web bez výpadku přesuneme na podporovanou verzi PHP. Napište nám, kde web běží a na jaké verzi PHP, a řekneme vám, co je potřeba udělat.