Zranitelnost ve WordPressu není žádná novinka. Kdo provozuje weby postavené na této platformě, ví, že bezpečnostní záplaty chodí prakticky pořád. Drtivá většina problémů se přitom netýká WordPressu samotného – sídlí v pluginech a šablonách, tedy v té obrovské a různě kvalitní ekosystémové nadstavbě, kterou si na jádro každý dolepuje podle svých potřeb. Zranitelný kontaktní formulář, děravý e-shopový plugin, opomenutá kontrola oprávnění v nějaké obskurní rozšiřující knihovně – to je denní chleba každého, kdo sleduje bezpečnostní feedy. Zpráva „nová chyba ve WordPress pluginu“ má tak nízkou informační hodnotu, že ji většina lidí přejde bez mrknutí oka.

O to větší pozornost by měla vzbudit chyba, u které nic z toho neplatí. A přesně takový je případ zranitelnosti, která dostala přezdívku wp2shell.

Proč je tohle jiné

wp2shell je řetězec dvou chyb, který dohromady umožňuje neautentizované vzdálené spuštění kódu (RCE) – a to přímo v jádru WordPressu. Ne v pluginu. Ne v šabloně. V samotném Core.

Vypíchněme, co všechno k úspěšnému útoku není potřeba, protože právě ten seznam z toho dělá výjimečný případ:

• Není potřeba zranitelný plugin.
• Není potřeba zranitelná šablona.
• Není potřeba, aby se útočník přihlásil – žádné platné přihlašovací údaje, žádná session.
• Není potřeba, aby administrátor na cokoli klikl, nic si nestáhl ani nikam nezadal svoje heslo.

Stačí jediné: aby zranitelná instalace WordPressu byla dostupná z internetu. A to je, upřímně, stav naprosté většiny WordPress webů na planetě.

Kritická neautentizovaná RCE přímo v jádru WordPressu je něco, co jsme neviděli téměř deset let. WordPress pohání odhadem přes 40 procent všech webů na světě, takže „chyba v jádru, kterou lze zneužít bez přihlášení a bez součinnosti oběti“ je zhruba nejhorší kombinace slov, jakou si v tomto kontextu dokážete představit. Není náhoda, že tým WordPressu u této aktualizace zapnul vynucené automatické aktualizace – mechanismus, který se používá jen v opravdu vážných situacích, protože zasahuje do webů bez toho, aby o tom jejich provozovatel musel vědět.

Chybu objevil a zodpovědně nahlásil Adam Kues z Assetnote / Searchlight Cyber. Opravené verze WordPressu – 6.8.6, 6.9.5 a 7.0.2 – vyšly v pátek 17. července 2026.

Anatomie řetězce: dvě chyby, které se doplňují

Samotný název wp2shell docela dobře vystihuje, oč jde – „z WordPressu k shellu“. Cesta k němu ale vede přes dvě samostatné zranitelnosti, které jsou dohromady mnohem nebezpečnější než každá zvlášť.

První z nich je CVE-2026-60137, neautentizovaná SQL injection. Vstupním bodem je parametr dotazu author__not_in, který WordPress běžně používá k vyloučení určitých autorů z výpisu příspěvků. Právě přes tento parametr se dá do databázového dotazu propašovat obsah, který tam nemá co dělat.

Druhá chyba, CVE-2026-63030, se týká REST API a konkrétně tzv. batch endpointu (/wp-json/batch/v1). Jde o problém, kterému se říká route confusion neboli záměna cesty. Batch API umožňuje poslat v jednom HTTP požadavku hromadu dílčích operací najednou. Adam Kues ve svém rozboru popisuje, jak se u tohoto rozhraní podařilo rozpojit fázi validace a fázi vlastního provedení požadavku. Zjednodušeně řečeno: batch endpoint kontroluje jeden route, ale reálně vykoná jiný. Díky téhle desynchronizaci se útočníkem řízené parametry dostanou do cesty, která by je za normálních okolností nejprve pořádně ošetřila a sanitizovala.

A tady se obě chyby spojují. Route confusion v batch API otevře dveře, kterými do jinak chráněné cesty propašujete SQL injection z první zranitelnosti. Jenže tím to nekončí. Samotná SQL injection je totiž jen začátek podstatně delšího řetězce.

Od SQL injection ke správcovskému účtu

Kdyby zůstalo jen u SQL injection, byl by to vážný problém – únik dat, čtení citlivých informací z databáze – ale ještě ne úplná katastrofa. Skutečně nepříjemné je až to, co následuje.

