Stručně: Po PHP2Shell samotná zobrazená verze PHP mnoho nedokazuje, protože poskytovatelé hostingu opravy často nasazují jako backport. Vyžádejte si proto písemné potvrzení aktualizace PHP: stav balíčku pro každou větev PHP, okamžik instalace a restart všech procesů PHP. Vzor ke zkopírování najdete níže.
Proč je písemné potvrzení důležité právě teď
Dne 21. 10. 2026 vydal projekt PHP záplaty pro dvě kritické zranitelnosti, známé pod názvem PHP2Shell. Obě umožňují spuštění škodlivého kódu na dálku bez přihlášení. BSI (německý spolkový úřad pro informační bezpečnost) vyhlásil varovný stupeň 3 / oranžový a doporučuje okamžitou aktualizaci.
Kdo provozuje web u poskytovatele hostingu, často nemůže aktualizaci nasadit sám. Zároveň však jako provozovatel nesete odpovědnost za data svých zákazníků. Písemné, konkrétní potvrzení od poskytovatele je proto víc než formalita. Je součástí vaší dokumentace, například vůči pověřencům pro ochranu osobních údajů, pojišťovnám nebo vedení.
K tomu přistupuje další věc: záplata neodstraní škodlivý software, který byl podstrčen dříve. Podle zpráv médií byl první pokus o útok pozorován už 17. 10. Přesný okamžik, kdy byl váš server chráněn, je proto důležitý pro otázku, zda musíte kontrolovat dál.
Proč zobrazená verze PHP nestačí
Opraveny jsou PHP 8.5.12, 8.4.27, 8.3.36 a 8.2.35. Mnoho distribucí a poskytovatelů ale převezme opravu jako backport do vlastního balíčku. Rozhraní jako Plesk pak dál ukazuje 8.2.34, přestože je server záplatovaný.
Naopak i správné číslo verze může klamat. Nové soubory samy o sobě nechrání, dokud v paměti běží staré procesy PHP. Nový stav je aktivní až po restartu všech workerů. Více v článku Jak správně ověřit verzi PHP a stav záplaty.
| Tvrzení poskytovatele | Co dokládá | Co chybí |
|---|---|---|
| „Všechny systémy jsou aktuální.“ | málo | verze nebo stav balíčku, datum, restart |
| „PHP 8.3.36 je nainstalováno.“ | verzi | datum, restart, postižené servery |
| „Backport v balíčku xy, restart dne …“ | záplatu a její aktivaci | případně údaje k PHP 8.1 a starším |
Jaké údaje od poskytovatele potřebujete
Požádejte o odpovědi na tyto body, pokud možno pro každý web nebo smlouvu:
- Které větve a verze PHP jsou pro vaše weby aktivní, včetně starších, které běží jen pro jednotlivé adresáře?
- Jsou zahrnuty opravy pro CVE-2026-109618 a CVE-2026-109619, jako oficiální verze, nebo jako backport?
- Kdy byla aktualizace nainstalována a kdy byly restartovány všechny procesy PHP (pooly FPM, Apache, LiteSpeed)?
- Je kvůli CVE-2026-115560 vypnuto
session.upload_progress.enabled? - Jaký provozní režim váš tarif používá, například PHP-FPM, nebo Apache s mod_php? U mod_php vidí tým PHP nejvyšší riziko.
- Které přístupové a chybové logy od 20. 10. 2026 se uchovávají a jak je získáte?
Pokud některý web běží ještě na PHP 8.1 nebo starším, zeptejte se zvlášť. Pro tyto větve už oficiální aktualizace neexistují, jen minimální zdrojové backporty pro 7.4, 8.0 a 8.1.
Vzor: vyžádání potvrzení aktualizace PHP od hostingu
Text zkopírujte do tiketu podpory nebo e-mailu poskytovateli hostingu. Údaje v hranatých závorkách doplňte.
Předmět: Žádost o potvrzení stavu oprav PHP (PHP2Shell, CVE-2026-109618 / CVE-2026-109619)
Dobrý den,
provozujeme u Vás následující weby / smlouvy:
[Číslo zákazníka, smlouva, domény]
V souvislosti s bezpečnostními chybami PHP CVE-2026-109618 a
CVE-2026-109619 (PHP2Shell, opravy z 21.10.2026) a upozornění
k CVE-2026-115560 z 23.10.2026 Vás žádáme o písemné
potvrzení následujících bodů:
1. Které verze PHP, resp. stavy balíčků jsou pro naše weby aktivní?
2. Obsahují tyto opravy (oficiální verze, nebo backport)?
3. Datum a čas instalace.
4. Datum a čas restartu všech procesů PHP (FPM, Apache,
LiteSpeed apod.).
5. Je session.upload_progress.enabled na straně serveru vypnuto?
6. Jaký provozní režim PHP se používá (např. PHP-FPM, mod_php)?
7. Uchovávají se přístupové a chybové logy od 20.10.2026 a
jak je můžeme získat?
8. Pokud některý web stále používá PHP 8.1 nebo starší: jaké zabezpečení
tam existuje a jaký přechod doporučujete?
Tyto údaje potřebujeme pro naši interní dokumentaci.
Děkujeme a s pozdravem
[Jméno, firma, funkce]
Jak odpověď správně vyhodnotit a sám ověřit
Dobrá odpověď uvádí konkrétní stavy, data a časy. Obecné formulace jako „zareagovali jsme“ pro vaši dokumentaci nestačí. V takovém případě se přívětivě zeptejte na chybějící body.
Pokud to váš tarif umožňuje, ověřte si stav i sami. S přístupem přes SSH obvykle stačí tyto příkazy:
# Verze příkazové řádky (může se lišit od verze pro web)
php -v
# Stav balíčku v Debianu/Ubuntu
dpkg -l | grep -E "php[0-9.]*-(fpm|cli|common)"
# Stav balíčku v RHEL, Alma, Rocky
rpm -qa | grep -i php
# Od kdy běží procesy PHP-FPM?
ps -eo pid,lstart,cmd | grep "[p]hp-fpm"
Pokud je čas spuštění procesů PHP dřívější než potvrzené datum instalace, restart nebyl úplný.
Když poskytovatel neodpovídá nebo odpovídá vyhýbavě
Zůstane-li odpověď bez reakce nebo chybí rozhodující údaje, neberte situaci za vyjasněnou. BSI doporučuje webové servery dočasně odpojit od sítě, pokud aktualizace není okamžitě možná. Zda je to pro váš web přiměřené, rozhoduje vedení, ideálně písemně a s datem.
Souběžně se vyplatí podívat se na možné stopy útoku, protože okamžik záplaty zůstává otevřený. Vodítka nabízí článek Jsem už kompromitován?. Bez přístupu přes SSH zůstává písemné potvrzení vaším nejdůležitějším dokladem. Které povinnosti má poskytovatel a které vy, vysvětluje stránka Sdílený hosting: co dělá poskytovatel; pro spravované servery pomůže Managed server: vyjasnění odpovědnosti.
Dotaz, odpověď a vlastní výsledky kontroly ukládejte s datem do jedné složky. Tento spis později pomůže při dotazech pojišťoven nebo pověřenců pro ochranu osobních údajů.
Jak konkrétně pomáhá PHP SOS?
- Společně s vámi formulujeme dotaz poskytovateli hostingu a odpověď odborně vyhodnotíme.
- Kde existuje přístup, sami ověříme stav balíčku, aktivní provozní režim a restart procesů PHP.
- Pokud zůstanou mezery, nasadíme přechodná opatření nebo naplánujeme přechod na podporovanou verzi.
- Výsledek a časové údaje zachytíme v dokladu, který můžete předat interně.
Jak probíhá aktualizace s restartem a dokladem, popisuje naše záplatování PHP jako služba.
Časté dotazy
Stačí, když mi poskytovatel hostingu napíše, že je vše aktuální?
Pro vaši dokumentaci spíše ne. Požádejte o konkrétní údaje: stav balíčku nebo verzi pro každou větev PHP, datum instalace a datum restartu všech procesů PHP. Teprve s nimi můžete vymezit časové okno zranitelnosti.
Proč moje hostingové rozhraní stále ukazuje PHP 8.2.34?
Distribuce a poskytovatelé hostingu někdy nasazují bezpečnostní opravy jako backport, aniž by změnili číslo verze. Plesk pak může dál zobrazovat 8.2.34, přestože je server záplatovaný. Jasno udělá jen potvrzení poskytovatele ke stavu balíčku.
Co mám dělat, když poskytovatel hostingu neodpovídá?
Zdokumentujte svůj dotaz s datem a po přiměřené době se zeptejte znovu. Souběžně ověřte, zda můžete přechodná opatření nastavit sami, a dohodněte s vedením, zda web do vyjasnění odpojíte od sítě, jak BSI pro nezáplatované servery doporučuje.
Uzavře zranitelnost i aktualizace WordPressu nebo e-shopu?
Ne. PHP2Shell je v samotném PHP. Aktualizace CMS nebo software e-shopu nic nemění na interpretu PHP, který na serveru běží.