Kritická zranitelnost WordPressu CVE-2026-87902: co znamená a jak jsme ji vyřešili

Tvůrci WordPressu vydali 22. září 2026 bezpečnostní aktualizaci 7.1.2, která opravuje kritickou zranitelnost CVE-2026-87902 přímo v jádru systému. Chyba se týká všech verzí od 4.7.0 do 7.1.1, tedy prakticky všech verzí vydaných za posledních zhruba deset let. Nepřihlášený útočník přes ni může přimět web, aby načetl soubor, který k tomu nikdy nebyl určen, a za určitých podmínek dokonce spustit na serveru vlastní kód. Tuto nebezpečnou část útoku na našich serverech provést nešlo, protože jsou preventivně zabezpečené. Přesto jsme jádro WordPressu na všech produkčních webech v naší péči aktualizovali do 24 hodin od vydání opravy – na jedinou vrstvu ochrany totiž nespoléháme.

Bezpečnostní opravy jsou u WordPressu běžnou součástí provozu. Většina z nich se týká méně používaných funkcí nebo ke zneužití vyžaduje přihlášeného uživatele. Tentokrát je situace jiná: chyba sídlí přímo v jádru, týká se téměř všech verzí, které jsou dnes v provozu, a útočník k jejímu zneužití nepotřebuje žádný účet. Proto jí věnujeme samostatný článek.

Hned na úvod to podstatné: pokud je váš web v péči wpsprava.online, nemusíte nic dělat. Opravu jsme nasadili a prověřili jsme i naše servery. Podrobnosti najdete v části Naši klienti jsou v bezpečí. Pro všechny ostatní jsme na konci připravili praktický postup, jak si web zkontrolovat.

Co se stalo

Zranitelnost s označením CVE-2026-87902 nahlásil 20. července 2026 bezpečnostní výzkumník Robert Ressl, a to prostřednictvím oficiálního programu WordPressu pro hlášení bezpečnostních chyb na platformě HackerOne. Díky takzvanému zodpovědnému zveřejnění měli vývojáři čas připravit opravu dřív, než se o chybě dozvěděla veřejnost.

Oprava vyšla 22. září 2026 jako součást bezpečnostního vydání WordPress 7.1.2. Pokud váš web už běží na aktuální řadě 7.1, o jejíchž novinkách jsme psali v článku Co přináší WordPress 7.1, stačí přejít na verzi 7.1.2. Protože chyba sahá hluboko do historie, vývojáři opravu přenesli i do všech starších větví až po verzi 4.7:

• 7.1.2 pro weby na řadě 7.1,
• 7.0.6 pro řadu 7.0,
• 6.9.9, 6.8.10 a 6.7.9 pro řady 6.9 až 6.7,
• další opravná vydání starších řad až po verzi 4.7.37.

Zranitelné jsou všechny verze od 4.7.0 do 7.1.1 včetně. Pokud váš web běží na kterékoli z nich, je potřeba ho aktualizovat.

Jak zranitelnost funguje

Když návštěvník otevře stránku, WordPress se musí rozhodnout, kterým souborem šablony ji vykreslí. Část tohoto rozhodnutí vychází z adresy stránky, konkrétně z parametru pagename, který může do adresy napsat kdokoli.

Představte si recepční, která podle jména na lístku přinese z archivu správnou složku. Kvůli chybě může návštěvník na lístek napsat i cestu, která vede mimo archiv – a recepční se po ní poslušně vydá. Útočník tak může přimět WordPress, aby načetl soubor z jiného místa na serveru, než kde leží šablona. Odborně se tomu říká Local File Inclusion (LFI), tedy vložení místního souboru.

Při souběhu několika dalších podmínek se z toho může stát vzdálené spuštění kódu (RCE). To je nejhorší možný scénář: útočník by pak mohl na serveru spouštět vlastní příkazy a převzít nad webem kontrolu.

Technický pohled

Chyba se nachází ve funkci get_page_template() (soubor wp-includes/template.php), která vyhledává šablonu stránky. Z veřejného parametru pagename sestavuje název souboru šablony, aniž by výslednou cestu omezila na adresář šablony. Ošetření vstupu sice s běžnými pokusy o průchod adresáři (path traversal) počítá, dvojitě zakódovanou variantu, například %252e%252e%252f, však nezachytí. Po dekódování z ní vznikne ../ a WordPress načte soubor mimo složku šablony. K útoku není potřeba žádné přihlášení.

Jak vážné to je

