Hosting informuje o podejrzanych plikach, strona zaczyna przekierowywać użytkowników na obcą domenę albo w wynikach Google pojawiają się podstrony, których nikt nie utworzył. Pierwszą reakcją jest zwykle zmiana hasła administratora, instalacja wtyczki bezpieczeństwa i aktualizacja wszystkiego, co pokazuje WordPress.
Każde z tych działań ma sens, ale niekoniecznie usuwa przyczynę włamania. Atakujący często nie potrzebuje dostępu do panelu administracyjnego. Wystarczy podatność w jednej z zainstalowanych wtyczek, która pozwala wykonać określoną operację bez uwierzytelnienia.
Dlatego bezpieczeństwo WordPressa nie powinno sprowadzać się do silnego hasła i aktualizacji wykonywanych raz w miesiącu. Trzeba również wiedzieć, jakie wersje komponentów działają na produkcji i czy nie pojawiła się dla nich nowa podatność wymagająca szybkiej reakcji.
Większość podatności WordPressa znajduje się we wtyczkach
Rdzeń WordPressa jest tylko częścią całego środowiska. Typowa strona korzysta dodatkowo z kilkunastu lub kilkudziesięciu wtyczek, motywu, a czasami również własnego kodu przygotowanego specjalnie dla danego serwisu.
Według raportu Patchstack State of WordPress Security in 2026 w 2025 roku zgłoszono 11 334 nowe podatności w ekosystemie WordPressa, czyli o 42% więcej niż rok wcześniej. 91% dotyczyło wtyczek, 9% motywów, natomiast w samym rdzeniu WordPressa zgłoszono sześć podatności zakwalifikowanych jako niskopriorytetowe.
Jeszcze istotniejsze jest to, że 46% podatności nie miało dostępnej poprawki w momencie publicznego ujawnienia. Samo regularne instalowanie aktualizacji nie wystarcza więc do utrzymania bezpieczeństwa strony. W niektórych przypadkach podatność jest już znana, ale poprawiona wersja wtyczki jeszcze nie istnieje.
W takiej sytuacji trzeba ocenić znaczenie podatności dla konkretnej strony. Czasami wystarczy ograniczyć podatną funkcję, w innym przypadku można zastosować odpowiednią regułę WAF, a przy poważniejszych błędach konieczne może być tymczasowe wyłączenie lub zastąpienie całej wtyczki.
Silne hasło nie zabezpieczy podatnej wtyczki
Silne i unikalne hasło oraz uwierzytelnianie dwuskładnikowe powinny być standardem dla kont administracyjnych. Chronią przede wszystkim przed przejęciem konta i nieuprawnionym logowaniem.
Nie zabezpieczają jednak przed podatnością, którą można wykorzystać bez logowania. Jeżeli błąd znajduje się na przykład w publicznym formularzu, endpointcie REST API albo funkcji dostępnej dla niezalogowanych użytkowników, atakujący może w ogóle nie korzystać z ekranu logowania WordPressa.
Im więcej dodatkowego kodu działa w serwisie, tym większa jest powierzchnia, którą trzeba kontrolować. Jest to szczególnie widoczne w WooCommerce, gdzie poza samym sklepem działają zwykle integracje płatności, dostaw, systemów magazynowych, marketing automation, faktur, feedów produktowych i innych usług.
Aktualizowanie WordPressa raz w miesiącu już nie wystarcza
Regularne okna serwisowe nadal są potrzebne. Można podczas nich wykonywać aktualizacje, testy, przegląd logów, kontrolę kopii zapasowych i porządkować nieużywane komponenty. Problem pojawia się wtedy, gdy taki przegląd jest jedynym mechanizmem odpowiedzialnym za bezpieczeństwo.
Jeżeli aktualizacje wykonywane są pierwszego dnia miesiąca, a kilka dni później zostanie ujawniona krytyczna podatność w używanej wtyczce, do kolejnego zaplanowanego przeglądu pozostają ponad trzy tygodnie. Przez cały ten okres podatna wersja może nadal działać na produkcji.
Nie można też zakładać, że pojawienie się podatności zawsze oznacza natychmiastową dostępność aktualizacji. Jeżeli producent nie opublikował jeszcze poprawionej wersji, WordPress może nie pokazywać żadnej dostępnej aktualizacji, mimo że używany komponent ma już publicznie znany problem z bezpieczeństwem.
Dlatego regularne utrzymanie warto oddzielić od monitorowania podatności. Aktualizacje można planować w określonych terminach, ale informacja o krytycznej podatności powinna zostać przeanalizowana od razu.
AI przyspiesza wyszukiwanie podatności
Tempo wykrywania błędów bezpieczeństwa również się zmienia. Narzędzia wykorzystujące AI są coraz częściej używane do analizy dużych repozytoriów, wyszukiwania potencjalnych podatności, weryfikowania ich znaczenia i wspomagania przygotowania poprawek.
Automatyzacja red teamingu i analizy bezpieczeństwa pozwala sprawdzać znacznie większą ilość kodu niż przy ręcznej analizie. Dla producentów oprogramowania oznacza to możliwość wcześniejszego znajdowania błędów, ale dla właściciela strony ma również drugą konsekwencję: informacje o nowych podatnościach mogą pojawiać się szybciej i częściej.
Proces utrzymania strony powinien być na to przygotowany. Jeżeli wykrywanie podatności jest coraz bardziej zautomatyzowane, trudno opierać reakcję wyłącznie na tym, że administrator raz na kilka tygodni otworzy ekran aktualizacji WordPressa.
Brak dostępnej aktualizacji nie oznacza braku podatności
Panel WordPressa odpowiada przede wszystkim na pytanie, czy dla zainstalowanego komponentu dostępna jest nowsza wersja. Nie jest to równoznaczne ze sprawdzeniem, czy obecnie używana wersja ma znaną podatność.
Może się zdarzyć, że na stronie działa najnowsza dostępna wersja wtyczki, ale została w niej właśnie ujawniona podatność i producent nie zdążył jeszcze opublikować poprawki. Podobna sytuacja występuje w przypadku porzuconych wtyczek. WordPress nie pokazuje aktualizacji, ponieważ nowe wydania po prostu przestały powstawać.
Dlatego przy ocenie bezpieczeństwa warto znać dokładne wersje WordPressa, motywu i wtyczek, a następnie porównywać je z informacjami o znanych podatnościach. Pozwala to wykryć sytuacje, których sam ekran aktualizacji nie pokaże.
Monitoring podatności można zautomatyzować
W DockRay wykorzystujemy właśnie takie podejście. Monitoring pobiera informacje o wersji WordPressa oraz zainstalowanych wtyczkach i ich wersjach. Te informacje mogą być następnie porównywane z danymi o znanych podatnościach.
Jeżeli pojawi się podatność dotycząca wersji działającej na monitorowanej stronie, DockRay może wysłać alert. Administrator nie musi więc czekać na kolejny zaplanowany przegląd ani samodzielnie sprawdzać każdego używanego komponentu.
Alert nie zastępuje oczywiście analizy ani samej aktualizacji. Jego zadaniem jest skrócenie czasu pomiędzy pojawieniem się informacji o podatności a reakcją osoby odpowiedzialnej za stronę. Po otrzymaniu informacji można sprawdzić dostępność poprawionej wersji, znaczenie podatności dla konkretnego serwisu i zdecydować o dalszych działaniach.
Automatyczne aktualizacje też trzeba kontrolować
Włączenie automatycznych aktualizacji może skrócić czas instalowania poprawek, ale nie powinno być traktowane jako kompletny system bezpieczeństwa. Aktualizacja nie pomoże, jeżeli poprawiona wersja jeszcze nie istnieje, a w rozbudowanym serwisie automatyczne wdrożenie nowej wersji może dodatkowo spowodować konflikt z motywem, inną wtyczką lub własnym kodem.
Istnieje również mniej oczywisty problem. WordPress może w określonych konfiguracjach nie wykonywać automatycznych aktualizacji mimo tego, że administrator zakłada, że są aktywne.
Repozytorium Git może zatrzymać automatyczne aktualizacje
WordPress sprawdza, czy instalacja znajduje się w katalogu objętym systemem kontroli wersji. Mechanizm WP_Automatic_Updater::is_vcs_checkout() szuka między innymi katalogów .git, .svn, .hg i .bzr. Ich wykrycie może spowodować pominięcie automatycznych aktualizacji.
Ma to znaczenie szczególnie na VPS-ach i serwerach, na których WordPress jest wdrażany z repozytorium. Katalog .git może znajdować się również wyżej niż sam katalog publiczny strony, przez co przyczyna braku aktualizacji nie zawsze jest oczywista.
Przy aktualizacji rdzenia WordPress może poinformować administratora o takiej sytuacji, ale w przypadku wtyczek i motywów problem może pozostać niezauważony. W panelu nadal można przy tym widzieć informację sugerującą, że automatyczne aktualizacje są włączone.
Stan mechanizmu warto sprawdzić w sekcji Narzędzia → Stan witryny, gdzie WordPress wykonuje test aktualizacji w tle. Przy instalacjach zarządzanych technicznie warto również przejrzeć konfigurację wp-config.php:
php
AUTOMATIC_UPDATER_DISABLED
DISALLOW_FILE_MODS
WP_AUTO_UPDATE_CORE
Jeżeli strona jest wdrażana przez Git i CI/CD, bezpieczniejszym rozwiązaniem może być kontrolowany proces podnoszenia wersji, testowania i wdrażania zmian niż niezależne modyfikowanie plików bezpośrednio na produkcji.
Usuń wtyczki i motywy, których nie używasz
Nieaktywna wtyczka nadal pozostaje na serwerze. Jej pliki PHP nie znikają po kliknięciu „Dezaktywuj”, dlatego niepotrzebne komponenty lepiej całkowicie usuwać.
Przy okazji warto sprawdzić, które wtyczki są nadal rozwijane. Brak dostępnych aktualizacji może oznaczać, że używana wersja jest aktualna, ale może też wynikać z tego, że autor zakończył rozwój projektu.
Przy każdym istotnym komponencie warto znać datę ostatniego wydania, deklarowaną zgodność z aktualnymi wersjami WordPressa oraz informacje o znanych podatnościach. Szczególnej uwagi wymagają wtyczki, które od kilku lat nie otrzymały nowej wersji, a nadal obsługują formularze, płatności, pliki lub inne funkcje dostępne z internetu.
Uporządkuj konta i uprawnienia
Po zabezpieczeniu warstwy oprogramowania warto przejrzeć dostęp użytkowników. Konta osób, które nie współpracują już przy stronie, powinny zostać usunięte lub zablokowane, a rola administratora ograniczona do osób, które rzeczywiście potrzebują pełnych uprawnień.
Dla kont administracyjnych warto stosować unikalne hasła i 2FA. Trzeba również pamiętać o hasłach aplikacji WordPressa, które zapewniają osobny dostęp między innymi do REST API. Zmiana zwykłego hasła użytkownika nie jest tym samym co odwołanie wcześniej utworzonych haseł aplikacji.
Dodatkowym ograniczeniem może być wyłączenie możliwości edycji plików motywów i wtyczek bezpośrednio z panelu:
php
define('DISALLOW_FILE_EDIT', true);
Nie zabezpieczy to strony przed każdym sposobem modyfikacji plików, ale ograniczy możliwości działania osoby, która przejęła konto administratora.
Kopie zapasowe powinny znajdować się poza serwerem strony
Backup przechowywany wyłącznie na tym samym serwerze co WordPress nie daje pełnego zabezpieczenia na wypadek poważnego incydentu. Przy szerokim dostępie do środowiska atakujący może uszkodzić zarówno stronę, jak i znajdujące się obok kopie.
Przynajmniej jedna kopia powinna być przechowywana niezależnie od serwera produkcyjnego. Warto również okresowo sprawdzać proces odtwarzania. Sam fakt, że system tworzy pliki backupu, nie gwarantuje jeszcze, że uda się z nich poprawnie uruchomić stronę, bazę danych i wszystkie integracje.
WAF i wtyczka bezpieczeństwa są dodatkową warstwą
Wtyczki bezpieczeństwa i WAF mogą blokować część podejrzanego ruchu, ograniczać próby logowania, wykrywać zmiany w plikach i dostarczać dodatkowe informacje o aktywności na stronie. Są przydatnym elementem zabezpieczenia, ale nie zastępują aktualizacji, monitorowania podatności i kontroli używanych komponentów.
WAF może być szczególnie przydatny w okresie pomiędzy ujawnieniem podatności a publikacją poprawionej wersji. Jeżeli sposób wykorzystania błędu jest znany i można go rozpoznać na poziomie ruchu HTTP, odpowiednia reguła może ograniczyć ryzyko do czasu wdrożenia właściwej poprawki.
Co zrobić, jeśli WordPress został już zhakowany?
Przywrócenie kopii zapasowej może szybko przywrócić działanie strony, ale nie powinno kończyć obsługi incydentu. Jeżeli w kopii znajduje się ta sama podatna wersja wtyczki, która umożliwiła włamanie, po odtworzeniu wraca również przyczyna całej sytuacji.
Przed rozpoczęciem czyszczenia warto zachować kopię zainfekowanego środowiska. Logi i zmodyfikowane pliki mogą później pomóc ustalić moment oraz sposób wejścia atakującego.
Następnie trzeba unieważnić aktywne sesje, zmienić klucze i sole WordPressa oraz wymienić dane dostępowe nie tylko do panelu administracyjnego, ale również do hostingu, SFTP lub SSH i bazy danych. Osobno należy przejrzeć i odwołać niepotrzebne hasła aplikacji.
Pliki rdzenia można zweryfikować za pomocą WP-CLI:
bash
wp core verify-checksums
W przypadku wtyczek pochodzących z oficjalnego repozytorium można wykorzystać:
bash
wp plugin verify-checksums --all
Weryfikacja sum kontrolnych pomaga znaleźć zmienione pliki, ale nie daje pełnej odpowiedzi na temat stanu całego serwisu. Własny motyw, dedykowana wtyczka albo komponent premium spoza oficjalnego repozytorium nie zawsze mają publiczny wzorzec, z którym można wykonać takie porównanie.
Trzeba również przeanalizować bazę danych. Złośliwe przekierowanie może zostać zapisane w wp_options, treści wpisu albo zadaniu cron i nie zostanie wykryte przez porównanie plików.
Po usunięciu zmian pozostaje ustalenie sposobu włamania. Pomagają w tym logi serwera z okresu poprzedzającego pierwsze objawy oraz lista wersji WordPressa, motywów i wtyczek działających wtedy na produkcji. Dopiero usunięcie podatnego komponentu lub zamknięcie innego wykorzystanego wektora ataku pozwala ograniczyć ryzyko ponownej infekcji.
Skaner bezpieczeństwa nie sprawdzi wszystkiego
Skanery bardzo dobrze radzą sobie z plikami, dla których istnieje znana oryginalna wersja albo sygnatura złośliwego kodu. Trudniejsze są własne motywy, dedykowane wtyczki, kod znajdujący się w mu-plugins oraz płatne komponenty dystrybuowane poza oficjalnym repozytorium.
Osobnym obszarem jest baza danych. Zmiany w wp_options, zadaniach cron czy treści wpisów nie są widoczne podczas zwykłego porównywania sum kontrolnych plików.
Skaner może więc wskazać zmodyfikowany plik lub wykryć znaną sygnaturę malware, ale nie zawsze ustali sposób, w jaki zmiana znalazła się na serwerze. Do tego potrzebna jest analiza logów oraz informacji o podatnościach komponentów używanych w momencie incydentu.
Jak powinno wyglądać utrzymanie bezpiecznego WordPressa?
Regularne przeglądy nadal mają znaczenie. Aktualizacje można wcześniej przetestować, wykonać kopię zapasową, wdrożyć zmiany w kontrolowany sposób i sprawdzić najważniejsze funkcje strony lub sklepu.
Nie powinny być jednak jedynym momentem, w którym sprawdzane jest bezpieczeństwo serwisu. Pomiędzy zaplanowanymi aktualizacjami trzeba monitorować, czy dla wersji działających na produkcji nie pojawiły się nowe podatności.
Jeżeli pojawi się istotna podatność, reakcja zależy od konkretnego przypadku. Przy dostępnej poprawce można przygotować szybszą aktualizację. Jeżeli poprawki jeszcze nie ma, trzeba ocenić możliwość wyłączenia podatnej funkcji, zastosowania tymczasowego zabezpieczenia albo zastąpienia komponentu.
W praktyce oznacza to połączenie regularnego utrzymania z ciągłym monitoringiem bezpieczeństwa. Harmonogram określa, kiedy wykonujemy standardowe prace serwisowe, natomiast alert o poważnej podatności może uruchomić działanie niezależnie od tego harmonogramu.
Bezpieczeństwo WordPressa wymaga ciągłej kontroli
Przy utrzymaniu i rozwoju stron sprawdzamy nie tylko dostępne aktualizacje. Analizujemy również używane wersje, porzucone i niepotrzebne komponenty, konfigurację aktualizacji, kopie zapasowe oraz podatności wymagające reakcji poza standardowym terminem prac serwisowych.
Część tego procesu można zautomatyzować. DockRay monitoruje wersje WordPressa i zainstalowanych wtyczek oraz może ostrzec, gdy dla używanej wersji zostanie wykryta znana podatność. Pozwala to zareagować wcześniej, zamiast czekać na następny zaplanowany przegląd strony.
Jeżeli hosting zgłosił podejrzane pliki, strona zaczęła zachowywać się nietypowo albo chcesz sprawdzić, czy używane komponenty są bezpieczne, napisz do nas. Możemy przeanalizować instalację, sprawdzić jej aktualny stan i przygotować proces dalszego utrzymania oraz monitorowania.
