Kritická zranitelnost „php2shell“: nasazujeme aktualizace PHP

Projekt PHP vydal ve středu 21. října 2026 ve 14:00 UTC bezpečnostní verze, které opravují dvě kritické zranitelnosti umožňující vzdálené spuštění kódu: CVE-2026-109618 a CVE-2026-109619, obě hodnocené 9,2 z 10 (CVSS v4.0). Výzkumníci ze společnosti watchTowr tuto dvojici pojmenovali „php2shell“.

Naše týmy právě nasazují opravené verze na servery, které spravujeme. Tento článek vysvětluje, o jaké zranitelnosti jde, proč se berou tak vážně a co děláme my.

Dvě zranitelnosti v samotném jádru PHP

Zranitelnosti se netýkají WordPressu, PrestaShopu ani žádného konkrétního rozšíření: jsou přímo v jádru PHP, ve způsobu, jakým připravuje a poté uklízí každý požadavek. Lze je proto zneužít bez ohledu na web nebo nainstalovaný CMS.

CVE-2026-109618: poškození paměti po jejím vyčerpání

Když požadavek překročí povolenou paměť, PHP ho přeruší. Pokud k přerušení dojde v nevhodnou chvíli, jsou některá interní data požadavku inicializovaná jen napůl. Úklid na konci požadavku je přesto považuje za platná, což poškodí paměť a může vést ke spuštění kódu, který zvolí útočník.

Podle bezpečnostního upozornění projektu PHP je riziko nejvyšší u mod_php (PHP načtené přímo v Apache): předvedený exploit umožňuje neověřenému požadavku spustit útok ještě předtím, než se vůbec spustí kód webu.

CVE-2026-109619: opětovné použití zastaralého globálního stavu

Druhá zranitelnost se týká interního stavu každého požadavku, který může přežít uvolnění paměti, v níž byl uložen. Další požadavek zpracovaný stejným procesem PHP (například „workerem“ PHP-FPM) pak může tento zastaralý stav použít dřív, než se vynuluje. Dočasná opatření zveřejněná projektem PHP ukazují, že souvisí se sledováním průběhu nahrávání souborů (session.upload_progress) a v PHP 8.5 s výpisy zásobníku při fatálních chybách.

Proč je to vážné

• Není potřeba žádné ověření: stačí jediný požadavek HTTP na web v PHP, bez účtu a bez konkrétního formuláře.
• Týká se to všech webů v PHP: WordPress, PrestaShop, Joomla, Drupal, Laravel, Magento… Odhady se pohybují od 1,3 do více než 1,9 milionu serverů dostupných z internetu.
• Podrobnosti unikly ještě před vydáním, a proto projekt PHP oznámil opravu už den předem. Exploitační kód už koluje, neověřený (a někdy i zamořený: nespouštějte ho).
• Cloudflare zmiňuje první útoky, které ale zatím nepotvrdil CERT-FR ani katalog zneužívaných zranitelností agentury CISA.
• Precedens mluví za vše: v roce 2024 byla zranitelnost CVE-2024-4577 zneužita méně než 24 hodin po zveřejnění.

Dotčené a opravené verze

CERT-EU se domnívá, že by mohly být dotčeny všechny verze od PHP 5. Někteří dodavatelé nabízejí zpětně portované opravy pro starší větve, jediným trvalým řešením však zůstává přechod na udržovanou verzi.

Co děláme v HaiSoft

Oznámení jsme sledovali už od předchozího dne a byli jsme připraveni: aktualizace se právě nasazují na naše servery.

• Sdílený hosting: opravené verze se instalují pro všechny nabízené verze PHP. Nemusíte nic dělat, pro vaše weby je celá operace transparentní.
• Spravované dedikované a virtuální servery: PHP aktualizujeme na každém serveru, tento zásah je součástí vaší smlouvy o správě. Opravené balíčky z repozitáře sury.org jsou už k dispozici a instalují se.
• Servery s Pleskem nebo s oficiálními balíčky Debianu: Plesk ani Debian zatím své opravené balíčky nevydaly. Sledujeme jejich vydání a aktualizace nasadíme, jakmile budou k dispozici.
• Weby, které stále běží na PHP 8.1 nebo starším: tyto verze opravu nedostanou. Dotčené zákazníky budeme kontaktovat, abychom naplánovali migraci na udržovanou verzi.

Spravujete si server sami?

1. Zjistěte, jaké verze PHP máte nainstalované: php -v, balíčky php8.* v Debianu nebo plesk bin php_handler --list v Plesku.
2. Aktualizujte na 8.5.12, 8.4.27, 8.3.36 nebo 8.2.35 (nebo na opravený balíček vaší distribuce) a restartujte všechny služby PHP-FPM, při použití mod_php i Apache.
3. Pokud aktualizace musí počkat, použijte dočasná opatření projektu PHP, která riziko snižují, ale neodstraňují.
4. Izolujte aplikace na neudržovaných verzích (VPN, filtrování, odpojení), jak doporučuje CERT-EU, dokud je nezmigrujete.
5. Sledujte každý shell, curl nebo wget spuštěný procesem php-fpm, apache2 nebo httpd: je to typický znak úspěšného útoku.

Dočasná opatření doporučená projektem PHP patří do php.ini nebo do konfigurace poolu PHP-FPM (ne do souboru .user.ini ani přes ini_set()), po nichž je nutné restartovat všechny workery:

; CVE-2026-109619
session.upload_progress.enabled = 0
; pouze PHP 8.5
fatal_error_backtraces = 0
; CVE-2026-109618: omezit velikost požadavků
; (8M bez nahrávání souborů, 32M s nahráváním)
post_max_size = 8M

Pro CVE-2026-109618 projekt PHP navíc doporučuje nastavit memory_limit = -1 tak, aby ho aplikace nemohla změnit, a omezit velikost požadavků na úrovni webového serveru nebo proxy. Toto nastavení ruší jakýkoli limit paměti na skript: použijte ho jen tehdy, když je okamžitá aktualizace opravdu nemožná.