Kritické zranitelnosti PHP (CVE-2026-109618 a CVE-2026-109619): co se stalo a co dělat

Dne 21. října 2026 vydal projekt PHP opravy dvou kritických zranitelností a CERT-EU téhož dne zveřejnilo bezpečnostní upozornění 2026-018. Obě jsou hodnoceny 9,2 a obě jsou popsány jako vzdálené spuštění kódu bez přihlášení. Pokud provozujete web na WordPressu, e-shop nebo jinou aplikaci v PHP, týká se Vás to a náprava spočívá v aktualizaci, nikoli v nastavení. Tento článek vysvětluje, co je známo, jak se útok dostane dovnitř a co byste měli udělat. Stav k 22. říjnu 2026, podle verze 1.1 upozornění CERT-EU.

Co se stalo

Projekt PHP oznámil 20. října bezpečnostní vydání a opravy zveřejnil 21. října ve 13:30 UTC. CERT-EU nazvalo své upozornění „Critical Vulnerabilities in PHP“ a uvádí dvě CVE: CVE-2026-109618 a CVE-2026-109619, každou s hodnocením 9,2. CERT-EU dále píše, že technické podrobnosti se již veřejně rozebírají a že se začaly šířit první ukázkové programy dokládající zneužitelnost. Upozornění nepotvrzuje útoky v praxi, ale uvádí, že je tím pravděpodobnější, že útočníci chyby již zneužívají. Berte to jako naléhavé.

Koho se to týká

Postižena je každá verze PHP starší než opravená v podporované větvi a každá větev, jejíž podpora skončila.

CERT-EU jmenuje PHP-FPM, Apache s mod_php, php-cgi, FrankenPHP a LiteSpeed. Podle týmu PHP nese nejvyšší riziko mod_php. Postiženy mohou být i produkty, které PHP obsahují; CERT-EU odkazuje na seznam nizozemského NCSC na konci tohoto článku. Počítá se každá instalace, která obsluhuje webové požadavky, ať už má formulář pro nahrávání souborů, nebo ne.

Jak se útočník dostane k první chybě

Nikdo se nemusí přihlásit. Podle CERT-EU předvedený útok ukazuje, že k jeho spuštění stačí jediný požadavek bez přihlášení, a to dříve, než se spustí jakýkoli kód aplikace. To většina lidí přehlédne: nezáleží na tom, zda je Váš WordPress aktuální, zda jsou Vaše zásuvné moduly opravené nebo zda je Váš kontaktní formulář chráněn. Požadavek dorazí nejdřív k jádru PHP.

První chyba, CVE-2026-109618, funguje takto:

1. Požadavek dorazí na adresu, kterou PHP obsluhuje. Žádné přihlášení, žádný účet.
2. PHP začne číst tělo požadavku. CERT-EU jako příklad uvádí zpracování nahrávání souborů z formulářů.
3. PHP prosazuje svůj memory_limit pomocí longjmp(). Při překročení limitu vyskočí z toho, co právě dělalo, a požadavek ukončí.
4. Stane-li se to uprostřed sestavování vnitřních dat požadavku, jsou tato data sestavena jen napůl.
5. Následný úklid zachází s neplatnými daty jako s platnými a uvolní paměť, která nebyla nikdy inicializována. Tato paměť může stále obsahovat data z dřívějších přidělení, která útočník ovládal.
6. Odtud upozornění popisuje spuštění kódu na serveru.

Jak útočník řídí poslední krok, záměrně nepopisujeme. Stačí vědět, že vstupním bodem není Vaše aplikace, a proto jej nic uvnitř Vaší aplikace nemůže zastavit.

Druhá chyba: stav, který přežije svou paměť

CVE-2026-109619 je jiný mechanismus se stejným výsledkem. PHP drží pro každý požadavek vnitřní stav. Po určitých selháních, například po závažné chybě, může tento stav zůstat, i když byla paměť pod ním uvolněna. Další požadavek, který zpracuje stejný pracovní proces, může tento zastaralý stav použít dřív, než je běžným způsobem vynulován. Útočník potřebuje dva požadavky, které skončí u téhož pracovního procesu; CERT-EU hodnotí výsledek stejně jako u první chyby: vzdálené spuštění kódu.

Co dělat ještě dnes

