PHP2Shell: dvě kritické chyby v PHP, útoky už běží a oprava je venku

PHP pohání zhruba sedm z deseti webů, u kterých je známý serverový jazyk: WordPress, e-shopy, Nextcloud, firemní intranety i tento web. Dnes dostalo opravu, kterou tvůrci jazyka označují za jednu z nejvážnějších v jeho historii. Bezpečnostní komunita dvojici chyb pojmenovala PHP2Shell a číslo hodnocení CVSS 9.2 z 10 je u obou.

Co se stalo, v krátkosti

• Dvě chyby, CVE-2026-109618 a CVE-2026-109619. Obě umožňují vzdálené spuštění kódu (RCE) bez přihlášení: útočník pošle speciálně sestavený požadavek a server spustí jeho program. První z nich navíc dokáže z paměti serveru vytáhnout hesla, tokeny a klíče, podobně jako kdysi Heartbleed.
• Týká se všech verzí od PHP 5.4 z roku 2012. Nezáleží na tom, jestli PHP běží pod Apachem nebo jako FPM, ani na tom, jakou aplikaci provozujete. Zranitelný kód se spouští dřív než vaše aplikace.
• Oprava vyšla 21. října ve 14:00 UTC, tedy v 16:00 našeho času, ve verzích 8.5.12, 8.4.27, 8.3.36 a 8.2.35. Původně byla plánovaná na 22. října; PHP ji uspíšilo poté, co 20. října odpoledne unikla čísla CVE na sociální sítě.
• Útoky už běží. Cloudflare hlásil první pokusy o zneužití v 07:43 UTC, sedm hodin před vydáním opravy. Patchstack ve stejnou dobu evidoval několik incidentů u webů na WordPressu. Nizozemské státní služby DigiD a MijnOverheid preventivně vypnuly.

Jak chyby fungují

Obě mají stejný základ: co se stane, když PHP při zpracování požadavku dojde paměť. Každý známý způsob zneužití začíná požadavkem typu multipart/form-data, tedy tím, jakým prohlížeč nahrává soubory. Útočník ho sestaví tak, aby PHP vyčerpalo limit paměti (memory_limit) v nevhodnou chvíli.

U první chyby (109618) jde o funkci, která hlásí průběh nahrávání souboru. Ta běží ještě před vaší aplikací a při výpadku paměti po sobě nechá nedoklizený stav. Následný úklid pracuje s uvolněnou pamětí a výsledkem je buď únik obsahu paměti (v odpovědi může odejít cizí session, heslo k databázi nebo privátní klíč), nebo spuštění kódu.

Druhá chyba (109619) sedí ve zpracování fatálních chyb: PHP si po výpadku paměti ponechá ukazatel na data, která už neexistují, a v kombinaci s OPcache z toho jde udělat řízené přepsání paměti. Sansec potvrdil funkční útok proti aktuálním verzím Magenta, WordPressu, Drupalu, Joomly, Nextcloudu, Laravelu i Symfony. Není to tedy chyba aplikací. Je to chyba motoru, na kterém všechny běží.

Kdo chyby našel

Tohle je část, která se na webu o AI hodí zdůraznit. Podle PHP Foundation chyby nezávisle nahlásily tři strany během srpna: bezpečnostní firma Calif (11. srpna), OpenAI (týž den, s dalšími vektory v září) a Wiz (24. srpna). Wiz ve své zprávě otevřeně popisuje, že nálezy vznikly s pomocí AI nástrojů, konkrétně jejich platformy Atlas a modelů Gemini 4 Argon a GPT od OpenAI. Chyby v kódu z roku 2012, které čtrnáct let nikdo nenašel, objevily během pár týdnů tři týmy, dva z nich s AI v hlavní roli.

To není náhoda, ale trend. Modely, které umí číst miliony řádků kódu a systematicky zkoušet, co se stane při výpadku paměti, dnes nacházejí chyby rychleji, než je stíhají opravovat správci projektů, kteří to často dělají ve volném čase. PHP Foundation to ví: v květnu založila bezpečnostní tým pro ekosystém, přes léto najala dva lidi na plný úvazek a s Califem se zapojila do programu „Patch the Planet", kde se AI auditování používá preventivně.

