Ve středu 21. října 2026 vydal tým PHP nouzové bezpečnostní aktualizace, které opravují dvě kritické zranitelnosti v samotném jádru jazyka: CVE-2026-109618 a CVE-2026-109619. Bezpečnostní komunita jim přezdívá PHP2Shell a důvod je jednoduchý – útočník může pomocí podvrženého HTTP požadavku spustit na serveru vlastní kód, a to bez jakéhokoliv přihlášení.

Protože chyba sedí v PHP samotném, netýká se jednoho konkrétního redakčního systému nebo e‑shopové platformy. Týká se prakticky každého webu, který na PHP běží – WordPressu, PrestaShopu, Magenta, Shopwaru, Laravelu i aplikací psaných na míru. A to i tehdy, když je kód vaší aplikace naprosto v pořádku.

Co se vlastně stalo

Na zranitelnostech se pracovalo v rámci koordinovaného zveřejnění od letošního srpna. Plán ale narušil únik informací: 20. října se detaily objevily na internetu ještě předtím, než byly k dispozici opravy. Tým PHP proto vydání urychlil a opravené verze zveřejnil 21. října ve 14:00 UTC.

Obě zranitelnosti mají hodnocení CVSS v4.0 9.2, tedy kritické. A nejde jen o teorii – bezpečnostní firmy už zaznamenaly první útoky v reálném provozu. Pokud tedy provozujete web na PHP, nejde o aktualizaci, kterou je možné odložit na příští měsíc.

Co přesně zranitelnosti dělají

Obě chyby souvisí se správou paměti v jádru PHP:

  • CVE-2026-109618 – spuštění kódu přes poškození paměti při jejím nedostatku. Když PHP během zpracování požadavku narazí na limit paměti, je přerušeno ve chvíli, kdy jsou interní data požadavku sestavená jen napůl. Následný úklid s nimi ale zachází jako s platnými, což vede k poškození paměti a v důsledku až ke spuštění kódu útočníka.
  • CVE-2026-109619 – spuštění kódu přes „zatuchlý“ globální stav. Interní stav patřící jednomu požadavku může přežít uvolnění paměti, na které ukazuje. Další požadavek obsloužený stejným procesem ho pak může použít dřív, než dojde k jeho resetu.

Nejnepříjemnější vlastnost obou chyb je, že k útoku dochází ještě předtím, než se vůbec spustí kód vaší aplikace. Žádný bezpečnostní plugin, firewall uvnitř CMS ani pečlivě napsaný kód vás tedy neochrání. Zranitelný kód je v PHP přítomen už od verze 5.4 z roku 2012.

Ohrožený je každý způsob, jakým PHP obsluhuje webové požadavky: PHP-FPM, Apache s mod_php, php-cgi, FrankenPHP i LiteSpeed. Nejvyšší riziko nesou servery s Apache a mod_php.

Kterých verzí PHP se to týká

Opravy vyšly pouze pro aktuálně podporované větve PHP:

  • PHP 8.5 – zranitelné verze nižší než 8.5.12, opraveno v 8.5.12
  • PHP 8.4 – zranitelné verze nižší než 8.4.27, opraveno v 8.4.27
  • PHP 8.3 – zranitelné verze nižší než 8.3.36, opraveno v 8.3.36
  • PHP 8.2 – zranitelné verze nižší než 8.2.35, opraveno v 8.2.35
  • PHP 8.1 a starší – oficiální oprava nevyšla, tyto verze už nejsou podporované

Pokud web běží na PHP 8.1, 8.0, 7.4 nebo dokonce starším, je zranitelný a oficiální cestou se ochránit nedá jinak než přechodem na novější podporovanou verzi. Někteří dodavatelé linuxových distribucí a hostingových platforem sice připravili vlastní záplaty i pro starší verze, takové balíčky ale často nesou nižší číslo verze než oficiální vydání. U nich je potřeba ověřit opravu v changelogu balíčku podle čísel CVE, ne podle čísla verze.

Proč PHP 8.2 není řešením

Na první pohled by se mohlo zdát, že nejjednodušší je u starších webů přejít na PHP 8.2 jako nejnižší opravenou verzi. Jenže podpora PHP 8.2 končí 31. prosince 2026. Opravy chyb přestala dostávat už na konci roku 2024 a od Nového roku nedostane ani bezpečnostní záplaty. Pokud by se po tomto datu objevila další podobná zranitelnost, weby na PHP 8.2 by na tom byly stejně jako dnes weby na PHP 8.1.

Migrace z PHP 7.4 nebo 8.1 na 8.2 tak znamená udělat celou práci, abyste ji za pár týdnů dělali znovu. Rozumnějším cílem je PHP 8.4, které má bezpečnostní podporu až do konce roku 2028, případně PHP 8.5 s podporou do konce roku 2029. A pokud už na PHP 8.2 běžíte, opravnou aktualizaci na 8.2.35 nasaďte hned, ale přechod na vyšší verzi naplánujte ještě letos.

Co udělat hned

  • Zjistěte, jakou verzi PHP váš web skutečně používá. Pozor, příkaz php -v v terminálu ukazuje verzi pro příkazovou řádku, která se může lišit od verze, se kterou běží web (PHP-FPM, mod_php). Spolehlivější je ověřit verzi v administraci hostingu nebo přímo v konfiguraci webového serveru.
  • Aktualizujte na opravenou verzi ve své větvi a restartujte PHP-FPM nebo Apache. Bez restartu běží dál staré procesy se zranitelným kódem.
  • Pokud aktualizace není možná okamžitě, nasaďte dočasná opatření. V php.ini nebo v konfiguraci FPM poolu nastavte session.upload_progress.enabled = 0, na PHP 8.5 navíc fatal_error_backtraces = 0, a PHP restartujte. Tato nastavení blokují známé cesty útoku, nejsou ale úplnou ochranou – jedinou skutečnou opravou je aktualizace.
  • Zkontrolujte, zda server nebyl kompromitován. Protože útoky probíhaly ještě před vydáním oprav, vyplatí se projít přístupové logy, hledat neznámé PHP soubory, nové uživatelské účty nebo podezřelé úlohy v cronu.

