U Apache s mod_php probíhá úklid i po nezdařeném startu požadavku. PHP-FPM při selhání této úvodní fáze ukončuje pracovní proces, což konkrétní cestu přerušuje. Nelze z toho ale dovodit bezpečnost FPM: nebezpečné stavy mohou vzniknout také během běhu aplikace. Opravný mechanismus mění zacházení s nedostatkem paměti, aby se zpracování nedostalo k neplatným datům; možnost omezovat spotřebu paměti přitom zůstává zachována.

CVE-2026-109619 má jiný průběh. Pracovní proces může po skončení požadavku uchovat odkaz na paměť, která už byla uvolněna. Další požadavek obsloužený stejným procesem s tímto pozůstatkem pracuje dříve, než ho běžná inicializace vyčistí. Jde o použití paměti po uvolnění, tedy use-after-free. Prokázané cesty zahrnují práci s diagnostikou fatálních chyb v PHP 8.5 a sledování průběhu nahrávání souborů přes sessions. U session varianty bylo spuštění kódu ověřeno na mod_php i FPM, přičemž cesta přes FPM závisí na vhodné operaci v aplikaci.

NHS England uvádí úspěšné výzkumné demonstrace v produktech využívajících PHP, včetně WordPressu, Drupalu a Joomly. Demonstrace ale neznamená, že každá instalace těchto produktů je stejně snadno zneužitelná, ani nedokládá napadení konkrétního webu. Výsledný dopad závisí na sestavení PHP, rozšířeních, konfiguraci a dostupných cestách zpracování vstupu. NÚKIB přesto doporučuje neodkládat aktualizaci a upozorňuje, že veřejně dostupné informace už mohou pomoci se zneužitím.

Cloudflare ve zprávě z 21. října potvrdil útočný provoz mířící na své zákazníky i průběžné změny útočných vstupů, kterými se útočníci pokoušeli obejít ochranu. To je doklad pozorovaných pokusů o zneužití, nikoli potvrzení napadení každého ohroženého webu. Firma nasadila ochrany do bezplatného i placeného WAF a upozornila, že samotné vyhodnocení požadavku nemusí stačit: její nové detekce kombinují údaje z požadavku a odpovědi serveru. Obecný příslib „silných pravidel WAF“ proto nelze považovat za úplné řešení. Také Cloudflare výslovně požaduje aktualizaci PHP; WAF chápe jako další obrannou vrstvu.

Společné evropské stanovisko zveřejněné agenturou ENISA doporučuje zjistit, kde organizace PHP skutečně používá, spojit se s poskytovateli hostingu a služeb a přednostně opravit systémy dostupné z internetu. PHP může být součástí komerčního či open-source produktu, aniž je tato závislost zvenčí patrná. Nestačí tedy projít jen seznam veřejných webů. Pokud rychlá náprava není možná, evropské doporučení počítá s dočasnou izolací vystavených aplikací od veřejných sítí.

U podporovaných větví je cílem instalace odpovídající opravené verze nebo balíčku s potvrzenou opravou od dodavatele distribuce. PHP 8.1 a starší už nemají standardní bezpečnostní podporu projektu. Někteří dodavatelé nabízejí vlastní zpětně přenesené opravy; tým PHP mimořádně poskytl také minimální zdrojové opravy pro 7.4, 8.0 a 8.1. To neobnovuje běžnou podporu těchto větví. Organizace potřebuje ověřit konkrétní balíček a jeho původ, nikoli pouze předpokládat, že starší číslo verze znamená neopravený systém nebo naopak dostatečnou ochranu.

Dočasná opatření mají podstatné limity. Pro paměťovou chybu PHP doporučuje při nemožnosti aktualizace administrativně vynutit memory_limit=-1, aby útočník nemohl využít předvídatelné dosažení tohoto limitu. Skutečné selhání alokace však zůstává rizikem. Zrušení limitu navíc vyžaduje kontrolu dostupnosti: smysl mají omezení velikosti a složitosti požadavků na předřazené vrstvě a vhodně nastavené paměťové hranice kontejneru či cgroup. Limity RLIMIT_AS a RLIMIT_DATA nejsou vhodnou náhradou, protože mohou vyvolat právě zranitelnou cestu selhání alokace.

Pro druhou chybu lze omezit potvrzené cesty vypnutím session.upload_progress.enabled a v PHP 8.5 také fatal_error_backtraces. Změny je nutné provést v konfiguraci účinné před zpracováním požadavku a restartovat všechny pracovní procesy. Volání ini_set() uvnitř aplikace přichází pro takovou ochranu pozdě. Pouhé skrytí chyb pomocí display_errors, error_reporting nebo operátoru @ problém neřeší. Ani kombinace těchto zásahů nepokrývá všechny varianty; úplnou nápravou zůstává aktualizace.

WordPress výslovně uvádí, že pro tyto chyby není plánována aktualizace samotného WordPressu. Použitou verzi PHP lze v jeho administraci zjistit přes Tools, Site Health, Info a Server, případně v ovládání hostingu. Prakticky je vhodné vyžádat si od poskytovatele potvrzení, jaký opravený běhový balíček konkrétní web používá. U vlastního provozu doporučujeme po nasazení ověřit také restart procesů a funkčnost aplikací, zejména nahrávání souborů a operací náročných na paměť.

Případ má i organizační rozměr. PHP Foundation přiznala, že první známky paměťového problému byly rozpoznány už v roce 2024, ale bez prokázané cesty ke spuštění kódu se hledání opravy opakovaně zastavovalo na kompatibilitě, technických kompromisech a omezených kapacitách. Konkrétní výzkumná hlášení v srpnu 2026 zásadně změnila hodnocení dopadu. Únik informací před zveřejněním pak vedl k posunu vydání oprav o den dopředu. Nadace mění rozhodovací postupy bezpečnostního týmu; samotné rychlejší nalézání chyb bez lidí schopných připravit a distribuovat opravu nestačí.

Nasazení záplat uzavírá zranitelnost, nevyhodnocuje však minulý provoz. NÚKIB upozorňuje například na neobvyklé procesy spouštěné službami PHP jako na možnou indicii kompromitace. Doporučujeme zachovat dostupné záznamy a případné odchylky prověřit v souvislosti s funkcí aplikace. Samotná preventivní odstávka není důkazem útoku a absence nápadných chyb v logu není potvrzením bezpečnosti.