Stav informací: 21. října 2026

PHP vydalo 21. října 2026 bezpečnostní aktualizace, které řeší dvě kritické zranitelnosti umožňující vzdálené spuštění kódu bez přihlášení. Pro majitele WordPress webů a e-shopů to znamená ověřit zabezpečení PHP u hostingu. Samotná aktualizace redakčního systému tuto opravu nenahradí.

Podle oficiálního oznámení projektu PHP obsahují opravy verze PHP 8.2.35, 8.3.36, 8.4.27 a 8.5.12. Vývojáři vyzývají k neodkladné aktualizaci. Zpráva přichází v době, kdy se zároveň blíží konec bezpečnostní podpory PHP 8.2.

Pro provozovatele webu jsou důležité dvě otázky: dostal server aktuální bezpečnostní opravy a jak dlouho ještě bude používaná větev PHP podporovaná? Jde o dvě různé části správy webu, které je potřeba řešit společně.

Co se v PHP stalo a proč je to závažné

Zranitelnosti mají označení CVE-2026-109618 a CVE-2026-109619. CERT-EU u obou uvádí závažnost 9,2 z 10 podle CVSS a doporučuje okamžité nasazení oprav.

Vzdálené spuštění kódu, označované zkratkou RCE, znamená možnost přimět napadený systém, aby vykonal útočníkův kód. Konkrétní následky závisí na oprávněních procesu a zabezpečení serveru. Mohou zahrnovat zásah do souborů webu nebo přístup k datům, se kterými aplikace pracuje.

První chyba souvisí se zpracováním situace, kdy PHP dojde paměť. Za určitých okolností zůstane část interních dat nedokončená, ale následné ukončování požadavku s ní může zacházet jako s platnou. Technický popis je v oznámení CVE-2026-109618.

Druhá chyba se týká interního stavu, který může odkazovat na již uvolněnou paměť. Pozdější požadavek obsluhovaný stejným procesem se k tomuto stavu může dostat ještě před jeho správným obnovením. Podrobnosti zveřejňuje oznámení CVE-2026-109619.

CERT-EU mezi ohroženými způsoby provozu uvádí PHP-FPM, Apache s mod_php, php-cgi, FrankenPHP a LiteSpeed. Míra rizika a podmínky zneužití se liší. U mod_php byl předveden útok, který může nastat ještě před spuštěním samotného aplikačního kódu. To je důvod, proč nelze ochranu stavět pouze na kontrolách uvnitř webové aplikace.

Které verze PHP obsahují opravy

Následující tabulka uvádí první opravná vydání v jednotlivých podporovaných větvích. Při pozdějším čtení článku může být dostupná novější aktualizace.

Používaná větev	Vydání s opravou těchto chyb
PHP 8.2	8.2.35
PHP 8.3	8.3.36
PHP 8.4	8.4.27
PHP 8.5	8.5.12

Zdroj: bezpečnostní oznámení PHP.

Existuje také varianta, kdy dodavatel distribuce nebo rozšířené podpory začlení opravu do svého balíčku bez změny základního čísla PHP na hodnotu z tabulky. Takové zpětné začlenění opravy se označuje jako backport. U hostingu proto požadujte potvrzení opravy obou konkrétních CVE, pokud zobrazené číslo verze neodpovídá tabulce.

Proč se zpráva týká také WordPressu a WooCommerce

WordPress používá PHP na straně serveru. WordPress.org vysvětluje, že dostupné verze PHP určuje poskytovatel hostingu. Aktualizace WordPressu, šablony a pluginů jsou samostatné úkony.

Praktický důsledek je jednoduchý: zelené oznámení o aktuálních pluginech nepotvrzuje, že je opravené také PHP. U e-shopu na WooCommerce nebo firemního webu může být aplikace aktualizovaná, zatímco serverové prostředí ještě čeká na zásah správce.

Tato zpráva sama o sobě neznamená, že byl konkrétní web napaden. Je podnětem k ověření jeho prostředí. Ani bezproblémové načtení úvodní stránky ale není důkazem, že server zranitelnost neobsahuje.

