Stručně: Kdo chce mít zranitelnost PHP2Shell v PHP uzavřenou ještě dnes, potřebuje čtyři věci: správnou aktualizaci, restart všech procesů PHP, kontrolu na již vložený škodlivý kód a doklad. Týká se to vás? Zavolejte nám. Pomůžeme. Převezmeme to na dálku, od první zprávy.
Nyní nic nemažte a nic znovu nenasazujte. I při záplatování platí: nejdřív zajistit, pak měnit. Pokud už něco pronikla dovnitř, potřebujeme stav souborů a logů. Nahlásit nouzi, společně ujasníme pořadí kroků.
Proč zranitelnost nepočká
Obě zranitelnosti CVE-2026-109618 a CVE-2026-109619 jsou přímo v PHP a umožňují spustit škodlivý kód na dálku bez přihlášení. Německé BSI vyhlásilo výstražný stupeň 3 (oranžový) a doporučuje okamžitou aktualizaci. Pokud to ihned nejde, mají se webové servery dočasně odpojit od sítě. Podle zpráv médií byly první pokusy o útok pozorovány už před zveřejněním záplat 21. 10. 2026. Cloudflare pozoroval pokusy a nasadil ochranná pravidla, varuje však, že pravidla jen podle dat požadavku nestačí.
Důležité pro provozovatele: aktualizace CMS zranitelnost PHP neuzavře. Ani WordPress.org podle zpráv žádnou aktualizaci proti ní nepřipravuje, protože zranitelnost je v interpretu. Uzavře se jen na úrovni PHP, tedy v tom, co váš server skutečně spouští.
Co udělat hned
- Znát cílovou verzi. Opraveno je v PHP 8.5.12, 8.4.27, 8.3.36 a 8.2.35. PHP 8.2 dosáhne konce podpory 31. 12. 2026, počítejte s tím.
- Zachytit všechny systémy. I testovací servery, obrazy kontejnerů a staré systémy dostupné z internetu.
- Ujasnit odpovědnost. U hostingových balíčků a spravovaných serverů aktualizaci nasazuje poskytovatel. Zeptejte se písemně na verzi a restart.
- Uchovat logy. Od 20. 10. 2026, podle odborného tisku.
- Domluvit okno. Restart krátce přeruší probíhající požadavky. Stanovte čas, kdy je k dispozici někdo, kdo může rozhodovat.
- Nečekat, pokud je systém otevřený. Pokud nelze záplatovat ihned, ověřte s námi odstínění nebo přechodná opatření.
Jak PHP SOS konkrétně pomáhá?
- Zmapování situace: Zjistíme systémy, verze PHP, provozní režimy, hosting a dostupnost a stanovíme pořadí: nejdřív nejvíce exponované systémy.
- Zajištění a uzavření: Zajistíme aktuální stav, nasadíme aktualizaci nebo dostaneme hosting na prokazatelně záplatovaný stav a restartujeme všechny procesy. U kontejnerů image znovu sestavíme a nasadíme.
- Kontrola a vyčištění: Protože záplata škodlivý kód neodstraní, hledáme známky dřívějšího průniku a v případě potřeby vyčistíme.
- Hardening a zpráva: Dostanete písemný doklad pro každý systém a doporučení, aby další aktualizace proběhla rychleji. Rozsah služby popisuje služba záplatování PHP.
Aktualizace, restart, doklad: na čem záleží
Nejčastější chybou je aktualizace bez restartu. Dokud v paměti běží staré procesy, zůstává zranitelný kód aktivní, i když jsou soubory nové. Návod najdete na stránce Restart PHP-FPM a všech workerů. Druhou chybou je věřit zobrazené hodnotě: distribuce a hostingové firmy často dodávají backporty, a pak číslo verze zůstane stejné. Spolehlivý je changelog balíčku s čísly CVE, u rodiny Debianu příkazem apt-get changelog <paket>.
Navíc podle příručky PHP platí od bezpečnostních vydání nová direktiva memory_hard_limit_percent. Pokud ji verze PHP nezná, je zranitelná. Test je krátký:
php -r 'var_dump(ini_get("memory_hard_limit_percent"));'
Musí se spustit pro každou verzi a provozní režim, protože příkazová řádka může používat jinou verzi PHP než webový server. Na závěr výsledek zaznamenáme, abyste ho mohli ukázat svému hostingu, pojišťovně nebo zadavateli.
Když aktualizace nejde ihned
Existují důvody, proč dnes aktualizace není možná: stará aplikace, která na novějších verzích PHP neběží, hosting bez schválení, obraz kontejneru v pevné pipeline. Pro tyto případy uvádí php.net přechodná opatření, která výslovně nejsou úplnou ochranou: nastavit memory_limit=-1 tak, aby ho aplikace nemohly přepsat, omezit post_max_size, session.upload_progress.enabled=0 a na PHP 8.5 fatal_error_backtraces=0, vždy s restartem. K tomu přistupují ochranná pravidla na okraji, která aktualizaci nenahrazují. Kolující tip blokovat všechny požadavky s PHPSESSID odborní autoři výslovně odmítají.
Která opatření se k vašemu systému hodí a co mohou rozbít, probereme předem. Více na stránce Okamžitá opatření, když zatím nemůžete záplatovat a v tématu WAF a virtuální záplatování. Pro PHP 8.1 a starší platí zvláštní situace, kterou popisuje stránka PHP 8.1 a starší: co nyní platí.
Co nám poslat
- Seznam serverů a hostingů, pokud existuje
- Výstup příkazu
php -vpro každý systém a informaci o provozním režimu - Informaci, zda se používají kontejnery, Plesk, cPanel nebo spravovaná nabídka
- Požadované časové okno a kontaktní osobu pro restarty
- Informace o nápadnostech od 17. 10. 2026
Proč PHP SOS
Pracujeme v duchu „Made in Germany“ a spolu s naší partnerskou sítí odborníků na kybernetickou bezpečnost se již více než 25 let specializujeme na IT bezpečnost. Máte jeden kontaktní bod, který aktualizaci provází, ověří restart a dodá doklad. Pracujeme na dálku, bez cestování, a dokumentujeme každý krok. Neslibujeme zázraky: záplata zranitelnost uzavře, ale neprokazuje, že se předtím nic nestalo, a to vám také tak řekneme.
Týká se to vás? Zavolejte nám. Pomůžeme.
Nenechávejte zranitelnost otevřenou déle. Zavolejte nebo napište přes WhatsApp. Přebíráme situaci od první zprávy a zůstáváme u ní, dokud není incident uzavřen a zdokumentován. Nahlásit nouzi hned.
Časté dotazy
Mohu bezpečnostní zranitelnost PHP uzavřít sám, nebo potřebuji pomoc?
Aktualizace je pro administrátory proveditelná, ale náchylná k chybám: musí se týkat verze, která skutečně obsluhuje požadavky, a všechny procesy se musí restartovat. Kdo má více serverů, obrazy kontejnerů nebo hosting s vlastními zvláštnostmi, ušetří s podporou čas i chyby.
Musí se PHP po aktualizaci restartovat?
Ano. Nové soubory samy nestačí, dokud v paměti běží staré procesy PHP. Je nutné restartovat všechny workery, resp. procesy, u mod_php webový server.
Co dělat, když pro mou verzi PHP zatím aktualizace neexistuje?
Pro PHP 8.1 a starší už projekt PHP oficiální aktualizace nevydává. Pak je nutný prokazatelně záplatovaný backport od poskytovatele, migrace na udržovanou verzi, nebo přechodná opatření, která ale nenabízejí úplnou ochranu.
Stačí nastavit session.upload_progress.enabled na 0?
Ne. Podle odborných zpráv samotné nastavení neuzavře obě zranitelnosti, aktualizace PHP zůstává povinná. Nastavujte ho pouze v php.ini, v poolu FPM nebo v konfiguraci serveru, nikoli přes ini_set() nebo .user.ini.
Jak poznám, že je zranitelnost poté skutečně uzavřena?
Dokladem na běžícím systému: verze nebo changelog balíčku, test na novou direktivu memory_hard_limit_percent a potvrzení, že se po aktualizaci restartovaly všechny procesy.