Zapnuté automatické aktualizace jsou jedna z prvních věcí, které doporučuji u WordPressu nastavit. Aktualizovaný web je téměř vždy bezpečnější než web, na kterém několik měsíců nikdo neotevřel administraci.
Automatické aktualizace ale nejsou bezpečnostní strategie. Jsou pouze jednou její částí.
V praxi totiž existuje důležitý časový úsek mezi okamžikem, kdy je v pluginu nebo samotném WordPressu objevena bezpečnostní chyba, vydáním opravy, její instalací a následnou kontrolou webu.
A právě poslední krok se velmi často vynechává.
Plugin hlásí aktuální verzi. WordPress také. Na první pohled je tedy všechno v pořádku.
Jenže aktualizace opravuje zranitelnost. Neodpovídá na otázku, zda ji někdo nestihl využít ještě před aktualizací.
Srpen 2026 ukázal, jak rychle se situace může měnit
Dobrým příkladem byl letošní srpen.
Samotný WordPress vydal během šesti dnů dvě bezpečnostní aktualizace. WordPress 7.0.3 vyšel 6. srpna a řešil několik bezpečnostních problémů, mezi nimi například XSS na přihlašovací obrazovce s potenciálem vést až ke spuštění PHP kódu nebo problém typu SSRF. O šest dní později, 12. srpna, následoval WordPress 7.0.4 s další bezpečnostní opravou týkající se možnosti vzdáleného spuštění kódu za určitých podmínek.
Podobně živá je situace u pluginů. Databáze Wordfence například na konci srpna evidovala nové zranitelnosti Forminatoru, TranslatePressu, LiteSpeed Cache a řady dalších rozšíření.
Zvlášť názorný byl případ TranslatePressu. Bezpečnostní chyba byla Wordfence nahlášena 11. srpna, 12. srpna byla potvrzena a předána vývojářům a 13. srpna již existovala opravená verze 3.3.2. Za určitých podmínek přitom chyba umožňovala nepřihlášenému útočníkovi získat odkaz pro reset hesla administrátora a převzít jeho účet.
Vývojář tedy zareagoval velmi rychle.
Přesto je na tomto příkladu dobře vidět, proč zabezpečení WordPressu nelze zredukovat na zelenou ikonku „vše je aktuální“.
Bezpečnostní problém má vlastní časovou osu
Představme si jednoduchou situaci:
1. V pluginu existuje zranitelnost.
Provozovatel webu o ní zatím nemusí vůbec vědět.
2. Chybu někdo objeví.
Může to být bezpečnostní výzkumník, vývojář, ale teoreticky také útočník.
3. Vývojář připraví opravu.
4. Vyjde nová verze pluginu.
5. WordPress ji automaticky nainstaluje.
V tomto okamžiku máme aktuální plugin.
To je dobrá zpráva.
Jenže mezi body 1 a 5 mohl být web určitou dobu zranitelný. A pokud už někdo chybu využil například k vytvoření administrátorského účtu, vložení škodlivého souboru nebo úpravě databáze, samotná aktualizace tento problém nemusí odstranit.
Aktualizací zavřeme dveře. Nezjistíme tím ale automaticky, jestli jimi už předtím někdo neprošel.
Opravený plugin neznamená automaticky čistý web
S tímto rozdílem se setkávám i při čištění napadených WordPress webů.
Samotný původní bezpečnostní problém už může být dávno opravený. Všechny pluginy mohou být aktuální a bezpečnostní mezera, kterou se útočník původně dostal dovnitř, už vůbec nemusí existovat.
Na serveru ale mohou zůstat například:
- neznámé PHP soubory,
- upravené systémové soubory WordPressu,
- škodlivý kód vložený do existujícího pluginu nebo šablony,
- nový administrátorský účet,
- změny v databázi,
- přesměrování návštěvníků,
- backdoor umožňující útočníkovi návrat.
A právě proto při podezření na napadení nestačí otevřít administraci, kliknout na „Aktualizovat vše“ a považovat problém za vyřešený.
Známá zranitelnost se rychle mění v praktický návod k útoku
Zveřejnění bezpečnostní chyby má ještě jeden důležitý efekt.
Jakmile jsou dostupné podrobnosti o zranitelnosti, je mnohem jednodušší hledat weby, které používají postiženou verzi pluginu. Útočník nemusí konkrétní firmu znát ani si její web předem vybrat.
Velká část útoků na WordPress není osobní.
Automatizované nástroje jednoduše procházejí velké množství webů a hledají známé slabiny.
Proto může být rozdíl mezi aktualizací dnes a aktualizací za tři týdny podstatnější, než se na první pohled zdá.
Co tedy kontrolovat kromě aktualizací?
Dobrá správa WordPress webu by měla kombinovat několik vrstev ochrany.
Základem jsou samozřejmě pravidelné aktualizace. Týká se to WordPressu, pluginů i šablon. Současně je dobré sledovat, zda některé používané rozšíření nemá aktuálně známou závažnou zranitelnost.
Druhou vrstvou jsou zálohy. Ideálně automatické, pravidelné a uložené mimo samotný webhosting. Záloha ze stejného serveru nemusí při vážnějším incidentu stačit.
Další důležitou vrstvou je kontrola změn souborů. Bezpečnostní nástroje, například Wordfence, mohou upozornit na změněné systémové soubory nebo podezřelé soubory, které do běžné instalace WordPressu nepatří.
Vyplatí se také občas zkontrolovat uživatelské účty a administrátory. Na webu by neměl existovat účet s vysokým oprávněním, o kterém nikdo neví.
A pokud máme podezření na incident, přicházejí na řadu také serverové a bezpečnostní logy. Ty mohou pomoci určit, co se na webu skutečně odehrálo.
Automatické aktualizace mají ještě jeden háček
Bezhlavé zapnutí automatických aktualizací úplně všeho má i druhou stránku.
Aktualizace může opravit bezpečnostní problém, ale současně způsobit konflikt s jiným pluginem, šablonou nebo vlastními úpravami webu.
U jednoduchého prezentačního webu může být riziko malé. U rozsáhlejšího WooCommerce e-shopu, členského webu nebo webu s desítkami pluginů už bych byl opatrnější.
Proto u důležitějších projektů dává smysl kombinovat rychlost bezpečnostních aktualizací s kontrolovaným nasazením.
Ideální postup je:
záloha → staging → aktualizace → základní test → produkční web → kontrola.
U kritické bezpečnostní aktualizace samozřejmě nechceme několik dní testovat každý detail. Staging ale umožňuje velmi rychle zjistit alespoň to, zda aktualizace nerozbila nákupní proces, formuláře, přihlášení nebo jinou zásadní funkci.
Jak může vypadat minimální měsíční bezpečnostní rutina
Pro menší firemní WordPress nemusí pravidelná správa znamenat hodiny práce každý týden.
Rozumné minimum může jednou měsíčně zahrnovat kontrolu:
- verze WordPressu, pluginů a šablon,
- známých zranitelností používaných komponent,
- výsledků bezpečnostního scanu,
- změněných nebo podezřelých souborů,
- administrátorských účtů,
- funkčnosti záloh,
- základních funkcí webu po aktualizacích.
U aktivního e-shopu nebo webu, který je pro firmu obchodně důležitý, je samozřejmě vhodná častější kontrola.
Důležité ale je, že někdo skutečně ověřuje výsledek.
„Web se aktualizuje sám“ a „web je spravovaný“ nejsou totéž
Automatické aktualizace jsou skvělá funkce WordPressu a rozhodně bych je nezavrhoval. Naopak mohou výrazně zkrátit dobu, po kterou web používá starou zranitelnou verzi.
Jen od nich není dobré očekávat něco, co neumějí.
Nezkontrolují za nás, zda se aktualizace povedla. Neotestují všechny důležité funkce webu. Nevyhodnotí neobvyklé změny. A především nám samy o sobě nepotvrdí, že web nebyl napaden ještě před instalací bezpečnostní opravy.
Skutečná správa WordPress webu proto není jen proces aktualizování softwaru. Je to průběžná kontrola jeho stavu.
A právě v tom je podle mě největší rozdíl mezi webem, který se pouze „nějak udržuje aktuální“, a webem, o který se někdo skutečně stará.