Jak zjistit verzi PHP ve WordPressu

V administraci otevřete Nástroje → Zdraví webu → Informace → Server a najděte položku s verzí PHP. Tento postup uvádí také oficiální návod WordPressu.

Poznamenejte si celé číslo, například 8.4.26. Označení „PHP 8.4“ je pro kontrolu konkrétní bezpečnostní opravy příliš obecné.

Potom porovnejte údaj s tabulkou a případně se obraťte na podporu hostingu. Pokud spravujete více webů, zkontrolujte každý z nich: domény a subdomény mohou mít odlišná nastavení. Pro vlastní přehled se hodí zapsat doménu, zjištěnou verzi, datum kontroly a odpověď poskytovatele.

Co ověřit u hostingu a po aktualizaci

U sdíleného hostingu začněte dotazem na podporu. Požadujte potvrzení, zda prostředí vaší domény obsahuje opravy CVE-2026-109618 a CVE-2026-109619 a zda již běží opravené PHP. Obecné sdělení, že poskytovatel používá „podporovanou verzi“, na tuto otázku neodpovídá.

Před vlastní změnou verze připravte zálohu souborů i databáze. WordPress doporučuje také aktualizovat aplikaci, šablony a pluginy a ověřit jejich funkčnost. Při přechodu na jinou větev využijte testovací kopii webu, pokud ji máte k dispozici.

Pro provozní kontrolu po zásahu doporučuji projít skutečné úkony návštěvníka a správce:

přihlášení do administrace a uživatelského účtu;
odeslání kontaktního formuláře;
nahrání obrázku nebo přílohy;
vyhledávání a další důležité funkce webu;
u e-shopu košík a objednávku v dostupném testovacím režimu;
chybové záznamy a případná nová upozornění.

Rozlišujte při tom opravu uvnitř stejné větve, například 8.4.26 → 8.4.27, a přechod mezi větvemi, například 8.1 → 8.4. Druhý zásah vyžaduje širší kontrolu kompatibility. Neodkládejte však dostupnou bezpečnostní opravu jen proto, že se teprve připravuje větší modernizace webu.

Pokud opravu nelze rychle nasadit, má další postup posoudit správce serveru. CERT-EU doporučuje zvážit dočasnou izolaci veřejně dostupných aplikací do nasazení a ověření opravy. Univerzální rada upravit několik položek konfigurace není rovnocennou náhradou aktualizace.

PHP 8.1 je po konci podpory, PHP 8.2 čeká konec v prosinci

Bezpečnostní incident zároveň připomíná význam životního cyklu PHP. Udržovaná větev dostává nové opravy; po ukončení podpory je nutné řešit migraci nebo doloženou podporu od jiného dodavatele.

Podle oficiálního přehledu podpory PHP platí k 21. říjnu 2026 následující termíny:

Větev	Stav podpory	Konec bezpečnostní podpory projektu PHP
PHP 8.2	Pouze bezpečnostní opravy	31. prosince 2026
PHP 8.3	Pouze bezpečnostní opravy	31. prosince 2027
PHP 8.4	Aktivní podpora	31. prosince 2028
PHP 8.5	Aktivní podpora	31. prosince 2029

PHP 8.1 už běžnou podporu projektu nemá. Aktuální oznámení zmiňuje také mimořádné zdrojové backporty pro některé starší větve, které mohou pomoci správcům sestavujícím vlastní balíčky. Nejde o obnovení pravidelné podpory těchto verzí.

U webu na PHP 8.2 tedy vyřešte nynější opravu a současně naplánujte přechod před koncem roku. Cílovou verzi volte podle dostupnosti na hostingu a ověřené kompatibility celého webu, včetně vlastních úprav.

Co si z kontroly webu odnést

Výsledkem by mělo být konkrétní potvrzení: jaké PHP web používá, zda obsahuje obě opravy a kdo zajišťuje další aktualizace. U starší větve k tomu přidejte termín přechodu. Takový záznam je užitečnější než pouhé spoléhání na to, že hosting aktualizace pravděpodobně vyřešil.

