22 říjen 2026 / 11 minut čtení
Web vaší společnosti může být plně aktualizovaný, všechny pluginy zabezpečené a přístupová oprávnění správně nastavená. Útočník přesto může získat kontrolu nad serverem, aniž by se musel přihlásit. Dvě kritické zranitelnosti PHP, souhrnně označované jako PHP2Shell, představují bezpečnostní riziko, které se netýká pouze samotných webových stránek. Nejnovější zjištění Amazonu navíc ukazují, že pokusy o jejich zneužití se objevily už čtyři dny před oficiálním zveřejněním.
Dne 21. října 2026 byly zveřejněny dvě kritické zranitelnosti v prostředí PHP, evidované pod označeními CVE-2026-109618 a CVE-2026-109619. Obě získaly hodnocení CVSS v4.0 ve výši 9,2 z 10 a za určitých podmínek umožňují vzdálené spuštění škodlivého kódu (Remote Code Execution, RCE) bez nutnosti přihlášení.
PHP tvoří základ významné části světových webových stránek, včetně e-shopů, zákaznických portálů a redakčních systémů, jako jsou WordPress, Drupal nebo Joomla. Podle výzkumníků společnosti Wiz využívá PHP přibližně 70 % webových stránek. To však neznamená, že jsou všechny tyto weby zranitelné. Skutečné riziko závisí na používané verzi PHP, konfiguraci serveru a dostupných bezpečnostních aktualizacích.
Na rozdíl od běžných zranitelností webových aplikací zasahuje PHP2Shell samotné prostředí PHP, nikoli konkrétní plugin, redakční systém nebo aplikaci. Aktualizace WordPressu proto problém nevyřeší, pokud server nadále používá zranitelnou verzi PHP.
Obě zranitelnosti souvisejí s chybami při práci s pamětí během zpracování HTTP požadavků. Jejich technické příčiny se však liší.
CVE-2026-109618 – Vzdálené spuštění kódu v důsledku chyby při správě paměti
Pokud během zpracování požadavku selže přidělení paměti, PHP může ponechat některé interní datové struktury pouze částečně inicializované. Při následném uvolňování paměti může dojít k nesprávnému zpracování neplatných údajů, což za určitých okolností umožňuje spuštění libovolného kódu.
CVE-2026-109619 – Vzdálené spuštění kódu v důsledku opětovného použití neplatného interního stavu
Druhá zranitelnost souvisí se situací, kdy interní údaje z předchozího požadavku zůstanou dostupné i po uvolnění příslušné paměti. Další požadavek zpracovaný stejným procesem PHP může tento neplatný stav znovu použít ještě před jeho správnou inicializací. Výsledkem může být neoprávněný přístup do paměti nebo spuštění škodlivého kódu.
Bezpečnostním výzkumníkům se podařilo zneužití PHP2Shell nezávisle reprodukovat. Společnost Datadog Security Labs zdokumentovala útok využívající CVE-2026-109618, při kterém speciálně připravený HTTP požadavek umožnil spuštění škodlivého kódu bez přihlášení, a to ještě před vykonáním samotného aplikačního kódu.
Právě v tom spočívá mimořádná nebezpečnost PHP2Shell: bezpečnostní mechanismy aplikace včetně autentizace nemusí vůbec dostat příležitost útok zastavit.
Úspěšné zneužití může útočníkovi umožnit přístup k citlivým informacím, spouštění škodlivých procesů, instalaci malwaru nebo využití napadeného serveru k dalším útokům. Rozsah následků závisí na oprávněních procesu PHP a zabezpečení okolní infrastruktury.
Podle výzkumníků společnosti Wiz mají některé zranitelné mechanismy PHP původ ještě ve verzi PHP 5.4, která byla vydána v roce 2012.
Na objevení, analýze a koordinovaném odstraňování zranitelností se podíleli výzkumníci ze společností Wiz, Calif, OpenAI a Quarkslab. Pokročilé modely umělé inteligence jim pomáhaly analyzovat složité chování paměti, vyvíjet funkční exploity a ověřovat účinnost oprav.
Podle Wiz využití AI výrazně urychlilo také přizpůsobování exploitů různým aplikačním prostředím.
Tato zjištění poukazují na širší změnu v kybernetické bezpečnosti. Zranitelnosti, jejichž analýza v minulosti vyžadovala rozsáhlý manuální výzkum, může být díky pokročilým AI nástrojům jednodušší prozkoumat i zneužít.
Pro bezpečnostní týmy to znamená, že doba mezi zveřejněním zranitelnosti a jejím reálným zneužíváním se může dále zkracovat. PHP2Shell ukazuje, proč musí organizace dokázat na nové bezpečnostní hrozby rychle reagovat.
Nová zjištění týmu Amazon Threat Intelligence, publikovaná 22. října, ukazují, že se útočníci pokoušeli zneužít PHP2Shell ještě před oficiálním zveřejněním zranitelností.
Amazon identifikoval první pokus už 17. října 2026 prostřednictvím své sítě návnadových systémů MadPot. Aktivita pocházela z IP adresy spojené s komerční anonymizační službou.
Další pokusy následovaly 21. října a pocházely z různých anonymizovaných zdrojů. Zjištění naznačují, že informace o zranitelnostech mohlo mít před jejich veřejným zveřejněním k dispozici více útočníků.
Po vydání bezpečnostních oprav se začaly objevovat veřejně dostupné exploity, které byly krátce nato zaznamenány při útocích na senzory Amazonu.
Společnost Cloudflare nezávisle potvrdila škodlivý provoz související s PHP2Shell, včetně pokusů obejít její bezpečnostní pravidla. Následně nasadila ochranná opatření na úrovni webového aplikačního firewallu (WAF) také pro uživatele bezplatných služeb.
Tato zjištění jsou mimořádně důležitá, protože pokusy o zneužití předcházely oficiálnímu zveřejnění zranitelností. Organizace by proto při prověřování možného napadení neměly analyzovat pouze události po vydání bezpečnostních aktualizací, ale také starší záznamy.
Zároveň je však nutné rozlišovat mezi zaznamenanými pokusy o útok a úspěšným proniknutím do produkčních systémů. Samotná pozorování bezpečnostních společností ještě neprokazují, že se útočníkům podařilo konkrétní organizace kompromitovat.
Bezpečnostní tým PHP upozorňuje na rizika v několika prostředích používaných k provozu webových aplikací, včetně Apache s modulem mod_php, PHP-FPM, php-cgi, FrankenPHP a LiteSpeed.
Za obzvlášť rizikovou je považována konfigurace Apache s mod_php, u které bylo prokázáno zneužití bez autentizace ještě před spuštěním aplikačního kódu. Ani ostatní způsoby nasazení však nelze bez důkladného ověření považovat za bezpečné.
Dne 21. října 2026 byly vydány následující opravené verze PHP:
Verze PHP 8.1 a starší již nemají oficiální podporu projektu PHP. Některé linuxové distribuce a poskytovatelé dlouhodobé podpory však nabízejí bezpečnostní opravy i pro starší verze. Bezpečnostní tým PHP zároveň zpřístupnil minimální úpravy zdrojového kódu pro PHP 7.4, 8.0 a 8.1.
Organizace by proto měly kontrolovat bezpečnostní oznámení a seznamy změn svých dodavatelů, nikoli pouze samotné číslo používané verze PHP.
1. Identifikovat všechny systémy využívající PHP. Zmapujte veřejně dostupné webové aplikace, interní systémy, kontejnery, řešení třetích stran i další prostředí, ve kterých se PHP používá. Prioritu by měly mít systémy přístupné z internetu a aplikace pracující s citlivými údaji.
2. Bezodkladně nasadit bezpečnostní aktualizace. Aktualizujte PHP na opravenou verzi nebo nainstalujte bezpečnostní opravu podporovanou dodavatelem. Restartujte Apache, PHP-FPM a další dlouhodobě běžící procesy PHP a ověřte, že aktualizovaná verze je skutečně aktivní. U kontejnerových prostředí je nutné vytvořit nové obrazy a znovu nasadit příslušné služby. Samotná aktualizace zdrojového kódu totiž produkční prostředí nezabezpečí.
3. Prověřit možné napadení včetně období před zveřejněním. Analyzujte bezpečnostní záznamy minimálně od 17. října, kdy Amazon zaznamenal první pokus o zneužití. Zaměřte se na podezřelé HTTP požadavky, neobvykle velká formulářová data, chyby související s nedostatkem paměti, neočekávané procesy spuštěné prostřednictvím PHP a neoprávněné změny souborů. Pokud je to možné, vyhodnocujte společně záznamy webového serveru, koncových systémů a síťového provozu.
4. Omezit riziko tam, kde není možné aktualizovat okamžitě. Použijte ochranná pravidla WAF doporučená dodavateli, omezte nepotřebný veřejný přístup a zvažte dočasnou izolaci zranitelných služeb. Tato opatření mohou snížit riziko, ale nenahrazují bezpečnostní opravu.
5. Ověřit bezpečnost i po aktualizaci. Zkontrolujte, zda byla všechna zranitelná prostředí skutečně aktualizována, ověřte účinnost bezpečnostních opatření a prověřte podezřelou aktivitu z období před nasazením oprav. Odstranění zranitelnosti a prověření možného napadení jsou dva samostatné úkoly.
Výzkum společnosti Datadog upozorňuje na důležitý problém při odhalování útoků: úspěšné zneužití PHP2Shell nemusí způsobit pád procesu PHP.
Napadený server tak může nadále fungovat bez viditelných problémů a správce nemusí zaznamenat žádné zjevné příznaky útoku.
Bezpečnostní týmy by se proto neměly spoléhat pouze na dostupnost služeb. Důležitými indikátory mohou být neočekávané spouštění příkazů, neobvyklé chování procesů PHP, chyby při práci s pamětí nebo podezřelá HTTP komunikace.
Další možnosti nabízí monitorování síťového provozu. Společnost Corelight zveřejnila detekční pravidla pro nástroje Zeek a Suricata, zatímco Elastic představila přístupy založené na sledování podezřelého chování procesů a následné aktivity útočníků. Účinnost těchto opatření však závisí na dostupných datech, konfiguraci a konkrétním způsobu útoku.
Google Cloud zároveň upozornil, že u cloudových prostředí nestačí aktualizovat zdrojový kód. Je nutné aktualizovat také skutečně nasazené aplikace a jejich závislosti. Mimořádně důležité je to u kontejnerů, kde mohou zranitelné verze PHP zůstat v provozu i po vydání bezpečnostních oprav.
Svá omezení mají také dočasná konfigurační opatření. Například vypnutí funkce session.upload_progress může snížit riziko některých způsobů útoku, ale samotné zranitelnosti neodstraní.
Základním opatřením proto zůstává nasazení příslušných bezpečnostních aktualizací PHP.
PHP2Shell otevírá otázku, která výrazně přesahuje samotné PHP: Do jaké míry má vaše organizace přehled o technologiích, na kterých fungují její klíčové aplikace?
Aplikace může úspěšně projít bezpečnostním auditem, využívat silnou autentizaci a dostávat pravidelné aktualizace. Přesto může zůstat zranitelná v důsledku chyby v prostředí, na kterém běží, v jejích závislostech nebo v konfiguraci serveru.
Pro technologické a bezpečnostní lídry jsou proto zásadní tři oblasti:
Zjištění Amazonu přitom upozorňují na další důležitou skutečnost. Organizace nemohou automaticky předpokládat, že období před veřejným zveřejněním zranitelnosti bylo bezpečné. Pokud se objeví důvěryhodné důkazy o dřívějších pokusech o zneužití, bezpečnostní prověřování musí zohlednit i toto období.
Tyto schopnosti nejsou důležité pouze u PHP2Shell. Jsou základem účinné reakce na budoucí zranitelnosti v široce používaných softwarových technologiích.
PHP2Shell ukazuje, jak mohou zranitelnosti v základních technologiích ohrozit i jinak dobře zabezpečené aplikace.
Bezprostřední priority jsou jasné: aktualizovat zranitelné instalace PHP a prověřit možné pokusy o napadení včetně období před oficiálním zveřejněním.
Z dlouhodobého hlediska by však organizace měly posoudit také to, zda mají dostatečný přehled o technologických závislostech svých aplikací, konfiguracích serverů a možnostech dalšího postupu útočníka po případném proniknutí do systému.
Profesionální penetrační testování pomáhá organizacím odhalovat slabá místa webových aplikací a infrastruktury, ověřovat možnosti jejich zneužití a pochopit potenciální dopad na fungování firmy.
Potřebujete prověřit bezpečnost svých webových aplikací nebo infrastruktury? Bezpečnostní experti Citadelo vám pomohou identifikovat zranitelnosti, vyhodnotit rizika a určit priority při jejich odstraňování.
Všechny články
Přihlaste se k odběru našeho newsletteru a získejte všechny důležité novinky v oblasti kybernetické bezpečnosti a etického hackování.