PHP2Shell: kritická chyba v PHP – koho se týká a co dělat

PHP2Shell v kostce

Co: dvě kritické zranitelnosti přímo v jádru PHP, CVE-2026-109618 a CVE-2026-109619, obě se skóre CVSS 9,2.
Dopad: vzdálené spuštění kódu bez přihlášení a únik obsahu paměti serveru.
Koho se týká: všech instalací PHP, které obsluhují webové požadavky. Nejvíc ohrožený je Apache s modulem mod_php.
Opravené verze: PHP 8.5.12, 8.4.27, 8.3.36 a 8.2.35. Verze 8.1 a starší od vývojářů PHP opravu nedostanou.
Co udělat: aktualizovat PHP na serveru a restartovat služby. Aktualizace WordPressu ani pluginů tuto chybu neopraví.

Co se vlastně stalo

PHP je programovací jazyk, ve kterém je napsaný WordPress, Drupal, Joomla, PrestaShop, Magento, Moodle, Nextcloud a nespočet firemních aplikací. Chyby ale nejsou v žádné z nich. Jsou v samotném „motoru“, který kód těchto aplikací na serveru vykonává. Proto je nejde opravit aktualizací redakčního systému.

Technicky jde o chyby v práci s pamětí. Když PHP při zpracování požadavku nečekaně dojde paměť, požadavek předčasně ukončí, ale nedokáže po sobě pořádně uklidit. Typicky se to stane u formuláře s nahráváním souborů. V paměti pak zůstanou rozpracovaná nebo už uvolněná data. Další požadavek, který obslouží stejný proces, s nimi může zacházet, jako by byla platná.

Připomíná to číšníka, kterého uprostřed obsluhy odvolají k jinému stolu, takže nestihne uklidit. Další host si pak sedne ke stolu, na kterém leží cizí účtenka a klíče od auta. Šikovně sestavený požadavek může stejně tak přimět server, aby vydal obsah své paměti, třeba hesla, přístupové tokeny nebo klíče k API. V horším případě server spustí kód útočníka.

Podle oznámení vývojářů PHP se riziko týká všech instalací, které obsluhují webové požadavky: PHP-FPM, Apache s modulem mod_php, php-cgi, FrankenPHP i LiteSpeed. Nejhorší je situace u mod_php. Tam existuje předvedený útok, který stačí spustit jediným nepřihlášeným požadavkem, a to dřív, než se vůbec rozběhne kód webové aplikace. U PHP-FPM, které je na moderních serverech nejběžnější, vývojáři zranitelné chování potvrdili také, i když kompletní útok tam zatím zdokumentovaný není. Výzkumníci z firmy Wiz navíc upozorňují, že zranitelná může být i úplně jednoduchá stránka typu „Hello World“, bez jakéhokoli redakčního systému.

Neznamená to, že jde napadnout každý web na PHP. Úspěch útoku závisí na verzi, konfiguraci a nainstalovaných rozšířeních. Zjistit, jestli zrovna váš server útoku odolá, je ale pracnější než ho prostě aktualizovat.

Proč vlády raději vypínaly weby

První z chyb našli výzkumníci firmy Wiz 19. srpna a o pět dní později ji nahlásili týmu PHP. Následovaly dva měsíce neveřejné práce na opravách. Zapojily se do ní i linuxové distribuce, aby měly opravené balíčky připravené předem. Dvacátého října vývojáři PHP ohlásili, že opravy vydají další den ve 14:00 UTC, tedy v 16:00 našeho času.

Plán se ale začal rozpadat. Podle serveru Nedd.cz se ještě 20. října na fóru Hacker News objevil anonymní příspěvek, který existenci chyb prozradil. Amazon zachytil první pokus o zneužití na svých návnadových serverech (tzv. honeypotech) už 17. října, tedy čtyři dny před zveřejněním. V noci na 21. října se objevily první ukázkové exploity a po vydání oprav během několika hodin další.

Správci tak měli na reakci jen krátké okno. Americká NSA, britské NCSC i evropský CERT-EU proto vydaly nezvykle přímé doporučení: aktualizujte okamžitě, a pokud to nejde, systém do opravy odpojte. Vládní instituce spravují desítky až stovky webů různého stáří, a tak raději zvolily druhou možnost. Bezpečnostní výzkumník Nicholas Weaver to pro server Cybersecurity Dive shrnul slovy: „Jsme ve světě, kde musíte aktualizace nasazovat prakticky okamžitě.“

Zprávy o skutečných útocích se zatím rozcházejí. Firma watchTowr 21. října uváděla, že žádný pokus zatím neuspěl. Patchstack hlásil několik potvrzených případů a podle Amazonu je PHP2Shell „už široce zneužíván“. Pro vaše rozhodnutí to ale tolik neznamená. Exploity jsou veřejné, takže otázka už nezní, jestli to někdo na vašem serveru zkusí, ale kdy.

