Stručně: Zranitelnost PHP, o které se nyní píše, není ve WordPressu, ale v PHP na serveru pod ním. Aktualizace WordPressu proto PHP2Shell neuzavře. Rozhodující jsou stav záplat PHP, restart všech procesů PHP a kontrola typických úkrytů, jako jsou wp-content/uploads a mu-plugins.
Proč aktualizace WordPressu PHP2Shell neřeší
WordPress je aplikace napsaná v PHP. Zranitelnosti CVE-2026-109618 a CVE-2026-109619 leží o úroveň níž, přímo v interpretu PHP. Podle týmu PHP umožňují spuštění škodlivého kódu na dálku bez přihlášení. U Apache s mod_php byl exploit předveden ještě předtím, než se vůbec spustí kód WordPressu.
Web s aktuálním jádrem, aktuálními pluginy a silnými hesly tak může být přesto napadnutelný, pokud je PHP pod ním staré. Naopak záplatované PHP nedokazuje, že se předtím nic nestalo. Souvislosti vysvětlujeme v článku Co je PHP2Shell?.
| Úroveň | Kdo aktualizuje | Uzavře PHP2Shell? |
|---|---|---|
| Jádro WordPressu | Vy nebo vaše agentura | Ne |
| Pluginy a šablony | Vy nebo vaše agentura | Ne |
| PHP na serveru | Poskytovatel hostingu nebo správce serveru | Ano, spolu s restartem všech procesů PHP |
Zranitelnost PHP ve WordPressu: kontrola verze PHP
V administraci najdete v nabídce Nástroje > Stav webu > Informace v sekci „Server“ verzi PHP, se kterou váš web skutečně běží. To vypovídá víc než php -v na příkazové řádce, protože příkazová řádka často používá jinou instalaci PHP než webový server.
Samotné zobrazené číslo ale nestačí. Opravené verze upstreamu jsou 8.5.12, 8.4.27, 8.3.36 a 8.2.35. Mnoho poskytovatelů hostingu však opravy nasazuje jako backport; pak zůstává uvedeno starší číslo, přestože je záplatováno. Jak zjistit skutečný stav, popisuje článek Jak správně ověřit verzi PHP a stav záplaty. Které verze PHP vaše verze WordPressu podporuje, ověříte podle systémových požadavků na wordpress.org.
Kde se škodlivý kód ve WordPressu rád skrývá
Po úspěšném útoku útočníci obvykle zanechají zadní vrátka, aby se mohli vrátit i po záplatě. WordPress má pro to známá místa:
- wp-content/uploads/: určeno pro obrázky a PDF, ne pro soubory PHP.
- wp-content/mu-plugins/: pluginy „must-use“ se načítají automaticky a v administraci nejdou deaktivovat.
- wp-config.php: obsahuje přístup k databázi a bezpečnostní klíče; vložený řádek si tu stěží všimnete.
- .htaccess v hlavním adresáři i v podsložkách: přesměrování jen pro vyhledávače nebo spouštění neobvyklých přípon souborů.
- Šablony, především
functions.php, a také deaktivované, zapomenuté pluginy. - Databáze: noví administrátoři v
wp_users, cizí JavaScript vwp_optionsnebo v příspěvcích.
Neškodné první kontroly pomocí WP-CLI a vestavěných nástrojů:
# Porovnat soubory jádra s oficiálními kontrolními součty
wp core verify-checksums
# Zkontrolovat pluginy z adresáře na wordpress.org
wp plugin verify-checksums --all
# Vypsat soubory PHP ve složce uploads
find wp-content/uploads -type f -name "*.php"
# Zobrazit všechny administrátory
wp user list --role=administrator
Nález je důvodem k důkladnému prověření, ještě ne důkazem. Komerční pluginy takto zkontrolovat nelze. Podrobnosti najdete v průvodci Jak najít zadní vrátka ve WordPressu.
Podezřelé soubory nemažte ukvapeně. Nejprve zálohujte soubory, databázi a logy serveru od 20. 10. 2026. Bez těchto stop se později nedá zjistit, zda unikla data.
Pluginy, šablony a přístupy správců jako další riziko
PHP2Shell nepotřebuje zranitelnost pluginu. V běžném provozu jsou ale pluginy a šablony nejčastějším vstupem do webů na WordPressu. Každý plugin přináší vlastní kód, vlastní funkce nahrávání a vlastní cykly aktualizací. Nepoužívané pluginy byste měli smazat, ne jen deaktivovat, protože deaktivované soubory zůstávají na serveru.
Pro wp-login.php a wp-admin platí: málo administrátorů, osobní účty místo sdílených přístupů a dvoufázové přihlášení. Pokud XML-RPC nepotřebujete, lze jej zablokovat. Při podezření by se měla obnovit všechna hesla a bezpečnostní klíče v wp-config.php. Editor souborů v administraci vypnete také tam:
define( 'DISALLOW_FILE_EDIT', true );
Co byste jako provozovatel WordPressu měli udělat nyní
- U poskytovatele hostingu si písemně nechat potvrdit stav záplat PHP a restart všech procesů PHP.
- Nechat uchovat logy serveru od 20. 10. 2026.
- Provést výše uvedené kontroly nebo je nechat provést.
- Aktualizovat WordPress, pluginy a šablony. To je správné, ale nenahrazuje to krok 1.
- Při nálezech web jen tak neprovozovat dál, ale nechat jej vyčistit.
Aktualizace platformy může uzavřít známé zranitelnosti ve WordPressu a pluginech. PHP opravit nedokáže a neodstraní ani vložené soubory, které nepatří k jádru.
Jak konkrétně pomáhá PHP SOS?
- S vámi nebo s vaším poskytovatelem hostingu zjistíme skutečný stav PHP vašeho webu na WordPressu, včetně backportů a restartu.
- Zálohujeme logy, soubory a databázi dříve, než se cokoli změní.
- Kontrolujeme jádro, pluginy, uploads, mu-plugins,
.htaccessa uživatelské účty, zda neobsahují zadní vrátka. - Při nálezech provede čištění naše odstranění malwaru až do uzavření a zdokumentování incidentu; bez nálezů instalaci zpevníme v rámci okamžité pomoci při PHP2Shell.
Časté dotazy
Musím kvůli PHP2Shell aktualizovat WordPress?
Aktuální WordPress je vždy užitečný, PHP2Shell ale neuzavře. Zranitelnost je v interpretu PHP na serveru. K tomu je potřeba aktualizace PHP nebo potvrzený backport vašeho poskytovatele hostingu a restart všech procesů PHP.
Chrání před PHP2Shell bezpečnostní plugin?
Jen velmi omezeně. Plugin sám běží jako kód PHP uvnitř WordPressu. U mod_php byl předveden exploit dříve, než se vůbec spustí kód aplikace; plugin tak útok možná vůbec nezaznamená.
Proč WordPress stále ukazuje starou verzi PHP, ačkoli poskytovatel hostingu záplatu nasadil?
Mnoho poskytovatelů hostingu a distribucí Linuxu opravy zavádí jako backport do stávající verze. Číslo verze pak zůstane stejné. Nechte si stav záplat potvrdit poskytovatelem písemně.
Smí být ve složce wp-content/uploads soubor PHP?
Za normálních okolností ne. Složka uploads je určena pro média. Soubor PHP tam je zřetelným varovným signálem a před smazáním by měl být zálohován a odborně prověřen.