Zkušenosti z praxe

PHP2Shell: dvě kritické zranitelnosti PHP a naše reakce

Dvě kritické zranitelnosti PHP vyžadují aktualizace a přesnou kontrolu inventáře. Jak DAXS propojuje vyhodnocení, omezení přístupu a technické ověření.

Bezpečnost
Jezevčík DAXS s abstraktními ochrannými vrstvami a oranžovým symbolem aktualizace.

Od předběžného upozornění z 20. října mají PHP2Shell na seznamu kontrol mnozí správci IT. Dne 21. října 2026 projekt PHP vydal bezpečnostní aktualizace pro dvě kritické zranitelnosti. Pro DAXS to znamenalo technicky vyhodnotit zprávy, hledat potenciálně dotčené služby a určit priority podle skutečné dostupnosti. Rozhoduje to, co na daném systému skutečně běží, nikoli pouhé uzavření úkolu aktualizace.

Co bylo zveřejněno

Zranitelnosti CVE-2026-109618 a CVE-2026-109619 mohou umožnit spuštění cizího kódu bez předchozího přihlášení. Předběžné upozornění uvádí u obou CVSS v4.0 9,2. Kritické hodnocení je důvodem k rychlé kontrole; nedokazuje však, která konkrétní zákaznická instalace byla úspěšně napadena.

Projekt PHP uvádí opravené verze 8.5.12, 8.4.27, 8.3.36 a 8.2.35. Balíčky spravované distribucemi mohou obsahovat zpětně přenesené bezpečnostní opravy. Nižší zobrazená základní verze proto sama nedokazuje chybějící ochranu ani úspěšnou opravu. Rozhodují přesný balíček, informace dodavatele a skutečně používané běhové prostředí.

Upozornění se týkají různých napojení na webové servery. PHP zdůrazňuje riziko u Apache s mod_php; z toho neplyne plošné potvrzení bezpečnosti PHP-FPM ani jiných způsobů provozu. Součásti, rozšíření a nastavení se posuzují pro každé prostředí zvlášť. Název produktu v inventáři nestačí.

Časová osa: předběžné upozornění 20. října, aktualizace PHP 21. října a pokračující jednotlivé kontroly 22. října 2026.
Od upozornění k ověřitelné reakci

Naše první otázka: kde PHP skutečně běží?

Dostupná upozornění jsme porovnali s dosavadními znalostmi systémů. Inventář zahrnuje veřejné weby, administrační rozhraní, doplňkové aplikace i služby, které dodávají PHP jako součást. Priority určuje vnější dostupnost služby, její účel a odpovědnost za aktualizaci. Nejasné záznamy dostávají konkrétní kontrolní úkol.

Rozlišujeme nainstalovaný balíček a aktivní webovou službu. Vedle sebe může existovat několik verzí PHP. Ani úspěšná aktualizace programu pro příkazovou řádku nedokazuje, jaké běhové prostředí používá konkrétní proces webového serveru. Po změně proto musí být dohledatelně ověřeny dotčené služby a jejich účinná nastavení. Veřejně dostupná diagnostická stránka není trvalým řešením.

Inventář musí zahrnout také méně nápadné systémy. Webová správa může být vedlejší funkcí zařízení a přesto vytvářet další prostor pro útok. Zda vůbec používá PHP a potřebuje opravu, zůstává technickou otázkou. Samotná existence webového rozhraní neprokazuje dotčení zranitelností.

Aktualizovat, ověřit účinnost a zaznamenat otevřené body

Praktický postup začíná inventarizací a vyhodnocením. Dostupné bezpečnostní aktualizace se následně instalují podle priorit. Kontroluje se verze balíčku, nutné restarty, účinná konfigurace a potřebné aplikační funkce. Odpovědné osoby musí vidět, které služby již byly ověřeny a kde ještě chybí odpověď dodavatele, vhodný balíček či technické převzetí.

Pokud specializovanou službu nelze aktualizovat ihned, nejprve posuzujeme, jaká přímá veřejná dostupnost je opravdu nutná. Nepotřebný přístup z internetu lze dočasně odstranit. Oprávněné interní použití lze případně zachovat prostřednictvím vhodně oddělených přístupů. Jde o záměrně omezené opatření, jehož účinek i provozní dopady je nutné ověřit; software se tím automaticky nestává bezchybným.