Co udělat dnes

Máte web na sdíleném hostingu (Wedos, Active24, Forpsi, WebSupport a podobně): verzi PHP řídí hosting. Podívejte se do administrace, jakou verzi máte, a zkontrolujte, jestli hosting vydal oznámení. Pokud je verze nižší než 8.2.35, 8.3.36, 8.4.27 nebo 8.5.12 a hosting mlčí, napište mu. Nic víc udělat nemůžete, a nic víc dělat nemusíte. Pokud oznámení od hostingu nerozumíte, nechte si ho přeložit: Týká se mě to? Bezpečnostní zpráva do lidštiny.

Máte vlastní server nebo VPS: aktualizujte balíčky PHP (na Debianu a Ubuntu typicky z repozitáře deb.sury.org, který opravené verze vydal týž den) a restartujte PHP-FPM. Nejčastější chyba je, že php -v ukazuje novou verzi, ale web dál běží na starém procesu. Ověřte si verzi přes phpinfo nebo hlavičku odpovědi, ne jen v terminálu. Náš vlastní server dostal 8.4.27 ještě dopoledne, panel hostingu to provedl automaticky; přesto jsme verzi FPM ověřovali ručně. Pokud aktualizaci svěříte agentovi v terminálu, dejte mu zadání s plánem, zálohou a cestou zpět: Aktualizuj server bezpečně.

Používáte PHP 8.1 nebo starší: oficiální opravy pro ně nejsou, tyto větve skončily. Některé distribuce a placené služby (TuxCare a podobně) chyby zpětně opravují, ale spolehnout se na to nedá. Tohle je okamžik, kdy přechod na podporovanou verzi přestává být „někdy" a stává se „tento týden".

Provozujete Docker nebo CI: zkontrolujte, jestli obrazy, které stahujete, už mají opravenou verzi (Chainguard vydal opravené obrazy dokonce ráno před oficiálním vydáním), a nezapomeňte na staging, CI runnery a vývojová prostředí. Kde všude se verze PHP v projektu skrývá, najde audit závislostí.

Stavíte aplikace vibe codingem: Lovable, Bolt a podobné nástroje PHP nepoužívají, netýká se vás to. Pokud jste ale nechali agenta postavit aplikaci v Laravelu nebo Symfony a nasadili ji na vlastní VPS, týká se vás to plně.

Máte zákazníky, kteří se budou ptát: řekněte jim, co se stalo a co mají dělat, dřív, než se to dozví odjinud. Šablonu pro e-mail, web i sociální sítě napíše Zpráva zákazníkům o bezpečnostní aktualizaci.

Co nepomůže

Během úterka kolovaly rady, že stačí v nastavení vypnout volbu session.upload_progress.enabled nebo zrušit limit paměti. Vývojáři PHP to výslovně odmítli: pomůže to jen proti části známých vektorů a nedělá z neopraveného serveru bezpečný server. Dočasně pomůže blokovat požadavky multipart/form-data na úrovni webového serveru nebo WAF (Cloudflare pravidla nasadil i pro bezplatný tarif), ale je to brzda, ne oprava. Jediná skutečná oprava je nová verze.

Dobrá zpráva na závěr: oprava vyšla do dvou dnů od úniku, distribuce ji měly připravenou předem, a většina velkých hostingů ji nasadila během dne. Špatná zpráva: miliony serverů aktualizovat nikdo nebude, protože o nich nikdo neví. Ty budou cílem příštích týdnů.

Zdroje a další čtení

1. Today’s PHP Security Release, and How We’re Strengthening PHP Security (The PHP Foundation)
2. PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet (Wiz)
3. PHP2Shell: Critical PHP RCE (CVE-2026-109618, CVE-2026-109619) (Sansec)
4. php2shell (CVE-2026-109618, CVE-2026-109619): Critical PHP RCE FAQ (Tenable)
5. Major security alert: PHP vulnerable to critical RCE, attacks ongoing (Patchstack)
6. [ANNOUNCE] Upcoming Critical PHP Security Release (php.net)