WordPress 7.1.2: kritická zranitelnost jádra, kterou útočníci už zneužívají

WordPress 7.1.2 zranitelnost CVE-2026-87902 je kritická chyba v jádru WordPressu, kterou WordPress opravil 22. září 2026 ve verzi 7.1.2. Útočník se při ní nemusí přihlásit. Podvrženým požadavkem dokáže přimět výběr šablony stránky, aby načetl jiný PHP soubor na serveru, a když server a šablona splňují podmínky, spustí vlastní kód. Zasažené jsou verze 4.7.0 až 7.1.1 a oprava vyšla pro všechny větve až po 4.7. Patchstack už zaznamenal aktivní zneužívání včetně zápisu souborů na disk. Aktualizujte ještě dnes.

Tento článek je akční postup pro majitele a správce webů: co chyba dělá, jak zjistíte svou verzi, jak aktualizovat bez rozbití webu, jak hledat stopy útoku a co dělat, pokud aktualizace hned nejde. Obecné zásady ochrany najdete v našem 10bodovém checklistu bezpečnosti WordPress webu, tady řešíme jen tuto konkrétní chybu.

Co je WordPress 7.1.2 zranitelnost CVE-2026-87902

Jde o path traversal při výběru šablony stránky, který vede k vložení lokálního PHP souboru (local file inclusion) a za určitých podmínek ke vzdálenému spuštění kódu (RCE).

Když WordPress zobrazuje stránku, funkce get_page_template() skládá seznam kandidátů na soubor šablony. Podle technické analýzy Patchstack se jeden z kandidátů skládal z parametru pagename, který přichází přímo z požadavku, a na rozdíl od sousední větve kódu neprocházel kontrolou validate_file(). Zakódovaná sekvence pro přesun o složku výš tak prošla až do cesty k souboru a WordPress mohl vložit PHP soubor mimo složky aktivní šablony.

Oficiální bezpečnostní advisory GHSA-7hp8-65ch-5whp hodnotí chybu jako kritickou se skóre CVSS 4.0 9.2 a řadí ji pod CWE-98. Aby útočník dosáhl spuštění vlastního kódu, musí platit dvě podmínky:

• Šablona má složku začínající na page-: aktivní rodičovská nebo podřízená (child) šablona obsahuje v kořeni složku, jejíž název začíná na page-, například page-templates. Advisory jmenovitě uvádí starší výchozí šablony Twenty Twelve a Twenty Fourteen a populární šablony třetích stran Neve, Hestia a Sydney.
• Na serveru je vhodný PHP soubor: útočníci sahají po známém souboru pearcmd.php z balíku PEAR, který lze zneužít, když má PHP zapnuté nastavení register_argc_argv. Podle advisory to platí pro oficiální Docker obraz php a pro výchozí konfiguraci cPanel s PHP starším než 8.5.

Pokud šablona první podmínku splňuje, vložení souboru bez přihlášení funguje. Zda útočník spustí i vlastní kód, závisí na serveru. Patchstack proto doporučuje brát chybu jako kritickou, dokud si vlastní prostředí neověříte. Oprava ve verzi 7.1.2 má dvě části: doplnila chybějící kontrolu validate_file() a přidala novou kontrolu, podle které musí každá výsledná cesta k šabloně ležet v povolené složce šablony. Bezpečnostní tým tak podle Patchstack neřešil jednu chybu, ale celou třídu problémů.

Koho se WordPress 7.1.2 zranitelnost týká a které verze jsou opravené

Zasažený je každý web s WordPressem 4.7.0 až 7.1.1, který ještě nedostal opravenou verzi své větve. WordPress vydal opravu pro všechny větve, které ještě dostávají bezpečnostní záplaty, tedy až po 4.7. Starší web tak dostane opravu bez skoku na novou hlavní verzi. Podle oficiálního oznámení k vydání 7.1.2 je však aktivně podporovaná jen nejnovější verze.

Větev	Zranitelné verze	Opravená verze
7.1	7.1.0 až 7.1.1	7.1.2
7.0	7.0.0 až 7.0.5	7.0.6
6.9	6.9.0 až 6.9.8	6.9.9
6.8	6.8.0 až 6.8.9	6.8.10
6.7	6.7.0 až 6.7.8	6.7.9
6.6	6.6.0 až 6.6.8	6.6.9
6.5	6.5.0 až 6.5.11	6.5.12
4.7	4.7.0 až 4.7.36	4.7.37

Svou verzi zjistíte za minutu:

• V administraci: Nástěnka > Aktualizace. Stránka ukáže aktuální verzi a nabídne aktualizaci, pokud je dostupná.
• Přes WP-CLI: příkaz wp core version vypíše verzi jádra.
• U více webů: zkontrolujte všechny, i staré microsite, weby na subdoménách a testovací kopie na hostingu. Automatizovaný skener je prohledá stejně jako hlavní web.