Úkol nekončí spuštěním aktualizace. Potřebuje dohledatelné uzavření nebo pojmenovaný otevřený bod s odpovědnou osobou. Po omezení přístupu se ověřuje zbývající dostupnost. Po instalaci opravy následuje kontrola skutečně používané služby. Obojí patří do průběžně vedené provozní dokumentace.

Součástí výsledku je i distribuční cesta softwaru. U instalace spravované operačním systémem se porovnává bezpečnostní zpráva distribuce s nainstalovaným balíčkem. U přibaleného běhového prostředí rozhodují informace příslušného dodavatele produktu. To pomáhá předejít chybné interpretaci samotného čísla verze. Nestačí-li důkazy, bod zůstává otevřený s dalším kontrolním krokem. Zelený stav bez ověřitelného podkladu by byl zavádějící.

Rozhodovací postup: inventarizovat službu, ověřit vhodnou opravu, aktualizovat nebo omezit nepotřebné veřejné přístupy a poté ověřovat účinek a sledovat otevřené body.
Aktualizaci a dostupnost ověřovat zvlášť

Co přinášejí WAF, proxy, firewally a oddělené sítě

WAF, reverzní proxy, firewally a VLAN již patří mezi nástroje k omezení přístupů a datových cest. Firewall řídí povolená spojení, proxy soustřeďuje vymezené webové přístupy a oddělené sítě pomáhají omezovat povolenou komunikaci. Tyto funkce jsou cenné, neodstraňují však každou zranitelnost uvnitř procesu PHP.

Zejména nelze PHP2Shell prezentovat jako plně vyřešený WAF před aplikací nebo uvnitř ní. Projekt PHP označuje aktualizaci za úplné řešení; dočasná omezení pokrývají jen určité cesty útoku. Tyto vrstvy proto posuzujeme spolu se stavem oprav a ověřujeme, zda jiná cesta nemůže zamýšlené omezení obejít.

Zjednodušený model: internet, firewall, oddělené sítě, proxy nebo WAF a aplikace PHP. Řízení přístupu nenahrazuje bezpečnostní aktualizaci PHP.
Ochranné vrstvy a údržba softwaru patří k sobě

Izolované testy a AI podporují odborný úsudek

Pro technické posouzení jsme použili také vlastní izolovaná testovací prostředí. Claude a OpenAI Codex pomáhaly s rešerší a jejich přípravou. Rozhodující byly odborný úsudek a spolehlivé technické zdroje. Věrohodná odpověď AI nenahrazuje důkaz nainstalované verze ani ověření účinného nastavení.

Sledování zůstává nutné i po aktualizaci. Neobvyklé chyby, neočekávané procesy nebo spojení se posuzují vůči běžnému chování systému. Nainstalovaná oprava zpětně nedokazuje, že se předtím nic nestalo. Stejně tak jediný nezvyklý záznam v logu není spolehlivým důkazem úspěšného útoku.

Veřejné zprávy v souvislostech

Zpráva Vídeňské univerzity o omezení centrálních IT služeb ukazuje, jak výrazně mohou zasáhnout preventivní opatření. Aktualizované oznámení uvádí, že většina služeb je již opět dostupná. Veřejné informace pomáhají objasnit situaci, nevypovídají však o stavu jiné organizace ani konkrétního prostředí spravovaného DAXS.

Také upozornění dodavatele musí odpovídat konkrétní službě. Dodavatel může rozlišovat své produkty a hostovaný portál, který provozuje. Vyjádření k jednomu produktu nelze vztahovat na libovolné aplikace třetích stran. U OPNsense, FreePBX, Sophos či jednotlivého gateway proto záleží na přesné verzi, přibalených součástech, pokynech dodavatele a skutečných přístupech.

Příprava umožňuje ověřit reakci

Užitečný inventář, jasné odpovědnosti a připravené aktualizační postupy usnadňují reakci na kritická upozornění. Nezveřejňujeme nedoložené procento opravených systémů ani plošné potvrzení bezpečnosti všech instalací. Rozhodující jsou dohledatelné jednotlivé kontroly a pokračující práce s otevřenými případy. V pátek se podíváme, jak AI pomáhá dostat do kontrolního seznamu snadno přehlédnutelná zařízení.

Probrat bezpečnost a správu oprav

Více o systematickém posuzování bezpečnosti