Kritické zranitelnosti PHP CVE-2026-109618 a CVE-2026-109619: jak jsme ochránili weby ještě před opravou

Tvůrci PHP oznámili 20. října 2026 mimořádnou bezpečnostní aktualizaci, která opravuje dvě kritické zranitelnosti – CVE-2026-109618 a CVE-2026-109619. Obě umožňují útočníkovi spustit na serveru vlastní kód a týkají se prakticky každého webu postaveného na PHP, tedy i každého WordPressu. Oprava vyšla až o den později, podrobnosti o chybách ale unikly na veřejnost ještě před jejím vydáním. Servery v naší péči jsme proto zabezpečili náhradními opatřeními ještě týž den, opravu jsme nasadili na všechny klientské weby večer v den jejího vydání a následně jsme všechny servery prověřili. Žádný klientský web nebyl mimo provoz a nenašli jsme žádné známky napadení.

Když se mluví o bezpečnosti WordPressu, většina lidí si představí aktualizace pluginů a šablon. To je důležitá část péče o web, ale zdaleka ne jediná. WordPress běží na programovacím jazyce PHP a ten zase na serveru. Když se chyba objeví o patro níž, v samotném PHP, žádná aktualizace pluginu ji nevyřeší. Právě taková situace nastala tento týden.

Hned na úvod to podstatné: pokud je váš web v péči wpsprava.online, nemusíte nic dělat. Všechno jsme vyřešili za vás. V tomto článku chceme otevřeně ukázat, jak takový zásah probíhá.

Co se stalo

Tým PHP oznámil 20. října 2026, že na následující den, 21. října ve 13:40 UTC (v 15:40 našeho času), chystá bezpečnostní vydání pro všechny podporované řady:

• 8.5.12 pro řadu 8.5,
• 8.4.27 pro řadu 8.4,
• 8.3.36 pro řadu 8.3,
• 8.2.35 pro řadu 8.2.

Pro PHP 8.1 a starší už oficiální opravené balíčky nevycházejí. Vydání opravuje dvě zranitelnosti, které obě vedou ke vzdálenému spuštění kódu (RCE). To je nejhorší možný scénář: útočník by mohl na serveru spouštět vlastní příkazy a převzít nad webem kontrolu.

Situaci zkomplikovalo, že podrobnosti o chybách unikly na veřejnost ještě před vydáním opravy, a to už 20. října od 15:20 UTC (17:20 našeho času). Útočníci tak mohli o chybách vědět dřív, než existovala oprava. V takové chvíli rozhodují hodiny.

Proč to bylo nebezpečné

Obě chyby mají skóre 9,2 z 10 podle standardu CVSS 4.0, tedy mezinárodní stupnice pro hodnocení závažnosti zranitelností. Jde o kritickou závažnost. Týkají se všech způsobů, jakými PHP na webových serverech běží, takže se jim nevyhne žádný typ hostingu.

Představte si to jako vadný zámek, který se nemontuje do jednoho konkrétního domu, ale do většiny domů ve městě. Nezáleží na tom, jak pěkné máte dveře (tedy jak dobře je postavený samotný web) – slabé místo je v něčem, co mají všichni společné.

Technický pohled

• CVE-2026-109618 – poškození paměti ve chvíli, kdy PHP dojde vyhrazená paměť (takzvaný stav OOM, out of memory). Útočník, který dokáže PHP do tohoto stavu dostat, může chybu zneužít ke spuštění vlastního kódu.
• CVE-2026-109619 – chyba v práci se zastaralým globálním stavem ve funkci, která sleduje průběh nahrávání souborů (session.upload_progress). I ta vede ke spuštění kódu.

Zranitelné jsou všechna webová rozhraní PHP, tedy PHP-FPM i modul Apache (mod_php). Úplnou ochranu přináší jen aktualizace. Bezpečnostní upozornění ale zároveň popsalo dočasná opatření, která riziko do vydání opravy výrazně snižují.

Ochrana ještě před vydáním opravy

Na opravu jsme nečekali se založenýma rukama. Hned 20. října jsme začali dvěma kroky.

Soupis všech serverů s PHP

Nejdřív jsme shromáždili všechny veřejně dostupné informace a sepsali každý server, na kterém běží PHP – na naší nové hostingové platformě (Debian, PHP 8.5) i na starší platformě (Ubuntu, PHP 8.3), a to testovací i produkční.

Každý krok jsme od začátku zaznamenávali, takže máme přesný přehled, co se kdy kde stalo.

Dočasná opatření na všech serverech

Ještě týž den, tedy dřív, než oprava vůbec existovala, jsme na všech serverech s PHP nasadili dočasná opatření, která útočníkům cestu výrazně ztěžují:

• Vypnuli jsme sledování průběhu nahrávání (session.upload_progress). Tím jsme uzavřeli cestu ke zneužití chyby CVE-2026-109619. Weby tuto funkci běžně nevyužívají, takže to návštěvníci nijak nepoznali.
• Na serverech s PHP 8.5 jsme navíc vypnuli volbu fatal_error_backtraces.
• Na serverech s webovým serverem Apache jsme nastavili limity paměti, které hlídá přímo operační systém, a ne samotné PHP. Tím jsme omezili cestu, kterou využívá chyba CVE-2026-109618 při vyčerpání paměti.
• Odstranili jsme zastaralá nastavení PHP, která při startu PHP spouštěla zranitelnou část kódu.

I samotné nasazení jsme dělali opatrně. Změny jsme zaváděli postupně a po každém kroku jsme web po webu ověřili, že vše funguje tak, jak má.

