Usuwanie malware z WordPressa: plan krok po kroku

Skuteczne usuwanie malware z WordPressa polega na zastąpieniu wszystkiego, co się da, kopiami z zaufanych źródeł, zamknięciu luki, przez którą wszedł atakujący, i zmianie każdego sekretu, który mógł zobaczyć. Skasowanie jednego znalezionego podejrzanego pliku nie wystarczy, bo atakujący zwykle zostawiają sobie więcej niż jedną drogę powrotu.

Plan składa się z ośmiu kroków. Najlepiej przechodzić je po kolei i na bieżąco robić notatki: przydadzą się w kontaktach z Google, z dostawcą hostingu i być może z organem ochrony danych. Jeśli nie ma jeszcze pewności, że strona została przejęta, warto zacząć od naszej listy 12 oznak zhakowanej strony WordPress.

Przed usunięciem malware z WordPressa: czyścić, przywracać czy wezwać pomoc?

Tę decyzję trzeba podjąć na samym początku, bo od niej zależy reszta planu.

• Przywrócić czystą kopię zapasową, jeśli wiadomo mniej więcej, kiedy zaczęła się infekcja, i istnieje kopia sprzed tej daty. Kroki 3, 5 i 6 są nadal konieczne, w przeciwnym razie atakujący wróci tą samą drogą. Zamówienia, komentarze czy wpisy z formularzy powstałe po wykonaniu kopii przepadną, chyba że wcześniej zostaną wyeksportowane.
• Wezwać specjalistę, jeśli strona przyjmuje płatności lub przechowuje wrażliwe dane, infekcja wróciła po wcześniejszym czyszczeniu, zainfekowanych jest kilka stron na tym samym serwerze, potrzebny jest raport z analizy powłamaniowej dla ubezpieczyciela lub urzędu albo praca w wierszu poleceń nie jest dla Państwa komfortowa. Taką usługę oferuje też wielu dostawców hostingu.
• Wyczyścić stronę samodzielnie, jeśli mają Państwo dostęp przez SSH i WP-CLI, listę używanych wtyczek i motywów oraz czas, żeby zrobić to porządnie.

Izolacja: powstrzymać szkody, zachować dowody

Krok 1: Odizolować stronę

Stronę należy wyłączyć albo ograniczyć do niej dostęp, żeby odwiedzający nie zostali zainfekowani. wp maintenance-mode activate wyświetla komunikat o pracach serwisowych, ale działa tylko na żądania, które ładują WordPressa: wywołany bezpośrednio plik z tylną furtką nadal się wykona. Prawdziwa izolacja odbywa się na serwerze, dlatego warto poprosić dostawcę hostingu o zablokowanie publicznego dostępu lub ograniczenie go do Państwa adresu IP.

Następnie trzeba zamknąć panel administracyjny. To polecenie wylogowuje wszystkich użytkowników:

wp user list --field=ID | xargs -n 1 wp user session destroy --all

Własne hasło administratora należy zmienić z czystego urządzenia. Nieznane konta warto zanotować, ale usunąć je dopiero po kroku 2. Na zainfekowanej stronie można dodawać do poleceń WP-CLI --skip-plugins --skip-themes, aby kod wtyczek i motywów się nie wykonywał; wtyczki must-use i wp-config.php nadal się ładują.

Krok 2: Zapisać stan po infekcji

Zanim cokolwiek się zmieni, trzeba zapisać zhakowaną stronę dokładnie w obecnym stanie. Ta kopia jest potrzebna do ustalenia drogi włamania, do odpowiedzi dla ubezpieczyciela lub urzędu, a także jako punkt powrotu, gdyby czyszczenie coś zepsuło.

