Tento týden byly zveřejněny dvě kritické bezpečnostní zranitelnosti v PHP, označené jako CVE-2026-109618 a CVE-2026-109619. Jde o zranitelnosti umožňující vzdálené spuštění kódu (RCE - Remote Code Execution) bez jakéhokoliv přihlášení. Obě zranitelnosti mají podle dostupných analýz závažnost CVSS 9,2 na stupnici do 10.

Jakou roli hraje PHP na webu

PHP je serverový skriptovací jazyk, který zpracovává dynamické části webových stránek. Je často nasazen na pozadí webserveru, kde zajišťuje dynamické generování obsahu, přístup do databáze a zpracování dat z ní, atd. Typický průběh požadavku vypadá zhruba takto:

1. Návštěvník pošle patřičnému webserveru požadavek na URL nějakého webu, např. https://vasedomena.cz/.
2. Webový server předá požadavek na pozadí PHP engine.
3. PHP spustí kód aplikace, požádá o data z databáze, následně je zpracuje a předá zpět webserveru ve formě HTML.
4. Webserver následně zajistí odeslání dat návštěvníkovi webu.

Zranitelnost přímo v PHP proto představuje vážnější riziko než běžná chyba např. v pluginu redakčního systému či šabloně vzhledu. Chyba v PHP totiž může ohrozit celkový provoz serveru, tedy vrstvu společnou pro všechny PHP weby na daném stroji. Ohroženy jsou tak všechny další weby, typicky pokud se jedná o nejběžnější – sdílený – hosting.

Co se stalo

Dne 21. října 2026 byly zveřejněny dvě kritické zranitelnosti, a zároveň vyšly bezpečnostní aktualizace PHP řešící tyto kritické chyby, souhrnně označované jako PHP2Shell:

• CVE-2026-109618 – chyba při zpracování nedostatku paměti RAM (out-of-memory, OOM). Pokud je překročen memory_limit, PHP může přerušit zpracování požadavku v okamžiku, kdy interní data nejsou plně inicializovaná. Při následném „úklidu“ v paměti může dojít k poškození paměti, ke vzdálenému spuštění kódu, pádu serveru a podobně závažným projevům.
• CVE-2026-109619 – zranitelnost typu use-after-free (CWE-416). Interní stav patřící jednomu požadavku může v paměti zůstat použitelný i poté, co byla paměť, do které byl uložen, uvolněna. Případný další požadavek obsloužený stejným PHP procesem pak může pracovat s neplatnými daty.

Zásadní problém je to, že útočník nemusí mít přihlašovací údaje k webu ani redakčnímu systému (CMS - WordPress, Drupal, Joomla atd.), který na webu běží. Vhodně připraveným HTTP požadavkem, který adresuje zkusmo vašemu webu, může v takto zranitelném prostředí potenciálně spustit libovolný kód, číst data dostupná danému procesu, pod kterým PHP běží atd.

Vliv na provoz různých verzí PHP – 5/7/8

Zranitelnosti se týkají širokého rozsahu verzí PHP. Podle dostupných analýz jsou postiženy verze od PHP 5.4 až po PHP 8.5.11. Oficiální opravy byly vydány pouze pro podporované větve PHP 8.2 až 8.5. Níže najdete vliv na jednotlivé verze PHP a možné varianty řešení problému:

• PHP 5.x – oficiální oprava nebyla vydána; jde o zastaralou, již nepodporovanou větev. Řešením je pouze migrace na podporovanou verzi PHP s nutnou (často zásadní) úpravou kódu aplikace/webu
• PHP 7.x – oficiální oprava nebyla vydána; větve PHP 7 jsou rovněž mimo běžnou podporu. Řešením je migrace na PHP 8.x s nutnou úpravou kódu aplikace/webu
• PHP 8.0 a 8.1 – oficiální úprava nebyla vydána. Řešením je migrace na PHP > 8.2
• PHP 8.2 – opraveno ve verzi 8.2.35, nutno přejít min. na tuto verzi
• PHP 8.3 – opraveno ve verzi 8.3.36, nutno přejít min. na tuto verzi
• PHP 8.4 – opraveno ve verzi 8.4.27, nutno přejít min. na tuto verzi
• PHP 8.5 – opraveno ve verzi 8.5.12, nutno přejít min. na tuto verzi

Všichni naši zákazníci byli informováni individuálně, a to v kontextu konkrétní verze PHP, kterou jejich web skutečně používá. Informace proto nebyla obecná, ale rozlišovala mezi:

• weby na opravitelných verzích PHP 8.2.x, 8.3.x, 8.4.x a 8.5.x,
• weby na starších verzích PHP, pro které oficiální oprava neexistuje,
• weby, u nichž byla nutná migrace na webserver s novějším PHP,
• weby, u nichž je třeba následně ověřit kompatibilitu celého webu/aplikace, pluginů redakčního systému, šablon vzhledu atd.

Cílem tohoto přístupu bylo, aby každý zákazník věděl, zda a jaký úkon jeho konkrétní web vyžaduje.

Souhrn bezpečnostních opatření – nutný přesun webů na webserver s PHP 8.x

U webů běžících na PHP 5.x nebo 7.x nebylo možné aplikovat oficiální bezpečnostní update, protože pro tyto větve nebyl vydán. Z tohoto důvodu jsme tyto weby, i když jejich aplikace nebyly zcela kompatibilní s PHP 8.x, přesunuli na webový server s PHP 8.x. Toto řešení výrazně snižuje riziko zneužití kritických zranitelností PHP, protože web přestal běžet na zranitelné a již nepodporované verzi PHP.

Rozumíme tomu, že přechod z PHP 5.x či 7.x na PHP 8.x může vyžadovat následnou úpravu staršího kódu, pluginů nebo šablon. Bezpečnost však v této situaci měla přednost – ponechání webu na PHP 5.x či 7.x by znamenalo provoz bez dostupné oficiální opravy kritické zranitelnosti, a ohrožoval by jak váš vlastní web, tak naši hostingovou infrastrukturu. Konec konců – PHP 8.x bylo uvedeno v r. 2022, což znamená, že na úpravu staršího kódu měl každý majitel webu dodnes cca 4 roky času.

Děkujeme za pochopení. V případě jakýchkoliv dotazů nás neváhejte kontaktovat.