Koho se to týká a kdo má opravu na starosti

Nejdůležitější informace celého článku: chyba je v PHP na serveru, ne ve vašem webu. Opravit ji tedy musí ten, kdo server spravuje. A to nemusíte být vy.

• Web na běžném webhostingu. Typicky firemní prezentace na WordPressu nebo menší e-shop u některého z českých hostingů. PHP na serveru aktualizuje hosting, vy k serveru ani nemáte přístup. Velcí poskytovatelé reagovali během prvních hodin, Český hosting například nasadil opravy na sdílený hosting i virtuální servery. Vy byste měli zkontrolovat, že váš hosting opravu oznámil, a v zákaznické sekci se podívat, jakou verzi PHP váš web používá. Pokud jde o starou verzi z řady 7 nebo dokonce 5, hosting pro ni často nemá plnohodnotnou opravu, jen dočasná omezení. Pak je nejvyšší čas přejít na novější verzi.
• Spravovaný WordPress hosting. U služeb, které se na WordPress specializují, platí totéž, a to ještě víc, protože právě za tohle platíte. Ověřte si oznámení poskytovatele, nic dalšího obvykle dělat nemusíte.
• Vlastní VPS nebo server, který spravujete sami. Tady jste správce vy, případně kolega z IT nebo externí správce, kterého jste si najali. Poskytovatel vám dodal virtuální stroj s operačním systémem, ale za to, co na něm běží a jak je to aktuální, odpovídáte sami. Postup najdete v další kapitole.
• Spravovaný server nebo VPS. Pokud platíte za správu, měl by opravu nasadit poskytovatel. Neberte to ale jako samozřejmost. Podívejte se do smlouvy, co přesně správa zahrnuje, protože to často bývá jen operační systém a ne třeba PHP z repozitáře třetí strany. Raději se zeptejte e-mailem. Písemná odpověď se hodí, kdyby se později něco stalo.
• Web vám postavil a provozuje dodavatel. Klasická situace: web vám udělala agentura nebo freelancer a nějak běží. Zjistěte, kde běží a kdo má k serveru přístup. Pokud je hosting na vaše jméno, platí pro vás jeden z předchozích bodů. Pokud server provozuje dodavatel, zeptejte se ho přímo, kdy a jak opravu nasadil.
• Aplikace v kontejnerech (Docker, Kubernetes). Aktualizace balíčků na hostitelském serveru vám nepomůže, protože PHP je zabudované přímo v obrazu kontejneru. Obraz je potřeba znovu sestavit nad aktualizovaným základem a kontejnery znovu nasadit. Totéž platí pro FrankenPHP.
• Krabicový software a zařízení s vestavěným PHP. PHP běží i tam, kde byste ho nečekali: ve webových rozhraních síťových zařízení, v ovládacích panelech serverů, v intranetech, docházkových systémech nebo starších firemních aplikacích. Tady musí opravu dodat výrobce. Nizozemské NCSC vede seznam produktů, kterých se PHP2Shell týká, a odkazuje na něj i CERT-EU.
• Návštěvníci webů. Běžní uživatelé nemusí aktualizovat nic. Aktualizace prohlížeče ani telefonu tu nehraje roli, nanejvýš narazí na dočasně nedostupný web.

Častý omyl zní: „Aktualizoval jsem WordPress, takže jsem v bezpečí.“ Nejste. Aktualizace WordPressu, šablony a pluginů je důležitá, ale PHP2Shell neopraví. Funguje to i obráceně: aktualizované PHP vás neochrání před děravým pluginem.

Spravujete server sami? Tady je postup

Pokud jste správce vy, počítejte s tím, že na jeden příkaz to nebude. Následující postup vychází z doporučení vývojářů PHP, britského NCSC, Amazonu a praktických návodů pro jednotlivé distribuce.