Popsaný řetězec zneužívá interní mechanismy WordPressu, které spolu na první pohled vůbec nesouvisejí: cachování příspěvků, řádky v oEmbed cache, tzv. changesety (uchovávané verze změn například z Customizeru) a systém akčních hooků. Postupným zřetězením těchto komponent se z pouhé možnosti manipulovat s databázovými dotazy stane možnost založit v systému nový administrátorský účet.

A jakmile má útočník administrátorská práva, je zbytek už jen formalita – WordPress totiž adminovi legitimně umožňuje spoustu mocných věcí. Nejpřímočařejší cestou k RCE je nahrání pluginu: administrátor smí do WordPressu nahrát libovolný PHP kód v podobě pluginu a ten se pak spustí s oprávněními webového serveru.

V praxi to znamená, že úspěšné zneužití dává útočníkovi plnou administrátorskou kontrolu nad webem a schopnost spouštět kód s právy toho procesu, pod kterým běží PHP. Odtud je to k webshellu, zadním vrátkům, rozesílání spamu, přesměrování návštěvníků nebo šifrování dat už jen otázka toho, co si útočník usmyslí. Proto by se každé podezření na zneužití mělo brát jako kompletní kompromitace webu, ne jako dílčí incident.

Koho se to týká

Rozsah zranitelných verzí se u obou chyb mírně liší, což je detail, na kterém záleží víc, než by se zdálo.

• WordPress 7.0.x je zranitelný oběma chybami a je opraven ve verzi 7.0.2.
• WordPress 6.9.x je rovněž zranitelný oběma chybami a je opraven ve verzi 6.9.5.
• WordPress 6.8.x je zranitelný „jen“ SQL injection (ne route confusion v batch API) a je opraven ve verzi 6.8.6.
• Verze starší než 6.8 touto konkrétní dvojicí chyb zasaženy nejsou.

Praktický důsledek: pokud běžíte na větvi 6.9 nebo 7.0, jste vystaveni celému řetězci až po vzdálené spuštění kódu, a to je nejnaléhavější scénář. Pokud běžíte na 6.8, jste sice ušetřeni route confusion, ale SQL injection se vás týká pořád – a i tu je potřeba záplatovat bez otálení. „Jenom SQL injection“ totiž není důvod k oddechu; je to pořád neautentizovaný přístup k databázi.

Pokud tedy provozujete WordPress na některé z větví 6.8, 6.9 nebo 7.0, jediná rozumná reakce je okamžitě ověřit, že web už doběhl na příslušnou opravenou verzi.

Časová osa: mezi záplatou a zneužitím uběhly hodiny

Na wp2shell je znepokojivé nejen to, co umožňuje, ale i to, jak rychle se z akademického rozboru stala praktická hrozba. Časová osa mluví jasně:

17. července 2026 vydal bezpečnostní tým WordPressu verze 7.0.2, 6.9.5 a 6.8.6. Téhož dne publikoval Wordfence první varování a nasadil ochranu na úrovni firewallu svým placeným zákazníkům.

17. července 2026, 23:29 UTC – tedy prakticky ještě týž večer – byl v telemetrii firewallu zachycen první požadavek, který nesl podpis pokusu o zneužití batch endpointu REST API. Někdo už v tu chvíli testoval chování route confusion.

17. července 2026, 23:42 UTC, o pouhých třináct minut později, přišel první jasný pokus o SQL injection cílený přesně na zranitelné chování vyloučení autorů skrze batch endpoint.

18.–19. července 2026 už výzkumníci (a útočníci) reverzně analyzovali samotnou záplatu a začaly kolovat proof-of-concept exploity i nezávislé reprodukce chyby.

20. července 2026 zveřejnil Searchlight Cyber podrobný technický rozbor Adama Kuese včetně mechaniky celého řetězce a veřejného kontrolního nástroje na adrese wp2shell.com.

Ten interval mezi vydáním opravy a prvními pokusy o zneužití – počítaný v hodinách, ne dnech – je asi nejdůležitější poučení z celého případu. Vydání záplaty totiž zároveň funguje jako startovní výstřel: jakmile je oprava venku, útočníci ji mohou porovnat s předchozí verzí, z rozdílu odvodit podstatu chyby a zamířit na weby, které ještě nestihly aktualizovat. Kdo s aktualizací otálel, byl vystaven přesně v tom okně, kdy už veřejně kolovaly technické detaily a útočníci aktivně skenovali internet.