Den vydání: aktualizace krok za krokem

Ve středu 21. října jsme průběžně kontrolovali web php.net i oficiální zdroje balíčků, ze kterých servery software instalují. Opravené PHP totiž nevychází všude ve stejnou chvíli – nejdřív ho vydají tvůrci PHP a teprve potom ho správci jednotlivých linuxových distribucí připraví pro své systémy.

1. Nová platforma jako první: balíčky pro Debian byly k dispozici nejdřív. Všechny servery nové platformy jsme během krátké doby aktualizovali na PHP 8.5.12.
2. Starší platforma o něco později: balíčky pro Ubuntu vyšly až s odstupem několika hodin. Jejich server byl navíc pod náporem přetížený a část požadavků odmítal. Postup aktualizace jsme proto upravili: každý server si nejdřív stáhl všechny potřebné balíčky (v případě neúspěchu opakovaně) a teprve potom začala samotná instalace. Žádný server tak nikdy nezůstal napůl aktualizovaný. Webový server jsme restartovali vždy až po dokončení celé instalace, jedním čistým restartem.
3. Postupné nasazení: nejdřív jeden testovací server, potom všechny testovací (staging) servery a teprve nakonec produkční servery, na kterých běží ostré weby, a to po menších skupinách. Automatizace se zastaví při první chybě, takže případný problém by se nikdy nerozšířil na další weby.
4. Ověření každého serveru: po aktualizaci jsme u každého serveru zkontrolovali, že běží správná verze PHP, že PHP funguje, že se načítají všechna rozšíření, že je k dispozici ovladač databáze a že weby odpovídají.

Večer 21. října byly opravené všechny servery s PHP v naší péči – servery nové platformy na PHP 8.5.12, servery starší platformy na PHP 8.3.36.

Kontrola po zásahu

Aktualizace zavře dveře, ale neřekne, jestli jimi předtím někdo neprošel. Protože podrobnosti o chybách unikly ještě před vydáním opravy, prověřili jsme všechny servery s PHP zpětně, od okamžiku úniku informací. Hledali jsme:

• pády PHP a nárazové vyčerpání paměti, které by mohly signalizovat pokus o zneužití,
• neznámé soubory PHP ve složkách pro nahrané obrázky a dokumenty,
• nové naplánované úlohy, přístupové klíče nebo jiné způsoby, jak by si útočník mohl na serveru zajistit trvalý přístup,
• programy spuštěné přímo z PHP, které tam nemají co dělat.

Výsledek: žádné známky napadení. V záznamech serverů jsme našli jen běžné automatické skenování od robotů, kteří zkoušejí otevírat neexistující soubory. Nic z toho nebylo úspěšné.

Dočasná opatření z prvního dne jsme záměrně ponechali zapnutá. Oprava je sice nasazená, ale další vrstva ochrany navíc nikdy neuškodí.

Co to znamená pro naše klienty

Jako klient wpsprava.online jste nemuseli udělat vůbec nic – a o celé akci jste se možná dozvěděli až z tohoto článku. To je přesně smysl správy webu. Celý zásah ve zkratce:

• Ochrana ještě před opravou: dočasná opatření byla na serverech během několika hodin od oznámení, tedy dřív, než oprava vůbec existovala.
• Hlídání vydání: na opravu jsme nečekali do příštího plánovaného termínu, ale sledovali jsme ji v reálném čase.
• Postupné a bezpečné nasazení: nejdřív testovací servery, potom ostré weby po malých skupinách.
• Ověření a kontrola: každý server jsme po aktualizaci prověřili a zpětně jsme hledali případné stopy útoku.
• Výsledek: oprava na všech klientských webech ještě večer v den vydání, nula webů mimo provoz, nula známek napadení.

Pokud váš web nespravujeme

Zeptejte se svého poskytovatele hostingu, zda už váš web běží na opravené verzi PHP (8.5.12, 8.4.27, 8.3.36 nebo 8.2.35). Pokud váš web běží na PHP 8.1 nebo starším, oficiální oprava pro něj nevyšla a je nejvyšší čas naplánovat přechod na novější verzi.

Nechcete podobné zprávy sledovat sami? Přenechte to nám. O bezpečnostní aktualizace, zálohy i dohled nad servery se v rámci wpsprava.online staráme za vás. Přehled služeb a tarifů najdete v ceníku nebo nás rovnou kontaktujte – rádi váš web zkontrolujeme a převezmeme do správy.

Často kladené otázky

Musím jako klient wpsprava.online něco dělat?

Ne. Dočasná opatření jsme nasadili ještě před vydáním opravy, samotnou opravu PHP jsme na všech klientských webech nasadili večer v den jejího vydání a následně jsme všechny servery prověřili. Nenašli jsme žádné známky napadení a žádný další krok z vaší strany není potřeba.

Byl můj web během aktualizace nedostupný?

Ne. Aktualizaci jsme nasazovali postupně a každý server hned ověřili. Žádný klientský web nebyl mimo provoz.

Co je PHP a proč se mě to týká?

PHP je programovací jazyk, ve kterém je napsaný WordPress. Server ho potřebuje ke každému zobrazení stránky vašeho webu. Chyba v PHP se proto týká každého WordPressu bez ohledu na to, jaké používá pluginy nebo šablonu.

Co znamenají zkratky RCE a OOM?

RCE (Remote Code Execution) znamená vzdálené spuštění kódu – útočník může na serveru spouštět vlastní příkazy. Jde o jeden z nejzávažnějších typů zranitelností. OOM (Out of Memory) označuje stav, kdy programu dojde vyhrazená paměť.