Naše weby vznikají s důrazem na , funkčnost a čistý design.
Každý projekt bereme jako příležitost vytvořit něco, co vám bude skutečně sloužit.
Útoky na WordPress se dávno neodehrávají tak, jak si je většina majitelů webů představuje. Nikdo vás nehackuje. Vás jen našel skener. A od chvíle, kdy vyjde nová zranitelnost, běží hodiny — ne dny. Tenhle text je technický průvodce po tom, kde se WordPress reálně láme, proč většina „bezpečnostních“ opatření nefunguje, a co s tím dělat.
Začněme čísly, protože ta mění celou strategii obrany. Podle výroční zprávy Patchstack State of WordPress Security in 2026 přibylo za rok 2025 v ekosystému WordPressu 11 334 nových zranitelností, což je meziroční nárůst o 42 procent. Z nich 91 procent připadlo na pluginy a 9 procent na šablony. V samotném jádře WordPressu byla nahlášena jen šestice zranitelností — a všechny s nízkou prioritou.
To je zásadní posun v uvažování. Jádro WordPressu je po dvou dekádách veřejného auditu, s vlastním bezpečnostním týmem a vynucovanými automatickými aktualizacemi, jednou z lépe udržovaných částí vaší infrastruktury. Když v červenci 2026 vyšla verze 7.0.2 s jednou kritickou a jednou vysoce závažnou chybou, WordPress.org rovnou zapnul vynucené aktualizace pro zasažené instalace. Následovaly verze 7.0.3 a 7.0.4 v odstupu několika dní. Systém funguje.
Co nefunguje, je zbytek. Průměrný firemní web má dvacet až čtyřicet pluginů, které běží se stejnými právy jako jádro, mají plný přístup k databázi i k souborovému systému — a jejich autoři nemají bezpečnostní tým. Podle stejné zprávy 46 procent nahlášených zranitelností nedostalo opravu do doby veřejného zveřejnění. Rada „aktualizujte pluginy“ tedy v polovině případů nemá co aplikovat.
A pak je tu časová osa. Patchstack měřil, za jak dlouho po zveřejnění zranitelnosti přijde první reálný pokus o zneužití. Zhruba polovina vysoce dopadových chyb je zneužita do 24 hodin. U těch nejmasověji atakovaných je vážený medián pět hodin. Pět hodin od zveřejnění do okamžiku, kdy vám na web klepe automatizovaný exploit.
Nikdo nestihne během pěti hodin ručně otestovat aktualizaci na stagingu.
Nejčastěji zneužívanou kategorií zranitelností je podle stejné analýzy broken access control — česky nejlépe „chybějící kontrola oprávnění“. A je to kategorie, proti které jsou tradiční aplikační firewally z principu skoro slepé.
Typický WAF hledá vzory: uvozovku a klíčové slovo UNION SELECT v parametru, značku script v odeslaných datech, sekvenci teček a lomítek v cestě k souboru. Chybějící kontrola oprávnění ale žádný podezřelý vzor nemá. Vypadá jako naprosto legitimní požadavek.
Vzorec, který se v pluginech opakuje s únavnou pravidelností, vypadá takhle. Plugin zaregistruje obslužnou funkci pro AJAX požadavek, aby si administrátor mohl uložit nastavení. K tomu ji ale zaregistruje i variantou určenou pro nepřihlášené návštěvníky — tou s předponou wp_ajax_nopriv. Uvnitř funkce chybí kontrola oprávnění přes current_user_can a chybí i ověření bezpečnostního tokenu (nonce). Výsledkem je, že kdokoli může poslat obyčejný požadavek na wp-admin/admin-ajax.php a přepsat nastavení webu — u řady pluginů včetně adresy pro přesměrování návštěvníků nebo role, kterou dostane nově registrovaný uživatel.
Žádná injekce, žádný podezřelý řetězec. Pro firewall to je běžný provoz od běžného klienta.
Jak moc jsou na tom hostingy špatně, Patchstack změřil penetračními testy napříč poskytovateli: standardní kombinace hostingových firewallů a Cloudflare zablokovala jen 12 procent útoků cílených na známé zneužívané zranitelnosti WordPressu. Při širším vzorku včetně obecnějších zranitelností to bylo 26 procent.
Jinými slovy: pokud vaše bezpečnostní strategie stojí na tom, že „hosting to nějak řeší“, stojí na třech čtvrtinách děravé podlahy.
Útok probíhá ve čtyřech fázích a žádná z nich není osobní.
1. Průzkum. Bot projde web, vytáhne z HTML seznam načítaných skriptů a stylů a z cest k nim si sestaví soupis nainstalovaných komponent. Verzi pluginu si dohledá v souboru readme.txt, který drtivá většina rozšíření nechává veřejně dostupný v adresáři pluginu.
2. Zneužití. Následuje slepá salva exploitů. Bot netestuje, jestli jste zranitelní — je levnější poslat požadavek a podívat se na odpověď. Zajímavý detail ze zprávy: mezi deseti nejčastěji atakovanými zranitelnostmi roku 2025 byly jen čtyři zveřejněné v roce 2025. Zbytek byly staré známé díry z let 2023 a 2024, u kterých útočníci spoléhají na to, že někde pořád běží neaktualizovaná verze. A mají pravdu, jinak by to nedělali.
3. Perzistence. Tady se za poslední rok změnilo nejvíc. Data od Monarx, která zprávu doplňují, ukazují posun od odkládání samostatných škodlivých souborů k injektáži kódu přímo do legitimních souborů jádra, pluginů a šablon. Automatická logika typu „smaž podezřelý soubor“ na tohle nestačí — musíte vloženou část chirurgicky odstranit. Zároveň skoro zdvojnásobil objem takzvaných uploaderů, malých skriptů, jejichž jediným úkolem je udržet útočníkovi cestu zpátky. Rodina Lock360 jde ještě dál a drží se rezidentně v paměti serveru: jakmile obnovíte čistý index.php nebo .htaccess, malware ho během chvíle přepíše zpět.
4. Monetizace. SEO spam, přesměrování, phishing, odchytávání platebních karet ve WooCommerce. A protože moderní kampaně používají takzvaný cloaking — vyhodnocují, kdo je na druhé straně —, vy jako přihlášený administrátor vidíte čistý web, vyhledávací robot vidí spam napěchovaný klíčovými slovy a náhodný návštěvník z mobilu skončí na podvodné stránce. Varianty Parrot TDS už umí rozpoznat i crawlery jazykových modelů a servírovat jim neškodný obsah. Infekce se tak často pozná až podle propadu v pozicích ve vyhledávání nebo podle stížnosti zákazníka.
Nejméně příjemný důsledek: mezi kompromitací a jejím objevením běžně uplynou týdny. Tomu musí odpovídat i retence záloh.
Každý plugin je nezávislý dodavatel s neomezenými právy nad vaší aplikací. Udělejte si audit a nemilosrdně mažte — v administraci přes stránku Pluginy a filtr Neaktivní, nebo hromadně přes WP-CLI.
Deaktivovaný plugin není neškodný — jeho soubory zůstávají na disku a řada zranitelností je zneužitelná přímým zavoláním konkrétního souboru bez ohledu na to, jestli je plugin aktivní. Deaktivace není odinstalace.
U toho, co zůstane, se dívejte na datum poslední aktualizace, počet aktivních instalací a na to, jestli má vývojář zavedený program pro hlášení zranitelností (VDP). Od roku 2026 ho podle evropského nařízení Cyber Resilience Act budou komerční pluginy potřebovat, aby je vůbec směly nabízet evropským uživatelům — nemít ho je čím dál silnější varovný signál.
Ještě poznámka k prémiovým rozšířením: zpráva zjistila, že u placených komponent, typicky z tržišť jako Envato, bylo 76 procent nalezených zranitelností reálně zneužitelných a měly třikrát více prokazatelně zneužívaných chyb než bezplatné pluginy. Zaplacení licence není bezpečnostní opatření — jen znamená, že se na kód dívá méně nezávislých očí.
Pět hodin je méně, než trvá schvalovací proces. Menší a bezpečnostní aktualizace jádra nechte běžet automaticky, velké verze držte pod kontrolou — v konfiguračním souboru wp-config.php k tomu slouží konstanta WP_AUTO_UPDATE_CORE nastavená na hodnotu minor.
U pluginů zapněte automatické aktualizace u těch, které jsou vystavené internetu a mají historii rychlých oprav: formuláře, cache, SEO, platební brány. Ruční režim ponechte u těch, na kterých stojí vzhled nebo kritická logika. Do stejné vrstvy patří i virtuální patching od služeb typu Patchstack nebo Wordfence, který nasadí ochranné pravidlo v okamžiku zveřejnění zranitelnosti — právě proto, že v 46 procentech případů žádná oprava od autora zatím neexistuje.
Buďme přitom upřímní: automatické aktualizace mají odvrácenou stranu. Kompromitovaný účet vývojáře nebo předání pluginu novému „správci“ znamená, že si backdoor natáhnete sami, dobrovolně, v noci a bez kontroly. Je to reálné riziko dodavatelského řetězce a odpověď na něj není aktualizace vypnout — statisticky prohrajete —, ale zmenšit počet dodavatelů, sledovat změny vlastnictví u kritických pluginů a mít monitoring integrity, který podezřelou změnu odhalí bez ohledu na to, jestli přišla od útočníka, nebo z oficiálního repozitáře.
Jednotlivě nejúčinnější opatření proti webshellům. Nahrání souboru se tím nezabrání, ale jeho spuštění ano — a právě spuštění dělá z nahraného obrázku backdoor.
Na nginx vytvořte pro adresář wp-content/uploads samostatný blok location a dovnitř vnořte pravidlo, které zakáže přístup ke všem souborům s příponou php, phtml, phar a číslovanými variantami typu php7 nebo php8. Na Apachi stačí do stejného adresáře vložit soubor .htaccess s direktivou FilesMatch se stejným výčtem přípon. Pozor na velikost písmen — pravidlo musí být necitlivé na velikost, jinak ho obejde přípona zapsaná jako PhP.
Totéž zvažte pro adresář s cache. Legitimní plugin nemá důvod spouštět PHP z adresáře určeného pro média.
Když už útočník získá administrátorský účet, vestavěný editor souborů je pro něj přímá cesta ke spuštění kódu — stačí přidat jeden řádek do šablony. V konfiguračním souboru proto zapněte konstantu DISALLOW_FILE_EDIT, která editor šablon i pluginů kompletně vypne. Ve stejném kroku si zapněte vynucené HTTPS pro administraci konstantou FORCE_SSL_ADMIN a ujistěte se, že ladicí výpisy nikdy nekončí ve výstupu stránky.
Ostřejší varianta, konstanta DISALLOW_FILE_MODS, zakáže veškerou instalaci a aktualizaci z administrace — dává smysl jen tam, kde nasazujete přes Git. Souborová práva držte na 644 pro soubory a 755 pro adresáře, konfigurační soubor na 640, a kořen webu nesmí být zapisovatelný uživatelem, pod kterým běží PHP.
Dvoufaktorové ověření nasaďte pro všechny účty s právem editace, nejen pro administrátory — z účtu editora vede eskalace často jediným krokem. Dál omezte počet pokusů o přihlášení a přihlašovací stránku ošetřete omezením rychlosti požadavků na úrovni serveru, ne až pluginem, který se stejně načte až po startu celého WordPressu.
Nezapomeňte na aplikační hesla v profilu uživatele: jsou to plnohodnotné přístupy k REST API, dvoufaktorové ověření na ně neplatí a nikdo si na ně nevzpomene. Projděte je a nepoužívané zrušte.
Pokud nepoužíváte mobilní aplikaci ani Jetpack, zavřete rozhraní XML-RPC. Je to legitimní endpoint, ale ideální nástroj pro hromadné hádání hesel, protože umožňuje desítky pokusů v jediném požadavku. Na úrovni webserveru je to jedno pravidlo, které zakáže přístup k souboru xmlrpc.php.
Projděte si administrátorské účty. Bývá jich víc, než čekáte — bývalý dodavatel, testovací účet, integrace, která „to potřebovala“. Vypište si je i s datem registrace: nově vytvořený administrátor s datem, které si nepamatujete, je klasický artefakt útoku a bývá to první viditelná stopa.
K tomu nasaďte záznam aktivit, ať už pluginem typu WP Activity Log nebo Simple History, a odesílejte ho pryč ze serveru. Log, který útočník může smazat, není důkaz.
Protože se dnes škodlivý kód injektuje do legitimních souborů, hledejte odchylky proti originálu. WP-CLI umí porovnat kontrolní součty jádra i všech pluginů proti oficiálnímu repozitáři — jsou to dva příkazy a měly by běžet pravidelně, ideálně automaticky.
Při podezření se vyplatí i ruční pohled: vypište si všechny PHP soubory v adresáři wp-content změněné za posledních sedm dní a seřaďte je podle data. Nezapomeňte na adresář mu-plugins, který se načítá vždy a nejde deaktivovat z administrace, a na naplánované úlohy WordPressu — backdoor, který se sám pravidelně obnovuje, tam bývá vidět jako neznámá událost.
Pravidlo tři kopie, dvě média, jedna mimo lokalitu. K tomu verzování nebo neměnné úložiště, jinak vám útočník smaže i zálohy. Klíčový a přehlížený parametr je retence: když se infekce projeví po šesti týdnech, sedmidenní záloha je vám k ničemu, protože už obsahuje backdoor. Držte alespoň 30 až 60 dní zpátky.
A jednou za čtvrtletí zkuste skutečnou obnovu do testovacího prostředí. Statistika úspěšnosti neověřených záloh je deprimující.
Aplikační hardening vám nepomůže, pokud pod ním leží špatně postavený server. Tři body s největším dopadem:
Aktuální PHP. WordPress 7.0 sice formálně podporuje ještě PHP 7.4, ale ta má konec podpory od konce roku 2022 a bezpečnostní opravy nedostává. Držte se verze 8.2 a vyšší.
Izolace. Na sdíleném hostingu s jedním systémovým uživatelem pro všechny weby platí, že kompromitace toho nejzanedbanějšího znamená kompromitaci všech ostatních. Každý web má mít vlastního systémového uživatele a vlastní PHP proces. Tohle je otázka na poskytovatele hostingu, ne na vás — ale je to otázka, kterou byste mu měli položit.
Odchozí provoz. Většina malwaru potřebuje kontaktovat řídicí server, stáhnout druhou fázi nebo odeslat data. Omezení odchozích spojení z PHP je jedno z mála opatření, které funguje ještě poté, co útočník uspěl.
Několik rad koluje internetem tak dlouho, že se z nich stalo dogma. Většinou jde o opatření, která zvyšují pocit bezpečí a nulově snižují riziko.
Skrývání verze WordPressu z hlavičky stránky. Bot verzi nezjišťuje. Pošle exploit naslepo a vyhodnotí odpověď — je to levnější než pečlivé zjišťování verzí.
Přejmenování administrace nebo přesun přihlašovací stránky. Zdrží skriptované hádání hesel, ale proti zranitelnostem v pluginech, které se zneužívají přes AJAX rozhraní nebo REST API, nedělá vůbec nic.
Změna prefixu databázových tabulek na existujícím webu. Marginální přínos u úzké podmnožiny slepých SQL injekcí, výměnou za reálné riziko rozbití serializovaných dat v nastavení a metadatech.
Skrytí uživatelských jmen přes REST API. Rozumné jako drobná hygiena, ale pokud máte dvoufaktorové ověření a limit pokusů, útočníkovi seznam jmen nepomůže.
Nic z toho není škodlivé. Problém nastává, když to někdo považuje za hotovou práci.
Postup, který má smysl, v tomhle pořadí:
Nejdřív snímek, potom úklid. Udělejte kopii souborů i databáze v infikovaném stavu. Bez ní nezjistíte vstupní bod a za dva týdny budete čistit znovu.
Web do údržbového režimu, ať nešíříte malware návštěvníkům a nesbíráte zápis na blacklisty.
Rotace všech tajemství. Hesla uživatelů, bezpečnostní klíče v konfiguračním souboru (jejich změna zneplatní všechny existující přihlášené relace), přístup k databázi, klíče pro FTP a SSH, API klíče plateb a integrací.
Najděte vstupní bod. Bez toho je čištění jen odklad. Logy webserveru kolem času nejstaršího podezřelého souboru, korelace s verzemi pluginů a známými zranitelnostmi.
Nespoléhejte na mazání souborů. Rezidentní malware přepíše obnovené soubory během minut. Bezpečnější je nasadit jádro, pluginy a šablony znovu z čistých zdrojů a přenést zpátky jen databázi a nahrané soubory — po kontrole.
Sledujte web ještě měsíc. Kontrolujte Search Console, nově vytvořené uživatele, naplánované úlohy a odchozí spojení.
Shrnuto do jedné věty: WordPress není nebezpečný, nebezpečná je neudržovaná instalace s třiceti pluginy od dvaceti různých autorů, hostovaná na sdíleném serveru bez izolace.
Data z posledního roku říkají tři věci celkem jasně. Riziko je téměř výhradně v rozšířeních, nikoli v jádře. Reakční doba se zkrátila na hodiny, takže manuální procesy nestačí a automatizace přestala být luxusem. A obrana postavená na detekci až po kompromitaci selhává, protože moderní malware je navržený tak, aby ho detekce neviděla.
Nejlepší návratnost má paradoxně to nejnudnější: méně pluginů, zapnuté automatické aktualizace, zakázané spouštění PHP v adresáři s nahranými soubory, dvoufaktorové ověření a záloha, kterou jste skutečně vyzkoušeli obnovit. Zbytek je jemné doladění.
Zdroje dat: Patchstack a Monarx, State of WordPress Security in 2026; oznámení bezpečnostních vydání na WordPress.org (verze 7.0.2 až 7.0.4, 2026).
zpět
Ing. David Pavelka
Čapkova 322
582 91 Světlá nad Sázavou
IČ 87496828 | DIČ CZ8605173269
+420 560 550 879
info@dpavelka.cz