Aktuální situace: PHP2Shell. Dvě kritické zranitelnosti PHP (CVSS 9.2) umožňují spustit škodlivý kód bez přihlášení. Záplaty od 21. 10. 2026.Co nyní udělat →

Okamžitá pomoc při PHP2Shell: pomoc při zranitelnosti PHP

PHP2Shell uzavíráme na vašich webových serverech na dálku: inventura, záplata nebo přechodné opatření, restart všech workerů a písemný doklad.

Stav 4 min čteníSlužby

Stručně: PHP2Shell jsou dvě kritické zranitelnosti přímo v PHP, přes které mohou útočníci bez přihlášení spustit škodlivý kód. Pokud potřebujete rychle pomoc s touto zranitelností PHP, převezmeme na dálku inventuru, záplatování nebo přechodné opatření, restart všech procesů PHP a první hledání stop. Na konci obdržíte písemný doklad o stavu.

Pomoc při zranitelnosti PHP: proč je nutné jednat hned

Dne 21. 10. 2026 v 16 hodin německého času vydal projekt PHP záplaty pro CVE-2026-109618 a CVE-2026-109619. Obě zranitelnosti jsou hodnoceny CVSS v4.0 9.2 a umožňují spuštění škodlivého kódu na dálku, aniž by se kdokoli musel přihlásit. Postiženy jsou obvyklé provozní režimy: PHP-FPM, Apache s mod_php, php-cgi, FrankenPHP a LiteSpeed.

BSI (německý Spolkový úřad pro informační bezpečnost) vyhlásil výstražný stupeň 3 (oranžový). Doporučuje okamžitou aktualizaci, a pokud ta není možná, webové servery dočasně odpojit od sítě. Palo Alto Networks (Unit 42) napočítalo více než 22,6 milionu exponovaných, potenciálně zranitelných instancí. Potvrzené úspěšné útoky v širokém měřítku nebyly podle BSI zpočátku známy, Cloudflare však již hlásil pokusy o útok.

Pro vedení firem a majitele to znamená: každý veřejně dostupný server s PHP je kandidátem, dokud se neprokáže opak. Srozumitelné vysvětlení zranitelnosti najdete na stránce Co je PHP2Shell?.

Pro koho je okamžitá pomoc při PHP2Shell určena?

Pro firmy, agentury a veřejné instituce, které provozují aplikace v PHP a nemohou nebo nechtějí situaci zvládnout sami v potřebné hloubce. Týká se to vlastních root serverů a vServerů stejně jako serverů s Pleskem nebo cPanelem, prostředí s kontejnery a spravovaných serverů, kde je odpovědnost nejasná.

I kdo má poskytovatele hostingu, často potřebuje podporu. Mnoho poskytovatelů nasazuje backporty; Plesk pak dál zobrazuje například 8.2.34, přestože je balíček záplatovaný. Naopak se může zobrazit nové číslo verze, zatímco staré procesy PHP stále běží v paměti. Které verze se považují za opravené, najdete na stránce Které verze PHP jsou postižené?.

Jak konkrétně pomáhá PHP SOS?

  1. Inventura: Zjistíme všechny instalace PHP, provozní režimy a verze na vašich serverech, včetně stavu balíčků a běžících procesů. Výsledkem je seznam, které systémy jsou postižené, opravené nebo nejasné.
  2. Záplata nebo přechodné opatření: Kde je to možné, nasadíme opravené verze (8.5.12, 8.4.27, 8.3.36, 8.2.35) nebo balíčky vaší distribuce. Pokud to hned nejde, uplatníme přechodná opatření podle php.net a otevřeně řekneme, že neposkytují úplnou ochranu.
  3. Restart a kontrola: Restartujeme všechny workery a procesy PHP a poté ověříme, že neběží žádný starý proces. Samotné nové soubory zranitelnost neuzavřou.
  4. První hledání stop: Zajistíme logy serveru od 20. 10. a hledáme nesrovnalosti, jako jsou nové soubory PHP, neznámé cron úlohy nebo neobvyklé procesy. Protože neexistují zveřejněné potvrzené indikátory kompromitace (IOC), opírá se tato kontrola o analýzu chování.
  5. Doklad a další kroky: Obdržíte písemnou zprávu. Při podezření na kompromitaci doporučíme vhodné navazující kroky, například odstranění malwaru nebo forenzní šetření.