Pokud má web zapnuté automatické aktualizace na pozadí, podle oznámení WordPressu se aktualizace spustí sama. Neberte to jako hotovou věc a verzi si ověřte. Automatické aktualizace mohl v minulosti někdo vypnout a na to se obvykle přijde až při podobném incidentu.

Jak aktualizovat ještě dnes bez rozbití webu

Aktualizace jádra na opravenou verzi je jediná skutečná oprava, všechno ostatní jen dočasně snižuje riziko. Verze 7.1.2 je podle Patchstack čistě bezpečnostní vydání s jedinou opravou, takže riziko, že rozbije web, je menší než u velké aktualizace. I tak postupujte v tomto pořadí:

1. Záloha: před aktualizací zálohujte databázi i soubory. Pokud nemáte ověřený postup, použijte náš návod na zálohování WordPress webu podle pravidla 3-2-1.
2. Aktualizace: v administraci Nástěnka > Aktualizace > Aktualizovat, nebo přes WP-CLI příkazem wp core update. Na starší větvi můžete opravenou verzi téže větve nainstalovat cíleně, například wp core update --version=6.8.10, a přechod na nejnovější verzi si naplánovat zvlášť.
3. Ověření verze: po aktualizaci se znovu podívejte, zda web opravdu běží na 7.1.2 nebo na opravené verzi své větve.
4. Funkční test: projděte klíčová místa webu: kontaktní formulář, přihlášení, košík a pokladnu, pokud jde o e-shop.

U e-shopu nebo webu s množstvím pluginů je bezpečnější postup přes testovací kopii, který popisujeme v článku aktualizace WordPressu přes staging a rollback. U chyby, kterou útočníci už aktivně zkoušejí, však produkční aktualizaci neodkládejte o dny. Pokud se po aktualizaci něco pokazí, pomůže vám návod co dělat, když web po aktualizaci WordPressu nefunguje.

Jak zjistit, zda útočníci váš web už zkoušeli

Útoky začaly v den vydání opravy, proto nestačí aktualizovat, je potřeba podívat se i do logů a na server. Podle průběžného sledování Patchstack zachytil jejich firewall první pokusy 22. září 2026, tedy v den vydání 7.1.2, a ještě ten den i první pokus zapsat přes pearcmd.php soubor na disk. Útočníci podle Patchstack stavěli útoky z rozdílu v kódu opravy. Od 23. září kolují veřejné skenovací nástroje včetně pojmenované šablony pro skener Nuclei, takže chybu dnes zkouší kdokoli, ne jen úzká skupina útočníků.

Útok podle Patchstack probíhá ve třech fázích: ověření, zda vložení souboru funguje (přes neškodné soubory jádra), ověření, zda je dostupný pearcmd.php, a zápis PHP souboru na disk. V přístupových lozích (access log) hledejte tyto signály:

• parametr pagename, který obsahuje %2e%2e nebo %252e%252e, v adrese i v těle POST požadavku,
• hodnotu pagename, která začíná templates%2f nebo názvem jiné složky page-,
• parametry pagename a page_id společně v jednom požadavku na kořen webu nebo na /index.php,
• jakýkoli výskyt řetězců pearcmd, +config-show nebo +config-create.

Na serveru zkontrolujte složky /tmp a /var/tmp. Nečekané soubory .php tam podle Patchstack znamenají, že zápis uspěl, a server je třeba brát jako kompromitovaný, ne jen skenovaný. Druhý signál je v lozích: odpověď 200 s obsahem OPML nebo RSS na běžné adrese stránky znamená, že vložení souboru na vašem serveru proběhlo. Na sdíleném hostingu do těchto složek často nevidíte, pak požádejte o kontrolu poskytovatele hostingu.

Pokud takové stopy najdete, samotná aktualizace nestačí. Změňte hesla administrátorů i přístupy k hostingu, obnovte bezpečnostní klíče ve wp-config.php, zkontrolujte seznam uživatelů s rolí administrátor a zvažte obnovu ze zálohy před útokem.

Co dělat, pokud nemůžete aktualizovat hned

Dočasně lze riziko snížit, ale nic z toho nenahrazuje aktualizaci. Tyto kroky slouží jen jako přemostění, než aktualizaci připravíte:

• Podívejte se do složky šablony: otevřete wp-content/themes a v aktivní šabloně i v její rodičovské šabloně hledejte v kořeni složku, jejíž název začíná na page-. Pokud tam je, první podmínka zneužití je splněná.
• Ověřte register_argc_argv: hodnotu najdete ve výpisu phpinfo() pro webové PHP, nebo se zeptejte hostingu. Podle Patchstack vypnutí neopraví vložení souboru, ale přeruší řetězec přes pearcmd, který z úniku informací dělá spuštění kódu.
• Pravidlo ve firewallu (WAF): odmítněte požadavky, ve kterých parametr pagename obsahuje sekvenci pro přesun o složku výš. Skutečný slug stránky ji nikdy neobsahuje, takže běžný provoz to podle Patchstack neomezí.
• Nespoléhejte na blokování IP adres: Patchstack eviduje útoky z několika stovek adres a většina požadavků se vydává za běžný prohlížeč.

V praxi: co tato chyba ukazuje o správě webu

Chyba v jádru se týká i webů, které mají pluginy v pořádku, proto správa nemůže stát jen na kontrole pluginů. U českých a slovenských firemních webů v praxi vidíme, že nejvíc se zapomíná na weby „beze změn“: microsite ke kampani, starý web na subdoméně, testovací kopii na hostingu. Právě ty běží roky na staré větvi a nikdo je nesleduje. U této chyby navíc rozhoduje i struktura šablony, kterou běžný přehled zranitelných pluginů neukáže.

Druhá lekce je rychlost. Když útočníci zkoušejí chybu v den vydání opravy, měsíční cyklus aktualizací na bezpečnostní vydání nestačí. Kontrolovaný postup přes staging má smysl u velkých verzí, bezpečnostní vydání jádra však patří na web týž den. Jak do toho zapadá celý rok údržby, popisujeme v kompletním průvodci správou WordPress webu.

Jak to řešíme v Denvě: při převzetí webu do správy a podpory se nejdřív podíváme na verze, pluginy, zálohy, hosting i stav zabezpečení. Při běžné správě průběžně sledujeme známé zranitelnosti a po každé aktualizaci ověříme, že web opravdu funguje, například že se odešle formulář a naskočí pokladna. Staráme se i o weby, které postavil někdo jiný.

Kdy to zvládnete sami a kdy s námi

Zvládnete sami, pokud:

• máte jeden web na aktuální větvi a zapnuté automatické aktualizace jádra,
• umíte si ověřit verzi a udělat zálohu, ze které jste už někdy obnovovali,
• hosting vám na požádání pošle přístupové logy a zkontroluje složky /tmp.

Vyplatí se přizvat nás, pokud:

• v lozích vidíte pagename se zakódovanými sekvencemi nebo řetězec pearcmd,
• web běží na staré větvi nebo má upravenou šablonu se složkou page-,
• spravujete více webů a nemáte přehled, na jakých verzích běží,
• nemáte zálohu, ze které byste web uměli spolehlivě obnovit.

Závěr

Pokud váš WordPress neběží na 7.1.2 ani na opravené verzi své větve, aktualizujte ještě dnes a pak se podívejte do logů a do složek /tmp. Chyba má hodnocení CVSS 4.0 9.2, oprava existuje pro všechny větve od 4.7 a útoky podle Patchstack běží ode dne vydání. Šablona se složkou page- a zapnuté register_argc_argv dělají z vložení souboru spuštění kódu, proto si obě podmínky ověřte i po aktualizaci. Pokud si nejste jistí, co jste v lozích našli, napište nám a podíváme se na to s vámi.

FAQ

Časté otázky.

Je můj web v bezpečí, pokud mám zapnuté automatické aktualizace?

Pravděpodobně ano, ale ověřte to. Podle oznámení WordPressu se na webech s automatickými aktualizacemi na pozadí aktualizace spustí sama. V administraci na stránce Aktualizace zkontrolujte, zda web běží na 7.1.2 nebo na opravené verzi své větve.

Musím přejít na WordPress 7.1, pokud mám starší verzi?

Kvůli této chybě ne. WordPress vydal opravu pro všechny větve až po 4.7, například 6.8.10 nebo 4.7.37. Aktivně podporovaná je však jen nejnovější verze, proto si přechod naplánujte.

Jak zjistím, zda moje šablona splňuje podmínku zneužití?

Podívejte se do složky aktivní šablony i její rodičovské šablony ve wp-content/themes. Pokud je v jejím kořeni složka, jejíž název začíná na page-, například page-templates, podmínka je splněná. Aktualizaci to však nenahrazuje.

Co když v lozích najdu požadavky s řetězcem pearcmd?

Znamená to, že útočník zkoušel řetězec vedoucí ke spuštění kódu. Zkontrolujte složky /tmp a /var/tmp na nečekané soubory .php. Pokud tam jsou, berte server jako kompromitovaný, změňte přístupy a zvažte obnovu ze zálohy.

Stačí firewall nebo bezpečnostní plugin místo aktualizace?

Ne. Pravidlo, které odmítá sekvence pro přesun o složku výš v parametru pagename, je podle Patchstack účinná dočasná ochrana. Skutečnou opravou je jen aktualizace jádra na opravenou verzi.