1. Zjistěte, kde všude PHP běží. Nejde jen o produkční web. Patří sem i testovací prostředí, staré zapomenuté weby, phpMyAdmin, monitoring nebo interní nástroje. Začněte tím, co je dostupné z internetu.
2. Zjistěte, odkud PHP pochází. Může jít o balíčky distribuce (Debian, Ubuntu, RHEL a odvozené), repozitář třetí strany (Ondřej Surý pro Debian a Ubuntu, Remi pro RHEL), kontejnerový obraz nebo vlastní kompilaci. Postup aktualizace se podle toho liší. Repozitář Remi v den vydání opravy neměl. Vývojáři PHP jeho uživatelům doporučili přejít na balíčky distribuce nebo PHP zkompilovat ze zdrojových kódů.
3. Nainstalujte opravu. Opravené verze jsou PHP 8.5.12, 8.4.27, 8.3.36 a 8.2.35. Distribuce jako Ubuntu nebo RHEL ale opravy často přenášejí do starší verze (tzv. backport), aniž by se změnilo číslo, které ukáže příkaz php -v. Kontrolujte proto verzi balíčku a jeho changelog, ne jen číslo verze PHP.
4. Restartujte všechno, co PHP spouští. Běžící proces má starou verzi PHP stále v paměti. U PHP-FPM stačí reload, u Apache s mod_php je potřeba plný restart, tzv. graceful restart nestačí. Nezapomeňte ani na fronty a dlouho běžící procesy, například workery front v Laravelu. Na Debianu a Ubuntu vám služby, které ještě potřebují restart, ukáže nástroj needrestart.
5. Ověřte výsledek. Zkontrolujte, že běží opravená verze a že žádný proces už nepoužívá starou knihovnu.
6. Zkontrolujte, jestli už nedošlo k napadení. Amazon doporučuje začít šetření od 17. října, ne až ode dne zveřejnění. Co hledat:
   • neobvyklé procesy spuštěné pod uživatelem webového serveru (na ty upozorňuje i NÚKIB),
   • POST požadavky s řetězcem PHP_SESSION_UPLOAD_PROGRESS,
   • požadavky s nahráváním dat, po kterých následují chyby z vyčerpání paměti,
   • nevysvětlitelné série chyb 500,
   • neobvykle velké cookies PHPSESSID,
   • nové nebo změněné soubory v adresářích webu.

   Mějte ale na paměti, že podle vývojářů PHP čisté logy bezpečnost nedokazují.

7. Při podezření jednejte jako při incidentu. Server izolujte a obnovte ze zálohy z doby před 17. říjnem. Protože chyba umožňuje číst obsah paměti, změňte také hesla k databázi, klíče k API a další přístupové údaje, ke kterým měla aplikace přístup. Organizace, na které se vztahuje zákon o kybernetické bezpečnosti, hlásí incident přes Portál NÚKIB.

Co když opravu nemůžete nasadit hned

Někdy to opravdu nejde. Stará aplikace na novější verzi nefunguje, dodavatel nereaguje nebo server prostě nikdo nespravuje. Pro takové případy zveřejnili vývojáři PHP dočasná opatření. Zároveň ale důrazně upozorňují, že úplným řešením je jen aktualizace. Opatření uzavírají pouze známé cesty útoku.

• Vypněte průběh nahrávání v sessions. Nastavte session.upload_progress.enabled=0 v php.ini nebo v konfiguraci FPM poolu (ne přes ini_set() ani .user.ini) a restartujte všechny procesy. Pokud funkci nepoužíváte, nechte ji vypnutou i po opravě.
• Upravte limity paměti a velikosti požadavků. Nastavte memory_limit=-1 tak, aby ho aplikace nemohla přepsat (například přes php_admin_value), a paměť pak hlídejte limitem kontejneru nebo systému. Snižte post_max_size na 8 MB, nebo na 32 MB, pokud web přijímá soubory.
• Na PHP 8.5 vypněte fatal_error_backtraces. Tím uzavřete jednu z potvrzených cest útoku.
• Blokujte nahrávání souborů, pokud ho nepotřebujete. Požadavky typu multipart lze zablokovat už na webovém serveru nebo proxy, ještě než dorazí k PHP.
• Postavte před web webový firewall (WAF). Cloudflare nasadil pravidla proti známým exploitům pro všechny zákazníky včetně bezplatného tarifu. Jeho technický ředitel Dane Knecht ale sám zdůraznil, že jde o dočasné řešení.
• Když nic z toho nejde, web odpojte. Přesně to udělaly vlády.

Stará verze PHP? Teď už nejde jen o technický dluh

PHP 8.1 a starší už od vývojářů opravy nedostávají. Vzhledem k závažnosti chyb připravil tým PHP výjimečně minimální opravy zdrojového kódu pro verze 7.4, 8.0 a 8.1, ty ale pomohou jen tomu, kdo si PHP sám kompiluje. Některé distribuce a dodavatelé dlouhodobé podpory opravy pro starší verze dodávají, často ovšem jen v placených programech. Například Ubuntu 18.04 a 20.04 je dostane jen s předplatným Ubuntu Pro a Debian 11 už bezplatné bezpečnostní opravy nedostává. Výchozí PHP 7.2 v RHEL 8 zůstane bez oprav úplně.

Starých instalací přitom není málo. Podle odhadu firmy Cisco, který cituje Cybersecurity Dive, běží zhruba polovina PHP instalací dostupných z internetu na verzi, na kterou se oficiální opravy nasadit nedají. Na sdíleném hostingu je situace podobná: Český hosting pro verze PHP 5.2 až 5.5 opravné balíčky nemá a nasadil jen omezení nahrávání dat.