Oficiální bezpečnostní upozornění na GitHubu (GHSA-7hp8-65ch-5whp) hodnotí chybu skórem 9,2 z 10 podle standardu CVSS 4.0, tedy jako kritickou. Záznam v databázi CVE uvádí skóre 8,1 podle CVSS 3.1, což odpovídá vysoké závažnosti.

Nejde o rozpor. CVSS je mezinárodní stupnice pro hodnocení závažnosti zranitelností a její verze 3.1 a 4.0 počítají skóre každá trochu jinak – jednotlivé faktory, například podmínky nutné k útoku nebo jeho dopad, váží odlišně. Tatáž chyba tak může dostat různé číslo. V podstatném se ale obě hodnocení shodují: jde o opravu, kterou je třeba nasadit co nejdříve.

Kdy hrozí převzetí serveru

Už samotná možnost načíst cizí soubor je vážná chyba, kterou by žádný web neměl nechat neopravenou. Aby z ní však vzniklo vzdálené spuštění kódu, musí platit všechny následující podmínky současně:

• Šablona obsahuje rizikovou složku: v nejvyšší úrovni šablony je složka, jejíž název začíná na page-, typicky page-templates/. Takovou složku mají například i starší výchozí šablony Twenty Twelve a Twenty Fourteen.
• Na serveru je vhodný soubor PHP: útok potřebuje soubor, který lze zneužít jako takzvaný gadget. Zneužití bylo předvedeno na souboru pearcmd.php z balíku PEAR.
• PHP má zapnutou volbu register_argc_argv.
• Server má zapisovatelný adresář pro dočasné soubory.

Všimněte si, že jen první podmínka závisí na webu – ostatní tři určuje hosting. Dva weby se stejnou šablonou tak mohou být z pohledu rizika na tom úplně jinak, podle toho, jak pečlivě je nastavený server, na kterém běží.

Útočníci už weby prověřují

Bezpečnostní společnost Patchstack zaznamenala první průzkumné požadavky necelých pět hodin po zveřejnění opravy, 22. září v 17:44 UTC (v 19:44 našeho času). Útočníci zatím jen zjišťují, které weby jsou zranitelné. Takové požadavky web nepoškodí, ale prozradí, zda už má opravu. Navíc je veřejně dostupný takzvaný proof-of-concept, tedy ukázkový kód, který zneužití předvádí.

Hromadné zneužití vedoucí ke spuštění kódu zatím potvrzeno nebylo. To je dobrá zpráva, ale ne důvod k odkladu. Když existuje veřejně dostupný ukázkový kód a útočníci už weby automaticky procházejí, čas na klidné vyčkávání rychle ubývá.

Naši klienti jsou v bezpečí

Nebezpečnou část útoku, tedy vzdálené spuštění kódu a převzetí serveru, na našich serverech provést nešlo. Zabránilo tomu jejich preventivní zabezpečení, které udržujeme dlouhodobě, nejen v reakci na tuto chybu. Samotná chyba v jádru WordPressu se ale týkala i webů v naší správě, stejně jako všech ostatních. Proto jsme jádro přesto aktualizovali na všech webech: díru samotnou zavírá až oficiální oprava a na jedinou vrstvu ochrany nespoléháme.

Co útok na našich serverech zastavilo

Po zveřejnění chyby jsme naši hostingovou infrastrukturu porovnali s podmínkami pro vzdálené spuštění kódu. Výsledek: tyto podmínky na našich serverech nebyly splněny ani před nasazením opravy.

• Na serverech chybí vhodný soubor, který by šlo zneužít jako gadget. Zbytečné balíčky pro PHP, jako je PEAR, neinstalujeme.
• Každý produkční web běží na vlastním virtuálním serveru. Weby spolu nesdílejí žádné prostředí, a případný útok se tak z jednoho webu nemůže přenést na jiný.
• Na novějších serverech je navíc volba register_argc_argv vypnutá.
• Žádná aktivní šablona na našich serverech nemá rizikovou složku začínající na page-.

Proč jsme přesto aktualizovali

Chceme být přesní: nastavení serverů zabránilo tomu, aby útok vedl až k převzetí serveru, chybu samotnou však neodstranilo. Tu zavírá jen oprava jádra. Proto jsme všechny produkční weby v naší správě aktualizovali na opravenou verzi příslušné řady méně než 24 hodin po vydání opravy, nejpozději do rána 23. září 2026. Tomu se říká vrstvená ochrana: bezpečnost nestojí na jediném opatření, ale na několika, která se navzájem jistí. Když jedna vrstva selže, jako tentokrát samotné jádro WordPressu, zachytí to další.