# uruchomić w katalogu głównym WordPressa; ~/evidence musi leżeć poza katalogiem WWW
mkdir -p ~/evidence
wp db export ~/evidence/db-infected-$(date +%F).sql
tar -czf ~/evidence/files-infected-$(date +%F).tar.gz .
sha256sum ~/evidence/*

Wiersz z sha256sum zapisuje sumy kontrolne, dzięki którym można później wykazać, że kopie pozostały niezmienione. Warto też pobrać logi dostępu i błędów, bo wielu dostawców przechowuje je tylko przez ograniczony czas.

Czyszczenie: zamknąć lukę i wymienić to, co naruszono

Krok 3: Znaleźć drogę włamania

Kto pominie ten krok, może za tydzień czyścić tę samą stronę od nowa. Typowe drogi wejścia to podatne wtyczki lub motywy, skradzione albo wielokrotnie używane hasła oraz inne zainfekowane strony na tym samym koncie hostingowym.

• Podatne wtyczki i motywy. Uruchomić wp plugin list --fields=name,status,version,update i wp theme list, a potem sprawdzić każdy nieaktualny element w bazie podatności. Liczy się czas: firma Patchstack, dostawca rozwiązań bezpieczeństwa, podaje, że w 2025 roku przy intensywnie wykorzystywanych podatnościach ważona mediana czasu do masowych ataków wyniosła 5 godzin (State of WordPress Security in 2026).
• Skradzione dane logowania. Sprawdzić, kiedy utworzono nieznane konta administratorów, i poszukać logowań z nieznanych adresów IP.
• Logi serwera. Szukać żądań POST do nietypowych plików w okolicach czasu, w którym zmienił się pierwszy plik.

grep '"POST ' access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20
find . -type f -name '*.php' -mtime -14 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort

W miejsce access.log trzeba wstawić własny plik logu. Pierwsze polecenie wyświetla ścieżki, do których trafiło najwięcej żądań POST, drugie – pliki PHP zmienione w ciągu ostatnich 14 dni. Znaczniki czasu da się sfałszować, więc należy je traktować jako wskazówki. Jeśli drogi włamania nie uda się ustalić, trzeba założyć najgorsze: wymienić wszystkie wtyczki i motywy oraz zmienić wszystkie dane dostępowe.

Krok 4: Wyczyścić stronę z użyciem zaufanych źródeł

Wymieniać zamiast naprawiać: świeże kopie z oficjalnego źródła są pewniejsze niż analiza zaciemnionego kodu.

Rdzeń WordPressa. Usunąć katalogi wp-admin i wp-includes i pobrać ponownie tę samą wersję, aby zniknęły także dodatkowe pliki ukryte w tych folderach. Polecenia należy uruchomić w katalogu głównym WordPressa, czyli w folderze, w którym znajdują się wp-load.php i wp-admin:

VER=$(wp core version)
[ -n "$VER" ] && [ -f wp-load.php ] && rm -rf wp-admin wp-includes && \
  wp core download --version="$VER" --skip-content --force
wp core verify-checksums --include-root

Drugi wiersz niczego nie usunie, jeśli nie udało się ustalić wersji albo polecenie nie zostało uruchomione w katalogu głównym WordPressa. --include-root (WP-CLI 2.8 lub nowszy) wyświetla dodatkowo nieznane pliki w katalogu głównym.

Wtyczki i motywy. Każdy folder wtyczki i motywu zastąpić świeżą kopią z WordPress.org lub ze strefy pobierania producenta. W przypadku wtyczek z WordPress.org polecenie wp plugin install <slug> --force nadpisuje zainstalowaną kopię, a wp plugin verify-checksums --all wskazuje potem zmienione i dodane pliki. Wszystko, czego się nie używa, należy usunąć i nigdy nie instalować ponownie z kopii typu „nulled”.

Uploads. Zawartości folderu uploads nie da się zainstalować od nowa, więc trzeba ją przejrzeć: wyszukać pliki PHP poleceniem find wp-content/uploads -type f -iname '*.php', porównać folder z kopią sprzed infekcji i usunąć wszystko, co nie jest plikiem multimedialnym.

Konfiguracja i pliki drop-in. Ręcznie sprawdzić wp-config.php, .htaccess, .user.ini, wp-content/mu-plugins oraz pliki drop-in, takie jak object-cache.php.

Baza danych. Złośliwy kod kryje się także we wpisach, opcjach, kontach użytkowników i zaplanowanych zdarzeniach:

wp user list --role=administrator --skip-plugins --skip-themes
wp option get siteurl && wp option get home
wp db search '<script' --all-tables
wp cron event list --fields=hook,next_run_relative,recurrence

wp db search znajduje również legalne skrypty, na przykład fragmenty kodu narzędzi analitycznych. Nieznanych administratorów, wpisy ze spamem i wstrzyknięte opcje należy usuwać dopiero po sprawdzeniu każdego z nich.

Krok 5: Zmienić wszystkie dane dostępowe oraz klucze i sole

Trzeba założyć, że atakujący przeczytał wp-config.php i każdy sekret zapisany na serwerze. Zmienić należy:

• każde konto WordPressa z uprawnieniami administratora lub redaktora, a nieznane hasła aplikacji (Application Passwords) unieważnić;
• dostęp do panelu hostingu, SFTP/FTP i SSH, łącznie z autoryzowanymi kluczami SSH;
• hasło do bazy danych, jednocześnie u dostawcy hostingu i w wp-config.php;
• klucze API zapisane we wtyczkach: płatności, SMTP, magazyn kopii zapasowych, CDN;
• konto e-mail, na które przychodzą linki do resetowania hasła administratora.

Następnie należy wymienić klucze uwierzytelniające i sole (salts) w wp-config.php. Zgodnie z dokumentacją WordPressa dla deweloperów ich zmiana unieważnia wszystkie istniejące ciasteczka, więc każdy musi zalogować się ponownie, również atakujący ze skradzioną sesją.

wp config shuffle-salts

Dalsze działania: zabezpieczyć, monitorować, udokumentować

Krok 6: Wzmocnić zabezpieczenia strony

• Zaktualizować rdzeń, wtyczki i motywy; nasz poradnik o podatnych wtyczkach WordPress omawia przeglądy i automatyczne aktualizacje.
• Dodać define( 'DISALLOW_FILE_EDIT', true ); do wp-config.php, aby usunąć z kokpitu edytory plików. DISALLOW_FILE_MODS idzie dalej i blokuje także aktualizacje z kokpitu i aktualizacje automatyczne, dlatego warto go używać tylko wtedy, gdy aktualizacje są instalowane w inny sposób.
• Włączyć uwierzytelnianie dwuskładnikowe dla każdego administratora. Rdzeń WordPressa go nie zawiera.
• Zablokować wykonywanie PHP w uploads. Apache 2.4, w pliku wp-content/uploads/.htaccess:

<FilesMatch "\.(?i:php|phtml|phar)$">
    Require all denied
</FilesMatch>

W nginx tę regułę należy umieścić przed ogólnym blokiem location ~ \.php$, ponieważ nginx używa pierwszej pasującej lokalizacji z wyrażeniem regularnym:

location ~* ^/wp-content/uploads/.*\.(php|phtml|phar)$ { deny all; }

Przed przeładowaniem konfiguracji warto uruchomić nginx -t, a potem sprawdzić, czy obrazy nadal się wczytują.

Krok 7: Monitorować i poprosić o ponowną weryfikację

W kolejnych tygodniach stronę trzeba uważnie obserwować: powtarzać kontrolę sum kontrolnych i folderu uploads, porównywać listy plików z czystym stanem i czytać logi dostępu. Jeśli infekcja wraca, droga wejścia jest nadal otwarta – i to jest moment, by wezwać specjalistę.

W tej fazie może pomóc Security Audit & Compliance od secaudit.eu: wtyczka utrzymuje bazowy stan integralności plików, weryfikuje sumy kontrolne rdzenia i szuka ukrytych administratorów, podejrzanych zdarzeń cron oraz ukrytego spamu SEO. Wykrywa i raportuje, ale nie czyści strony za Państwa.

Jeśli Google oznaczył stronę, po zakończeniu czyszczenia należy otworzyć w Search Console raport Security issues, wybrać Request a review i opisać, co zostało naprawione. Według Google weryfikacja trwa około jednego dnia w przypadku phishingu, kilka dni w przypadku malware i nawet kilka tygodni w przypadku spamu po włamaniu. O usunięcie z pocztowych list blokujących warto prosić dopiero wtedy, gdy spam przestanie wychodzić.

Krok 8: Ocenić naruszenie pod kątem RODO i je udokumentować

Ten krok jest ostatni na liście, ale jego zegar tyka od pierwszego dnia. Jeśli dane klientów, konta użytkowników, wpisy z formularzy lub zamówienia zostały ujawnione, zmienione albo stały się niedostępne, włamanie jest zazwyczaj naruszeniem ochrony danych osobowych. Wtedy trzeba zgłosić je organowi nadzorczemu (w Polsce Prezesowi UODO) bez zbędnej zwłoki, w miarę możliwości nie później niż w terminie 72 godzin od stwierdzenia naruszenia, chyba że jest mało prawdopodobne, by skutkowało ono ryzykiem naruszenia praw lub wolności osób fizycznych (art. 33 RODO). Jeśli ryzyko dla tych osób jest wysokie, trzeba je również zawiadomić (art. 34).

Bez względu na decyzję należy udokumentować okoliczności naruszenia, jego skutki i podjęte działania zaradcze: art. 33 ust. 5 wymaga tego przy każdym naruszeniu, także niezgłoszonym. Nasz poradnik o zgłaszaniu naruszeń w ciągu 72 godzin prowadzi przez tę ocenę krok po kroku. Jeśli Państwa organizacja podlega dyrektywie NIS2, poważne incydenty wymagają ponadto wczesnego ostrzeżenia w ciągu 24 godzin; szczegóły trzeba sprawdzić w krajowych przepisach wdrażających NIS2.

Najczęściej zadawane pytania

Czy wtyczka bezpieczeństwa może usunąć malware za mnie?

Niektóre narzędzia oferują automatyczne usuwanie znanego złośliwego oprogramowania. Żadne z nich nie powie jednak z pewnością, jak atakujący dostał się do środka ani jakie hasła przejął, więc kroki 3, 5 i 6 pozostają Państwa zadaniem.

Czy ponowna instalacja rdzenia WordPressa usunie moje treści?

Nie. Wpisy, strony i ustawienia są przechowywane w bazie danych, a dzięki --skip-content wtyczki, motywy i pliki w uploads pozostają nietknięte. Wymieniane są wyłącznie pliki rdzenia w wp-admin, wp-includes i katalogu głównym; wp-config.php zostaje zachowany.

Ten artykuł ma charakter ogólnoinformacyjny i nie stanowi porady prawnej.