Kritické chyby v PHP z 21. října 2026: útočník spustí kód bez přihlášení. Co má majitel webu udělat ještě dnes

Tento článek píšeme v den zveřejnění, protože jde o nejvážnější chybu v PHP za poslední roky a týká se prakticky každého firemního webu v Česku. Není to chyba WordPressu ani vašeho e-shopu, ale jazyka, ve kterém běží. Proto nepomůže aktualizovat web, je třeba aktualizovat server. Níže je bez technického balastu to, co má majitel firmy vědět a co si má nechat potvrdit od hostingu nebo správce.

Co se stalo

Bezpečnostní tým PHP zveřejnil 21. října 2026 dvě chyby, které společně umožňují vzdálené spuštění kódu. První (CVE-2026-109618) vznikne, když serveru dojde paměť přesně ve chvíli, kdy PHP teprve připravuje zpracování požadavku. PHP tehdy zpracování přeruší, ale při úklidu pracuje s neplatnými daty. Druhá (CVE-2026-109619) způsobí, že ve workeru zůstane stav z předchozího požadavku a další požadavek ho použije dřív, než se správně vynuluje. Útočník to umí vyvolat speciálně poskládaným požadavkem, například formulářem s obrovským počtem hlaviček, a nepotřebuje žádné heslo ani účet. Kód se spustí ještě předtím, než se dostane ke slovu samotná aplikace.

Obě chyby mají hodnocení 9,2 z 10, tedy kritické. Nahlásili je bezpečnostní výzkumníci, opravu připravil tým PHP a zveřejnil ji společně s chybami.

Koho se to týká

• Každého webu, který běží na PHP. WordPress, WooCommerce, PrestaShop, Magento, Drupal, Joomla, Laravel, Symfony, Nette i aplikace na míru. Podle odhadu CERT-EU jde o větve PHP 5, 7 i 8.
• Nejvíc servery s Apache mod_php. U tohoto nastavení tým PHP potvrdil plný útok přes obyčejný HTTP požadavek s výchozími limity. Je to typická konfigurace starších sdílených hostingů a starších vlastních serverů.
• PHP-FPM, FrankenPHP a LiteSpeed jsou zranitelné také, u FPM byl útok přes session potvrzen. To je dnes nejčastější nastavení moderních hostingů.
• Staré verze PHP jsou v největším ohrožení. Větve 5.6, 7.x, 8.0 a 8.1 PHP oficiálně nepodporuje. Pro 7.4, 8.0 a 8.1 vydalo jen minimální zdrojové záplaty a je na distribucích a hostinzích, jestli je zabudují. Pro Debian a Ubuntu vyšly 21. října opravené balíky i pro 5.6 a 7.x.

Útočí se už?

K 21. říjnu 2026 není potvrzený žádný reálný průnik a chyby nejsou v katalogu aktivně zneužívaných zranitelností CISA. Cloudflare však hlásí první pokusy o zneužití a pro weby za svou sítí nasadil nouzová pravidla. Na internetu koluje video nástroje PHP2Shell, který spouští kód na aktuálních verzích WordPressu, Magenta, Joomly, Drupalu, Laravelu či Symfony. Veřejně šířený exploit zatím nefunguje, bezpečnostní firmy ale potvrdily, že chyby jsou reálné. U kritické chyby tohoto typu bývá funkční útok otázkou dnů.

Co má firma udělat ještě dnes

1. Zjistěte, kde web běží a jakou má verzi PHP. V administraci hostingu je verze u domény. U vlastního serveru se zeptejte správce. Pokud nevíte ani jedno, napište tomu, kdo vám web dělal.
2. Ověřte přesné číslo verze, ne jen „8.2". Opravené jsou až verze v tabulce níže. Cokoli nižšího je zranitelné.
3. Na sdíleném hostingu aktualizaci dělá poskytovatel. Vy to neovlivníte, ale můžete si to nechat písemně potvrdit. Jedna věta podpoře: „Potvrďte prosím, že PHP na mé doméně má opravu CVE-2026-109618 a CVE-2026-109619 z 21. 10. 2026."
4. Starý web na PHP 5.6 nebo 7.x řešte přednostně. Pokud hosting staré verze nepatchuje, web je otevřený a jediná skutečná odpověď je přechod na podporovanou verzi. Jak na to, píšeme v článku PHP 7.4 vs. 8.x: proč migrovat.
5. Když nejde aktualizovat hned, zmírněte riziko. Omezte velikost požadavků a uploadů na webovém serveru i v PHP (post_max_size, upload_max_filesize), vypněte session.upload_progress, u PHP 8.5 vypněte fatal_error_backtraces, zablokujte multipart požadavky, pokud web nepoužívá odesílání souborů, a nasaďte WAF. Jsou to zmírnění, ne oprava.
6. Po aktualizaci zkontrolujte, jestli se nic nestalo. Podezřelé jsou PHP procesy, které spouštějí shell nebo stahují soubory, neznámé soubory v kořenovém adresáři, nové naplánované úlohy a nové účty. Při podezření server izolovat a zachovat logy.