Jak jsme postupovali

• Sledování bezpečnostních upozornění: o opravě jsme věděli ještě v den jejího vydání, protože bezpečnostní hlášení k WordPressu průběžně sledujeme.
• Nasazení bez odkladu: na rozdíl od běžných aktualizací jsme nečekali na plánovaný termín a opravu nasadili mimo obvyklý cyklus.
• Záznam ve správě verzí: u každého webu jsme novou verzi zapsali do souboru composer.json a změnu uložili do jeho historie v GitLabu, a to pro produkční i vývojovou větev. Víme tak přesně, co se kdy změnilo, a vývojové prostředí nezůstává pozadu.
• Informování klientů: každý klient se od nás dozvěděl, že proběhla mimořádná bezpečnostní aktualizace.

Co dělat, pokud váš web nespravujeme

WordPress tuto opravu šíří jako automatickou aktualizaci na pozadí, a to u všech webů, které mají automatické aktualizace povolené. Přesto se na ni nevyplatí spoléhat naslepo.

Postup krok za krokem

• Nejdřív zálohujte. Před jakýmkoli zásahem si pořiďte kompletní zálohu souborů i databáze.
• Zkontrolujte verzi. V administraci otevřete Nástěnka › Aktualizace. Web musí běžet na verzi 7.1.2, případně na opravené verzi své řady (například 7.0.6 nebo 6.9.9).
• Aktualizujte. Pokud máte starší verzi, spusťte aktualizaci. U webů spravovaných přes Composer tlačítko v administraci nepomůže – verzi je nutné zvýšit v souboru composer.json a web znovu nasadit, případně o to požádat vývojáře.
• Podívejte se do složky šablony. Zjistěte, zda adresář aktivní šablony obsahuje v nejvyšší úrovni složku začínající na page-. Nejde o chybu šablony, jen o jednu z podmínek, které zvyšují riziko.
• Zeptejte se poskytovatele hostingu. Ověřte si, zda má PHP zapnutou volbu register_argc_argv a zda je na serveru nainstalovaný PEAR.
• Projděte přístupové logy. Hledejte požadavky s parametrem pagename=, které obsahují %252e nebo %252f. Takové záznamy znamenají, že se o váš web někdo zajímal. Pokud je najdete a web v té době ještě nebyl opravený, obraťte se na odborníka.

Tato zranitelnost dobře ukazuje, proč se péče o web nevyplácí odkládat. Oprava existovala, ale chráněný byl jen ten web, na kterém ji někdo včas nasadil a ověřil. Pokud nechcete podobné zprávy sledovat sami, přenechte to nám. O bezpečnostní aktualizace, zálohy i dohled nad servery se v rámci wpsprava.online staráme za vás. Přehled služeb a tarifů najdete v ceníku nebo nás rovnou kontaktujte – rádi váš web zkontrolujeme a převezmeme do správy.

Často kladené otázky

Je můj web ohrožený?

Pokud běží na WordPressu ve verzi od 4.7.0 do 7.1.1, je zranitelný a měli byste ho co nejdříve aktualizovat. Zda by útočník mohl převzít i server, závisí na šabloně a nastavení hostingu. Načíst cizí soubor je ale možné na každém neopraveném webu.

Aktualizoval se můj web sám?

Možná ano, ale nespoléhejte na to. Automatická aktualizace proběhne jen tam, kde je povolená a kde se úspěšně dokončí. Weby spravované přes Composer nebo s vypnutými aktualizacemi se samy neaktualizují. Verzi si ověříte v administraci v části Nástěnka › Aktualizace.

Musím jako klient wpsprava.online něco dělat?

Ne. Převzetí serveru, tedy nebezpečnou část útoku, na našich serverech provést nešlo díky jejich preventivnímu zabezpečení. Přesto jsme jádro WordPressu na všech produkčních webech v naší správě aktualizovali do 24 hodin od vydání opravy, protože samotnou chybu zavírá až oficiální oprava. O mimořádné aktualizaci jsme vás informovali a žádný další krok z vaší strany není potřeba.

Co znamenají zkratky LFI a RCE?

LFI (Local File Inclusion) označuje chybu, kdy útočník přiměje aplikaci načíst soubor, který už na serveru leží, ale nikdy neměl být takto použit. RCE (Remote Code Execution) znamená vzdálené spuštění kódu – útočník může na serveru spouštět vlastní příkazy. Jde o jeden z nejzávažnějších typů zranitelností.