Co bylo vidět v datech o útocích

Po vyhodnocení provozu spojeného s firewallovým pravidlem pro wp2shell se ukázalo, že útočníci se nespokojili s tím, že by jen ověřovali existenci endpointu /wp-json/batch/v1. Objevily se požadavky, které se přímo pokoušely vyvolat chování route confusion, a krátce po nich požadavky s pokusy o SQL injection. Jinými slovy: nešlo o pouhé mapování terénu, ale o cílenou snahu projít celým řetězcem. Že je SQL injection ústředním prvkem cesty k RCE, se následně potvrdilo i vlastním testováním.

Firewall pomůže, ale nenahradí záplatu

Zákazníci Wordfence Premium, Care a Response dostali ochranu na úrovni firewallu už 17. července 2026, tedy v den zveřejnění. Uživatelé bezplatné verze Wordfence dostávají stejné pravidlo s obvyklým třicetidenním zpožděním, tedy 16. srpna 2026.

Tady je ale potřeba být upřímný: firewallové pravidlo není náhradou za aktualizaci jádra. Web Application Firewall dokáže snížit exploitovatelnost tím, že blokuje požadavky odpovídající známému vzoru útoku, ale útočníci vzory obcházejí a pravidla se dají obejít. Jediná skutečná náprava je dostat WordPress na opravenou verzi. Firewall berte jako přechodnou vrstvu, která vám kupuje čas, ne jako řešení.

Co udělat hned teď

Pokud spravujete WordPress web, tady je stručný postup, který má smysl projít okamžitě:

1. Ověřte verzi jádra WordPressu, na které web běží.
2. Aktualizujte na 6.8.6, 6.9.5 nebo 7.0.2 podle své větve.
3. Pokud běžíte na 6.9.x nebo 7.0.x, berte to jako obzvlášť naléhavé – tyto větve jsou zasaženy celým řetězcem až po RCE.
4. Zkontrolujte, že automatická aktualizace opravdu doběhla a nezasekla se na půli cesty.
5. Projděte seznam administrátorských účtů a hledejte uživatele, které jste tam nezakládali.
6. Zkontrolujte poslední nahrané pluginy a změny souborů – právě nahrání pluginu je typickou poslední fází útoku.
7. Web můžete prověřit veřejným kontrolním nástrojem na wp2shell.com.
8. Pokud máte Wordfence, projděte logy firewallu a hledejte blokované požadavky na /wp-json/batch/v1 nebo ?rest_route=/batch/v1.

Protože dopad může zahrnovat založení administrátora a spuštění kódu, jakékoli podezření na zneužití je namístě řešit jako plnou kompromitaci webu – tedy včetně obnovy z čisté zálohy, výměny hesel a klíčů a revize všeho, co na serveru běží.

Závěr: jádro je taky jen software

Roky jsme si zvykli, že bezpečnostní bolístky WordPressu jsou skoro vždycky „problém někoho jiného“ – nějakého pluginu, nějaké šablony, nějaké nadstavby. wp2shell je připomínkou, že ani jádro, jakkoli prověřené a spravované, není imunní. Software psaný lidmi obsahuje chyby a čím rozšířenější platforma, tím lákavější cíl a tím dražší každý přehlédnutý detail.

Poučení není nijak objevné, ale právě proto stojí za zopakování: aktualizujte rychle, mějte zapnuté automatické aktualizace, provozujte obranu do hloubky (firewall, princip nejmenších oprávnění, oddělení webu od databáze) a připravte si scénář pro případ, že se přesto něco stane – tedy funkční zálohy a jasný postup obnovy. U wp2shell rozhodovalo o osudu webu okno několika hodin. Weby, které měly zapnuté automatické aktualizace nebo je jejich správci projeli ručně ještě týž večer, byly v bezpečí. Ty ostatní se staly součástí statistiky.

A to je vlastně ta nejdůležitější věta celého případu: mezi „ohroženo“ a „v pořádku“ nebyl rozdíl v použité technologii ani v rozpočtu. Byl v tom, jak rychle se zareagovalo.

Zdroj: bezpečnostní analýza wp2shell od Wordfence; technický rozbor Adama Kuese, Assetnote / Searchlight Cyber. https://www.wordfence.com/blog/2026/07/wp2shell-aftermath-the-first-critical-unauthenticated-wordpress-core-rce-in-nearly-a-decade/