Klientka mi poslala zprávu:
„Podíval by ses mi prosím na web? Wordfence mi poslal hlášku, že se na webu změnil soubor wp-fixplugin.php. Není ten název podivnej?"
To sakra je.

Publikováno: 28. 8. 2026
Pustil jsem se do práce a za 3 hoďky web vyčistil. Během čištění jsem si dělal poznámky, abych se později s nahlédnutím do záloh pokusil zjistit, jak k napadení mohlo dojít.
Nejsem forenzní analytik, takže jsem podle svých možností a znalostí sestavil jednoduchou časovou osu napadení webu:
| Datum a čas | Událost |
|---|---|
| 16. 7. | WordPress běží na WP 6.9.1. |
| 17. 7. | WP komunita nachází dvě díry ve WP (viz níže). Obě jsou záplatovány vydáním WP 7.0.2. |
| 20. 7. v 06:17 | Na webu se objevuje admin účet “wpenginebot” |
| 24. 7. | Aktualizován WP na 7.0.2 (díra už zavřená, wpenginebot už je ale na webu) |
| 30. 7. v 00:12 | Vznik souborů (maskované jako pluginy): wordpress-cache-optimizer.php a wp-content-filter.php |
| 30. 7. v 02:04 | Přihlášení wpenginebot z 87.120.126.82 (Frankfurt, ale taky třeba jen VPN skrz Frankfurt) - útočník se vrací zkontrolovat/dokončit nasazení |
| 1. 8. | Někdy v té době se objevuje wp-fixplugin.php (mu-plugin) - dle záloh musel přibýt mezi 30. 7. a 1. 8. (smazal jsem ho bohužel dřív, než jsem si poznamenal datum, stejně tak infikované zálohy) |
Data sedí s bezpečnostní dírou objevenou pár dní předtím (první řádek tabulky). Šlo o vážnou díru v jádru WordPressu - typ zranitelnosti, kdy útočník nepotřebuje znát žádné heslo, prolomí se dovnitř přímo přes chybu v programu (tzv. RCE, remote code execution). Web pro ni byl v tu dobu otevřený. Okno mezi zveřejněním záplaty a klientovou aktualizací je přesně čas, kdy útočník poprvé udeřil.
A teď podrobněji o tom, co se na webu dělo.
Mu-pluginy mají ve WP speciální místo. Jsou to kousky kódu, který se spouští přednostně před ostatními pluginy a v administraci WP nejsou vidět.
Jeden takový, pojmenovaný wp-fixplugin.php (ten, který zachytil Wordfence, jak psala klientka) vkládal do stránky kód (java script), co se snažil tvářit jako Google Tag Manager.
Chyba lávky, na webu se používá cookiless analytika od Koko (víc o ní v článku Měříš návštěvnost webu? Vyzkoušel jsem čtyři nástroje najednou - tady jsou výsledky). Navíc v kódu komunikoval s úplně jiným serverem, než tím googlím.
A dělal to chytře - do stránek se vkládal jen návštěvníkům, ne přihlášeným adminům, aby to nikdo z majitelů webu neviděl na vlastní oči.
Navíc měl vlastní vzdálené API umožňující obsah java scriptu upravovat a nebo rovnou celý backdoor smazat. Jinými slovy: útočník si nechal servisní dvířka do svého vlastního malwaru, aby ho mohl aktualizovat. Fifák!
Ukázalo se, že infekce je v zálohách i tři týdny dozadu. Posunout web měsíc zpět je pro web s blogem a různými kurzy dost. Vyhodnotil jsem, že bude jednodušší web pročistit, než pracně prohledávat obsahové změny (a zase ho otevírat zranitelnostem).
Napadlo mě, jestli web není infikovaný tím backdoorem ze 17.7. Ten se má projevovat nejprve vytvořením cizího admin účtu. A fakt tam byl - navíc pojmenovaný, aby nebylo pochyb: wpenginebot .
Smazal jsem ho, do minuty se účet objevil znova. Ve Wordfence jsem v historii přihlášení našel data posledních úspěšných přihlášení účtu. Dle IP adresy se bot připojoval z Frankfurtu (což samozřejmě nemusí znamenat nic, VPN že jo).
Běžně začínám změnou hesel (databáze, FTP, WordPress). Tady jsem měnil jen FTP a databázi - útočník (je jedno jestli člověk nebo bot) se připojoval přes admin účet, který si sám vytvořil a navíc ho uměl automaticky obnovovat.
V konfiguraci WP (soubor wp-config.php) byly přidány řádky na povolení spouštění kódu ze složky /wp-content/uploads, to je složka, kde jsou uloženy obrázky a nemá práva na spouštění kódu. Jakmile je na webu něco takového, něco se děje (i kdyby předchozí stopy nebyly).
Mezi nainstalovanými pluginy jsem našel jeden s neškodným názvem - "WordPress Cache Optimizer". Za prvé jsem ho neznal, zadruhé mi přišla zvláštní jeho verze: 1.0.0. Podezíral jsem ho, že je to nějaký opuštěný plugin. Ale ne.
Ten "cache optimizer" neoptimalizoval vůbec nic. Optimalizoval akorát tak přidání dalšího skrytého admin účtu wphiddenbot a to tak, že nebyl vidět v administraci. Po otevření databáze se to potvrdilo.
Přímo v kódu bylo napsané heslo k tomu skrytému admin účtu. Útočník, co si dal se skrýváním takovou práci, nechal klíč pro další zlobry pod rohožkou.
Taky používal skript, který se sám prohlásil za "Site Health Cleanup". V reálu kontroloval seznam adminů - asi právě kvůli tomu, aby si mohl obnovovat admin účty po jejich smazání.
Po smazání účtu vetřelce z administrace a druhého (skrytého) z databáze se už účet neobnovil.
Zrekapitulujme si to. Pluginy a soubory s infekcí byly:
Dočištění vypadalo následovně:
wp-config.php, aby útočníkovi přestaly platit případné ukradené přihlašovací cookies.wp-content/uploads jestli neobsahují spustitelný kód.Nespoléhej jen na seznam uživatelů v adminu - pokud web napadl šikula, může ho aktivně schovávat. Pomůže pohled do databáze (tabulka wp_users):SELECT ID, user_login, user_email, user_registered FROM wp_users;
Must-use plugin je speciální složka pro pluginy, kterou WordPress spustí ještě před klasickými pluginy. Mu-pluginy nejsou zobrazeny v seznamu pluginů. Nejdou vypnout kliknutím, jen smazáním souboru - pro útočníka ideální schovávačka.
Hlavní konfigurační soubor WordPressu - obsahuje přístup k databázi, bezpečnostní klíče ("soli") a základní nastavení, bez kterých web vůbec nenaběhne.
Složka /wp-content/uploads je určená na obrázky a jiná média, ne na spouštění kódu. Na to má WP spoustu jiných míst. Pokud do wp-content/uploads někdo tuhle možnost přidal, značí to, že si připravil půdičku pro škodlivé soubory, které nebudou ovlivňované aktualizacemi pluginů a samotného jádra WP. Tahle úprava sama o sobě je silný signál, že se na webu něco děje.
Všechny změny ve WordPressu jsou zveřejňované (nejen ve WP, platí to pro jakýkoliv software). To nesledují jen vývojáři, ale taky zlouni, kteří je dostávají na zlatém podnose. U vážných zranitelností (typu RCE, kdy útočník nepotřebuje znalost žádného hesla) začnou automatizované skripty (a dneska už i LLM agenti) skenovat internet už během několika hodin až dnů od zveřejnění záplaty. Neaktualizované weby jsou nízkoležící ovoce, stačí utrhnout.
Well, it depends. Máš pravdu, že pokud nejseš nějaká celebrita, která se dá vydírat (nebo jen chlubit v komunitě, žes hacknul toho a tuhle) tak nejde o data.
Ve tvém případě jde spíš o tohle:
Jo a ne. Vyplatí se mít zapnuté automatické aktualizace jádra pro bezpečnostní opravy:define( 'WP_AUTO_UPDATE_CORE', 'minor' );
Větší vydání nových verzí WP dělám raději ručně - tím mě nepřekvapí nekompatibility pluginů nebo spadlý web. Páč se fakt nechceš připojit v pondělí k e-mailu a řešit, že ti kvůli neprošlé aktualizaci od páteční jedenácté nejede web.
Cti pravidlo: pokud plugin nepoužíváš, smaž ho. To stejné s WordPress tématy. Pokud nevíš, co plugin dělá, googli nebo použij chatbota.
Pokud měl útočník přístup k zápisu na disk, viděl pravděpodobně všechno, co jsi tam měl/a - včetně přihlašovacích údajů k databázi. Smazáním účtu ve WP zlobra jen vyhodíš z jedněch dveří. Klíče od ostatních mu zůstávají, dokud hesla nezměníš všude.
Pokud nevíš, kudy se na web dostal, změň všechna hesla a nezapomeň přegenerovat "sůl" ve wp-config.
wp2shell je označení pro řetězec dvou WordPress zranitelností ze 17. 7. 2026 označených jako CVE-2026-60137 a CVE-2026-63030.
Pro útok jsou potřeba obě díry, fungují v návaznosti na sebe:
1. První chyba udělá v hlavních dveřích webu díru, kterou se dá nakouknout dovnitř bez hesla.
2. Druhá chyba skrz díru dokáže vytvořit admin účet.
Postižené byly verze WordPressu:
Opravy děr vyšly ve verzích:
vydaných 17. 7. 2026.
Rád ti pomůžu web odčervit.

Měsíční newsletter pro majitele webů, kteří chtějí, aby jejich WordPress spolehlivě fungoval.
Dozvíš se:
🔌 Tipy na užitečné pluginy a nástroje.
🆕 Novinky z WordPress světa.
💡 Praktické návody a rady.