Větev PHP	Opravená verze	Poznámka
8.5	8.5.12	navíc vypnout fatal_error_backtraces, pokud nejde aktualizovat
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35
8.1, 8.0, 7.4	minimální záplaty zdrojového kódu od PHP	opravené balíky od distribucí, na hostingu si nechat potvrdit
7.0 až 7.3, 5.6	bez oficiální opravy	opravené balíky pro Debian a Ubuntu z 21. 10. 2026, jinak nutná migrace

Jak jsme reagovali my

Naše vlastní servery, na kterých běží hosting pro klienty, FaStorm i příjem dokladů dokl.sk, jsme záplatovali do dvou hodin od zveřejnění, včetně jednoho staršího webu na PHP 5.6, který dostal opravený balík od distribuce. Potom jsme prošli weby klientů na cizích hostinzích: spravovaný virtuální server jednoho z hostingů měl opravené balíky a restartované PHP ještě ten den, což jsme si ověřili přímo na serveru. Klientům na sdílených hostinzích jsme poslali doporučení, aby si opravu nechali potvrdit od poskytovatele, protože tam verzi nevidíme ani my.

Celé to trvalo jedno odpoledne, ale jen proto, že někdo sledoval oznámení PHP ve chvíli, kdy vyšla. Přesně na tom stojí bezpečnost firemního webu: ne na jednorázovém zabezpečení, ale na tom, že se někdo dozví o chybě v den zveřejnění a ví, kde všude je třeba zasáhnout. Co všechno má bezpečný web mít, jsme sepsali v článku Bezpečnost firemního webu, a kolik stojí, když to za vás někdo hlídá, v článku Kolik stojí údržba a servis webu. Takovou službu nabízíme jako údržbu webu od 750 Kč měsíčně, dnes je ale důležitější, abyste si opravu ověřili, než od koho ji máte.

Nevíte, na jaké verzi váš web běží, nebo vám hosting neodpovídá? Pošlete nám adresu webu, podíváme se, co se dá zjistit zvenku, a řekneme vám, koho a na co se ptát.

Časté otázky

Týká se to i mého webu na WordPressu nebo e-shopu?

Ano, pokud běží na PHP, a to je drtivá většina webů. Chyba není ve WordPressu ani v e-shopu, ale v samotném PHP, které je spouští. Zranitelný je server, ne aplikace, proto nepomůže aktualizovat WordPress, je třeba aktualizovat PHP. Na sdíleném hostingu to dělá poskytovatel, u vlastního serveru správce serveru.

Jak zjistím, jakou verzi PHP můj web používá?

V administraci hostingu bývá výběr verze PHP u domény, tam vidíte i přesné číslo. U vlastního serveru se zeptejte správce. Důležité je přesné číslo za druhou tečkou: opravené jsou 8.5.12, 8.4.27, 8.3.36 a 8.2.35 nebo novější. Samotné „8.2" nestačí. Pokud hosting ukazuje jen hlavní verzi, napište podpoře a nechte si potvrdit, že nasadili opravu z 21. října 2026.

Co když má web ještě PHP 7.4 nebo 5.6?

Tyto větve PHP oficiálně nepodporuje, pro 7.4, 8.0 a 8.1 vydalo jen minimální opravy zdrojového kódu. Distribuce a správci balíků je zabudovali do svých balíků, pro Debian a Ubuntu vyšly 21. října opravené balíky i pro 5.6 a 7.x. Na vlastním serveru se tedy dá záplatovat i starý web. Na sdíleném hostingu si to nechte potvrdit. Pokud hosting staré verze nepatchuje, je to nejrizikovější skupina webů a důvod k migraci, o které píšeme v článku o přechodu z PHP 7.4.

Útočí už hackeři?

K 21. říjnu 2026 není potvrzený žádný reálný průnik. Cloudflare hlásí první pokusy o zneužití a nasadil nouzová pravidla, na internetu koluje video nástroje PHP2Shell, který spouští kód na aktuálních verzích WordPressu, Magenta, Drupalu či Laravelu. Veřejně šířený exploit se zatím neukázal jako funkční. U kritické chyby tohoto typu je to ale otázka času, ne jestli, proto je třeba aktualizovat hned.

Co dělat, když aktualizaci nejde udělat hned?

Dočasně snižte velikost požadavků a uploadů na serveru, vypněte sledování průběhu uploadu v PHP (session.upload_progress), u PHP 8.5 vypněte fatal_error_backtraces, a pokud web nepoužívá odesílání souborů, zablokujte multipart požadavky na webovém serveru nebo ve firewallu. Pomůže i WAF, například Cloudflare. Jsou to zmírnění, ne oprava. Jediným úplným řešením je opravená verze PHP.

Závěr

Dvě chyby v PHP z 21. října 2026 dovolují spustit kód na serveru bez hesla a před spuštěním webu. Oprava existuje a je jediným úplným řešením: 8.5.12, 8.4.27, 8.3.36, 8.2.35 nebo opravený balík distribuce pro starší větve. Majitel firmy nemusí vědět, co je mod_php, musí jen dnes zjistit verzi PHP svého webu a nechat si potvrdit, že je opravená. Článek budeme aktualizovat, pokud se objeví potvrzené útoky nebo nové záplaty.