1. Zjistěte, jaká verze PHP Váš web skutečně obsluhuje. php -v v příkazovém řádku ukazuje verzi příkazového řádku, která se může lišit od verze Vašeho webového serveru. Zkontrolujte php-fpm -v, administrační panel hostingu nebo stránku, která volá phpinfo(). U sdíleného hostingu se zeptejte poskytovatele.
2. Aktualizujte na opravenou verzi: 8.5.12, 8.4.27, 8.3.36 nebo 8.2.35. Distribuce často přebírají opravy zpětně, aniž by změnily číslo verze; hledejte proto čísla CVE v bezpečnostním oznámení svého dodavatele. V kontejnerech sestavte znovu z aktualizovaného základního obrazu. Tým PHP upozorňuje, že rpms.remirepo.net v den vydání ještě nemělo žádné aktualizace, a doporučuje balíčky distribuce nebo sestavení ze zdrojových kódů.
3. Restartujte každý pracovní proces PHP. Aktualizace na disku nezmění procesy, které již běží. Restartujte PHP-FPM nebo webový server a poté znovu zkontrolujte běžící verzi.
4. Pokud dnes nemůžete aktualizovat, odpojte server od veřejných sítí, dokud oprava není nasazena a ověřena. CERT-EU jasně říká, že tyto chyby plně odstraní jen aktualizace.
5. Pokud používáte PHP 8.1 nebo starší, požádejte dodavatele o zpětně portovanou opravu nebo přejděte na podporovanou větev. Tyto verze nedostávají pravidelné aktualizace.

Opatření, která riziko snižují, ale chybu neodstraňují

CERT-EU uvádí opatření, která útok ztěžují. Výslovně říká, že instalaci bezpečnou neudělají. Používejte je během přípravy aktualizace, nikoli místo ní.

• Proti CVE-2026-109618: Nastavte memory_limit=-1 tak, aby jej aplikace nemohly přepsat, například pomocí php_admin_value v poolu FPM, a ověřte, že žádný záznam poolu, adresáře ani aplikace opět nenastavuje konečný limit. Nastavte nízkou hodnotu post_max_size (8M bez nahrávání souborů, 32M s ním) a držte upload_max_filesize pod ní. Omezte velikost požadavku, počet polí, části multipart, počet hlaviček a hloubku vnoření na webovém serveru nebo proxy serveru. Použijte limit paměti kontejneru nebo cgroup jako hranici dostupnosti, ale ne RLIMIT_AS ani RLIMIT_DATA, které mohou vyvolat zranitelné selhání přidělení paměti.
• Proti CVE-2026-109619: Nastavte session.upload_progress.enabled=0 v php.ini, v poolu FPM nebo v konfiguraci serveru, která se uplatní před zpracováním požadavku (ne pomocí ini_set() ani .user.ini), a restartujte všechny pracovní procesy. U PHP 8.5 nastavte navíc fatal_error_backtraces=0. Odstraňte neplatná nebo zastaralá nastavení pro jednotlivé požadavky, která vypisují diagnostická hlášení před inicializací, a opravte závažné chyby a překročení časového limitu běhu, které může útočník vyvolat.

Co SilentShield zde dokáže a co ne

Toto není problém botů a raději to říkáme otevřeně, než abychom dovolili produktové stránce naznačit opak. Útok zasáhne jádro PHP dřív, než požadavek uvidí cokoli od nás nebo jakýkoli CAPTCHA, zásuvný modul či pravidlo firewallu uvnitř Vaší aplikace. Ochrana před boty u formuláře jej nezastaví a nikdo by Vám neměl tvrdit, že ano. Jediná úplná náprava je aktualizace PHP.

API a přehledový panel SilentShield nejsou napsány v PHP. Zásuvný modul pro WordPress a PHP SDK běží ve Vašem vlastním PHP, takže u nich musí aktualizace proběhnout na Vašem serveru. Po aktualizaci je obvyklá ochrana před boty a spamem z formulářů stejně užitečná jako dříve; jen nikdy nebyla odpovědí na tento problém.

Zdroje

• CERT-EU Security Advisory 2026-018: Critical Vulnerabilities in PHP
• Oznámení projektu PHP z 20. října 2026
• GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• NCSC-NL php2shell: produkty, které obsahují PHP