Tým PHP doporučuje nechat session.upload_progress vypnuté i po aktualizaci, pokud tuto funkci nepoužíváte. Většina webů a e‑shopů ji nepotřebuje.

Jak funguje povýšení verze PHP u jakékoliv webové aplikace

Je potřeba rozlišit dva typy aktualizace. Opravná aktualizace v rámci větve (například z 8.3.30 na 8.3.36) obsahuje jen opravy chyb a bezpečnostní záplaty, kód aplikace se kvůli ní měnit nemusí a riziko problémů je nízké. Přechod na novou větev (například z 7.4 nebo 8.1 na 8.2 a vyšší) je ale skutečný projekt, protože každá větev odstraňuje zastaralé funkce a mění chování jazyka. Ať jde o WordPress, PrestaShop, Laravel nebo systém na míru, postup je v principu vždy stejný.

1. Inventura

Zjistíme aktuální verzi PHP, způsob běhu (FPM, mod_php), seznam použitých rozšíření (php -m) a verze všeho, co na PHP stojí: jádra CMS nebo frameworku, modulů, pluginů, šablon a knihoven v composer.json. Často se tu objeví první problém – modul, který autor přestal vyvíjet a na novém PHP nefunguje.

2. Analýza kompatibility

Ověříme, kterou verzi PHP podporuje použitá verze CMS nebo frameworku, a kód projdeme nástroji pro statickou analýzu, jako je PHPCompatibility nebo PHPStan. Ty odhalí funkce, které v nové verzi zmizely – typicky each() nebo create_function() odstraněné v PHP 8.0 – nebo konstrukce, které jsou zastaralé, jako dynamické vlastnosti objektů od PHP 8.2. Velkou část rutinních úprav umí zautomatizovat nástroj Rector.

3. Testovací prostředí

Upgrade se nikdy nedělá rovnou na produkci. Připravíme kopii webu včetně databáze na testovacím serveru s cílovou verzí PHP a zapneme podrobné logování chyb včetně upozornění na zastaralé funkce. Hlášky, které by na produkci zůstaly skryté, tak vidíme dřív, než se z nich stanou chyby.

4. Úpravy kódu a závislostí

Aktualizujeme knihovny přes Composer, moduly a pluginy na verze kompatibilní s novým PHP, opustěné knihovny nahradíme a vlastní kód upravíme podle výsledků analýzy. U starších projektů je někdy nutné nejdřív aktualizovat samotný CMS nebo framework, protože jeho stará verze nové PHP nepodporuje.

5. Testování

Kromě automatických testů, pokud je projekt má, projdeme ručně všechny kritické scénáře: u e‑shopu košík, objednávku, platební bránu, dopravu, zákaznický účet a administraci. Nezapomínáme ani na věci, které nejsou vidět – importy a exporty, feedy, napojení na ERP a účetnictví, odesílání e‑mailů a úlohy spouštěné cronem.

6. Nasazení

V domluveném časovém okně uděláme zálohu, přepneme verzi PHP (v administraci hostingu, konfiguraci FPM poolu nebo v Docker image), restartujeme služby a vyčistíme OPcache i aplikační cache. Důležité je ohlídat, aby novou verzi používaly i skripty spouštěné z příkazové řádky a cronu.

7. Monitoring a plán návratu

Po nasazení sledujeme logy chyb, dostupnost a objednávky. Pro jistotu máme vždy připravený postup, jak se rychle vrátit k předchozímu stavu, kdyby se objevil problém, který testy neodhalily.

Proč nečekat na další incident

PHP2Shell ukazuje, proč je provozování webu na nepodporované verzi PHP skutečné riziko. Weby na PHP 8.2 a novějším dnes stačilo aktualizovat a restartovat. Weby na PHP 7.4 nebo 8.1 teď čeká migrace ve chvíli, kdy proti nim už běží útoky – a na konci roku se do stejné situace dostanou i weby na PHP 8.2. Pravidelné povyšování verze PHP je výrazně levnější a klidnější než nouzová migrace pod tlakem.

Jak vám můžeme pomoci v PixelBrothers

V PixelBrothers vyvíjíme weby, e‑shopy a aplikace na míru v PHP od roku 2016, staráme se o servery a hosting našich klientů a bezpečností se zabýváme dlouhodobě. S PHP2Shell vám můžeme pomoci hned v několika krocích:

  • Rychlá kontrola – ověříme, jakou verzi PHP váš web skutečně používá a zda je zranitelný.
  • Okamžitá ochrana – nasadíme opravenou verzi nebo dočasná opatření, dokud není upgrade hotový.
  • Kontrola kompromitace – projdeme logy a soubory na serveru a ověříme, že útočník nezanechal stopy.
  • Migrace na novější PHP – kompletní upgrade včetně úprav kódu, modulů a testování na testovacím prostředí.
  • Dlouhodobá správa – pravidelné aktualizace, monitoring a dohled, abyste podobné situace nemuseli řešit narychlo.

Nevíte, na jaké verzi PHP váš web nebo e‑shop běží, nebo potřebujete pomoct s aktualizací? Ozvěte se nám a podíváme se na to.