Pokud tedy váš web běží na PHP 7 a „funguje“, PHP2Shell je dobrý důvod naplánovat přechod na PHP 8.4. Znamená to web otestovat, možná aktualizovat šablonu a pár pluginů a u vlastních aplikací upravit i kód. Pořád je to ale levnější než obnova napadeného serveru.

Chyby pomohla najít umělá inteligence

Výzkumníci Wiz při práci podle vlastního popisu využívali AI modely Gemini 4 Argon a GPT-5.6 Sol. Na hledání, koordinaci a ověření oprav se podílely také firma Calif a OpenAI. AI podle Wiz hlavně zjednodušila skládání jednotlivých chyb do funkčního útoku a jeho přizpůsobení různým verzím a konfiguracím PHP. Funkční exploity pro několik aplikací tak měl tým hotové během hodin. OpenAI označila PHP2Shell za jednu z nejzávažnějších zranitelností poslední doby a dodala, že jde o novou fázi, kdy AI dokáže najít chyby s dopadem na celý internet.

Stejné nástroje ale mají k dispozici i útočníci. Amazon ve své analýze upozorňuje, že díky AI dnes jde z rozdílu mezi starou a opravenou verzí kódu rychle odvodit funkční exploit. Utajení chyby do vydání oprav podle něj chrání obránce jen do chvíle, než stejnou chybu najde někdo jiný. Doporučení Amazonu proto zní: u kritických zranitelností na systémech dostupných z internetu měřte dobu nasazení oprav v hodinách, ne ve dnech.

Pro mnoho firem je to velká změna. Měsíční „záplatovací okno“ nebo aktualizace „až bude čas“ přestávají stačit.

Co si z toho odnést

PHP2Shell se dříve či později vyřeší. Další podobná chyba ale přijde, a s nástupem AI spíš dřív než později. Tyto otázky se vyplatí mít zodpovězené předem:

• Víte, co všechno provozujete? Seznam webů, aplikací a serverů včetně verzí, a to i těch, na které se roky nesáhlo.
• Víte, kdo za co odpovídá? Písemně, ve smlouvě s hostingem, správcem nebo dodavatelem, nejlépe i s tím, do kolika hodin nasadí kritickou bezpečnostní opravu.
• Umíte opravu nasadit rychle? Bez týdne testování a schvalování. Pomůže automatizace, testovací prostředí a zálohy, ze kterých lze opravdu obnovit.
• Máte pojistku? Webový firewall a monitoring nenahradí aktualizaci, ale získají vám čas.
• Neodkládáte upgrade? Nepodporovaná verze PHP, operačního systému nebo redakčního systému znamená, že při příští kritické chybě nebudete mít co nainstalovat.

Zdroje

• PHP Group: Upcoming Critical PHP Security Release a Security advisory: Critical remote code execution vulnerabilities, update now, php.net, 20. a 21. 10. 2026
• PHP Group: CVE-2026-109618: RCE via OOM corruption a CVE-2026-109619: RCE via stale global state, GitHub, 21. 10. 2026
• CERT-EU: Security Advisory 2026-018: Critical PHP Vulnerabilities, 21. 10. 2026
• NÚKIB: NÚKIB upozorňuje na kritické zranitelnosti v PHP – jediným řešením je aktualizace, 21. 10. 2026
• NCSC (Spojené království): Critical security issue affecting PHP, 21. 10. 2026
• Wiz Research: PHP2Shell: PHP RCE, Wiz Blog
• CJ Moses: Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot, AWS Security Blog, 21. 10. 2026
• Critical PHP vulnerabilities expose most websites to potential compromise, Cybersecurity Dive, 21. 10. 2026
• PHP2Shell: Critical PHP vulnerabilities patched, update now!, Help Net Security, 21. 10. 2026
• Mattias Geniar: PHP CVE-2026-109618 and CVE-2026-109619: how to apply the patches, ma.ttias.be
• PHP security flaw: Websites taken down as OpenAI spots issue with backbone of internet, The National, 21. 10. 2026
• Obří bezpečnostní díra ohrožuje internet. Úřady po Evropě raději vypínají vládní weby, Novinky.cz
• Aktualizujte, nebo vypněte. NSA vydala nezvykle tvrdé varování kvůli PHP, Nedd.cz, 22. 10. 2026
• Webové stránky Úřadu vlády jsou nedostupné. Na vině jsou chyby programovacího jazyka PHP, iROZHLAS, 21. 10. 2026
• Řešení kritické zranitelnosti PHP2Shell, Český hosting

Při tvorbě článku bylo využito generativní AI.