Text vychází z veřejných bezpečnostních oznámení a dokumentace dostupných 21. října 2026. Nenahrazuje kontrolu konkrétního serveru.

Zdroje

Publikační podklady pro martinpenicka.cz

Tato část slouží pro nastavení příspěvku; není součástí článku pro čtenáře. Text je připravený koncept. Autorskou řádku „Martin Pěnička“ použijte po vlastní redakční kontrole a převzetí odpovědnosti za publikaci. Viditelné datum vydání nastavte na skutečný den a čas zveřejnění; údaj o stavu informací výše není datem publikace.

SEO údaje

Pole	Navržená hodnota
H1 / titulek příspěvku	PHP opravuje dvě kritické chyby. Co mají udělat majitelé WordPress webů
SEO title	Kritické chyby PHP: opravy a postup pro WordPress
Meta description	PHP opravilo dvě kritické bezpečnostní chyby. Přehled opravených verzí, kontrola PHP ve WordPressu a postup pro majitele webů i e-shopů.
Slug	php-kriticke-chyby-2026
Navržená adresa	https://martinpenicka.cz/php-kriticke-chyby-2026/
Hlavní tematická fráze	kritické chyby PHP
Související dotazy	aktualizace PHP WordPress; jak zjistit verzi PHP; konec podpory PHP 8.2
Rubrika	Bezpečnost webu, případně existující rubrika WordPress
Štítky	PHP, WordPress, bezpečnost webu
Sociální titulek	Dvě kritické chyby PHP: co ověřit u svého hostingu
Sociální popis	Opravy PHP už vyšly. Zkontrolujte konkrétní verzi a potvrzení hostingu — samotná aktualizace pluginů tuto opravu nenahradí.

Navržená adresa není ověřená existující URL. Přizpůsobte ji skutečné struktuře trvalých odkazů. Použijte jeden H1; pokud jej vytváří šablona z názvu příspěvku, nevkládejte jej podruhé do obsahu. Podnadpisy článku jsou H2. Klíčové fráze není nutné dále uměle opakovat.

Co připravit pro Google News

Google zpravodajský obsah vyhledává a posuzuje automaticky. Dobře napsaný článek ani splnění technických doporučení nezaručují jeho zobrazení či pořadí v Google News. Oficiální vysvětlení Googlu.

Viditelný autor a skutečné datum. U článku zobrazte autora, datum publikace a po podstatné úpravě datum aktualizace. Profil autora má popisovat skutečnou činnost a zkušenosti. Na webu mají být dohledatelné informace o vydavateli a kontakt. To odpovídá pravidlům transparentnosti Google News.
Dostupnost pro vyhledávač. Ověřte, že publikovaná URL vrací obsah, nevyžaduje přihlášení, nemá noindex a není blokovaná v robots.txt. Zkontrolujte správný canonical. V Search Console použijte kontrolu URL a případně požádejte o indexaci. Nejde o záruku okamžitého zařazení.
Strukturovaná data odpovídající textu. Pro tuto zprávu lze použít NewsArticle. Zkontrolujte headline, author.name, author.url, datePublished, případně dateModified a skutečnou image URL. Časy uvádějte s platným časovým posunem pro den publikace. Autorova URL musí vést na skutečný profil. Nevkládejte vymyšlená data ani neexistující obrázky. Pokud data již generuje SEO plugin, upravte je tam. Výsledek ověřte v Rich Results Testu. Dokumentace Article.
Sitemap. Zařaďte příspěvek do běžné XML sitemap. U pravidelného zpravodajského obsahu lze použít i news sitemap; zpravodajské záznamy v ní mají zahrnovat články z posledních dvou dnů. Starší články z webu nemažte. Dokumentace news sitemap.
Zdroje a věcný titulek. Zachovejte odkazy na původní oznámení. Nedoplňujte tvrzení o napadení konkrétního hostingu ani o počtu zasažených webů bez ověření. Před zveřejněním po jiném datu zkontrolujte novější opravná vydání.