Důležité

Záplata neodstraní již vložený škodlivý software a nedokazuje, že se předtím nic nestalo. Proto k okamžité pomoci vždy patří pohled na období od 17. 10. 2026.

Co od nás získáte

  • přehled všech zkontrolovaných serverů s verzí PHP, stavem balíčku, provozním režimem a stavem záplaty
  • dokumentaci nasazených aktualizací nebo nastavených přechodných opatření
  • doklad, že všechny procesy PHP byly restartovány
  • zhodnocení hledání stop, rozdělené na doložené, pravděpodobné a neznámé
  • seznam otevřených bodů, například systémy s PHP 8.1 nebo starším

Tuto zprávu můžete předat vedení, pověřenci pro ochranu osobních údajů nebo pojišťovně. Právní posouzení nenahrazuje.

Co potřebujeme od vás

  • Přístup: přístup přes SSH nebo panel s dostatečnými oprávněními, případně svolení, aby nám váš poskytovatel hostingu mohl podat informace
  • Kontaktní osoba: osoba, která smí rozhodovat, například o krátkém provozu offline nebo o restartu
  • Přehled: které weby, e-shopy a aplikace běží na kterých serverech
  • Servisní okno: vaše požadavky, kdy smějí restarty proběhnout
  • Zálohy: informace, kde jsou uloženy aktuální zálohy

Pro administrátory, kteří si chtějí stav předem ověřit sami, často stačí tento neškodný pohled na stav:

php -v
# Debian/Ubuntu: nainstalované balíčky PHP s verzí
dpkg -l | grep -i php
# běžící procesy PHP a doba jejich spuštění
ps -eo pid,lstart,cmd | grep -i php

Co neslibujeme

Neslibujeme absolutní bezpečnost ani tvrzení, že váš server nebyl nikdy napaden, pokud to důkazy nepotvrzují. Na incidentu pracujeme tak dlouho, dokud není uzavřen a zdokumentován. Zda existuje oznamovací povinnost podle GDPR nebo zda je třeba informovat pojišťovnu, ujasněte prosím s pověřencem pro ochranu osobních údajů, právníkem nebo pojišťovnou. Technická fakta k tomu dodáme my.

Pokud potřebujete jen aktualizaci s dokladem, hodí se naše služba záplatování PHP. Pokud už existují známky útoku, je správným začátkem nouzová pomoc při napadeném webu.

Časté dotazy

Stačí, když můj poskytovatel hostingu PHP aktualizoval?

Může to stačit, pokud poskytovatel hostingu písemně potvrdí stav balíčku a všechny procesy PHP byly restartovány. Zobrazené číslo verze samo o sobě není důkaz, protože distribuce nasazují backporty. Zda byl server napaden již dříve, záplata každopádně nevysvětlí.

Musí být můj web kvůli okamžité pomoci offline?

Ne nutně. Německý BSI doporučuje webové servery dočasně odpojit od sítě, pokud aktualizace není okamžitě možná. Zda je to ve vašem případě nutné, rozhodneme společně po inventuře.

Chrání aktualizace WordPressu nebo Shopwaru před PHP2Shell?

Ne. PHP2Shell je přímo v PHP, ne v CMS. Aktualizace CMS zůstává užitečná, tuto zranitelnost ale neuzavře.

Co dělat u PHP 8.1 nebo starší?

Pro tyto verze už projekt PHP nevydává oficiální aktualizace, existují jen minimální zdrojové backporty pro 7.4, 8.0 a 8.1. Server přechodně zabezpečíme a společně s vámi naplánujeme přechod na podporovanou verzi.

Zdroje

Okamžitý kontakt

Každá hodina se počítá. Napište nám hned.

Stručně popište systém, verzi PHP a pozorování. Ozveme se, vyjasníme situaci a budeme pracovat na dálku, dokud nebude incident uzavřen a zdokumentován.

Okamžitá pomoc