Jak usunąć malware z WordPressa w 2026 — kompletny przewodnik

Wprowadzenie

WordPress odpowiada za ponad 95% infekcji wśród systemów zarządzania treścią. W 2025 roku odkryto 11 334 nowych luk w ekosystemie WordPressa, a 91% z nich dotyczyło wtyczek. Do tego mediana czasu od ujawnienia podatności do masowej eksploatacji spadła do zaledwie kilku godzin.

W praktyce oznacza to jedno: ataki w 2026 są w ogromnej mierze zautomatyzowane. Boty nie wybierają ofiary ręcznie. Skanują internet pod kątem nieaktualnych wtyczek, słabych haseł i dziurawych motywów, a potem wykorzystują to, co znajdą najszybciej.

Różnica między szybką naprawą a długim problemem z SEO, reputacją i reinfekcją zwykle sprowadza się do tego, czy wiesz, co zrobić w pierwszych minutach po wykryciu infekcji. Poniżej masz kompletny proces — od objawów i triage, przez czyszczenie plików i bazy, po zamknięcie wektora ataku.

Po czym poznać, że strona została zainfekowana

Większość infekcji nie objawia się zdewastowaną stroną główną. Znacznie częściej sygnały są subtelne i łatwe do przeoczenia, zwłaszcza jeśli logujesz się jako administrator i widzisz inną wersję strony niż zwykły użytkownik.

Najczęstsze objawy to przekierowania do podejrzanych stron, które pojawiają się tylko na telefonach albo wyłącznie dla wejść z Google. Administrator na desktopie nie widzi nic niepokojącego, a użytkownik trafia na strony hazardowe, farmaceutyczne albo z malwarem.

Inne sygnały ostrzegawcze to nowe konta administratora, ostrzeżenia od hostingu, spadek ruchu organicznego, wolne działanie strony spowodowane złośliwymi skryptami albo komunikaty w Google Search Console o niebezpiecznej witrynie.

Warto też wykonać proste wyszukiwanie site:twojadomena.pl. Jeśli zobaczysz tysiące nieznanych podstron ze spamem, to klasyczny sygnał Japanese Keyword Hack. Trzeba pamiętać, że nowoczesne infekcje często żyją wyłącznie w bazie danych, więc sam skaner plików może nie pokazać pełnego obrazu.

Pierwsze 60 minut — triage

W pierwszej godzinie po wykryciu infekcji liczy się kolejność działań. Największym błędem jest chaotyczne kasowanie plików, bo w ten sposób usuwasz ślady potrzebne do znalezienia backdoora i ustalenia źródła włamania.

1. Wyłącz stronę

Jeżeli to możliwe, ustaw tryb konserwacji lub zablokuj dostęp na poziomie hostingu albo serwera. Jeśli hosting już zawiesił stronę, to z perspektywy bezpieczeństwa jest to lepsze niż dalsze serwowanie malware odwiedzającym.

2. Zmień hasła, ale nie z panelu WordPressa

Hasła zmieniaj z poziomu hostingu, SSH, panelu bazy lub kont systemowych, a nie z kokpitu WordPressa. Jeżeli napastnik jest aktywnie zalogowany, może zobaczyć nowe dane dostępu, zanim skończysz pracę.

• hasła administratorów WordPressa,
• hasło bazy danych,
• FTP/SFTP i SSH,
• panel hostingu.

3. Zrób kopię zainfekowanego stanu

To brzmi paradoksalnie, ale zainfekowany backup jest potrzebny. Taka kopia zawiera znaczniki czasowe, strukturę plików i ślady, które pomagają ustalić, jak doszło do infekcji. Skopiuj pliki oraz wyeksportuj bazę danych zanim zaczniesz czyszczenie.

4. Unieważnij wszystkie sesje

Otwórz wp-config.php i podmień klucze AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY oraz NONCE_KEY. Alternatywnie możesz użyć polecenia wp config shuffle-salts. To wyloguje wszystkich użytkowników, również napastnika.

5. Zapisz objawy

Przekierowania, ostrzeżenie z Search Console, mail od hostingu, nietypowe popupy albo nowe podstrony w indeksie Google — zapisz wszystko. Ten materiał bardzo pomaga później odtworzyć wzorzec ataku.

Diagnostyka — metody analizy problemu

Diagnostyka ma dwa poziomy. Black-box odpowiada na pytanie, co widzi użytkownik i Google. White-box to analiza plików, logów i bazy danych od środka. Dobre czyszczenie potrzebuje obu perspektyw.

Podejście black-box

Na tym etapie sprawdzasz widoczne objawy bez logowania do WordPressa:

• przeskanuj domenę w Sucuri SiteCheck,
• sprawdź Search Console i status blacklist,
• przetestuj stronę na telefonie jako wylogowany użytkownik,
• wejdź z innej sieci lub urządzenia, jeśli przekierowania są warunkowe.

Podejście white-box

Jeśli masz SSH, możesz bardzo szybko zawęzić obszar poszukiwań. Szczególnie ważne są pliki PHP w uploads, zaciemniony kod i świeżo modyfikowane pliki.

W praktyce szukasz przede wszystkim kilku konkretnych śladów:

• plików PHP w katalogu wp-content/uploads, bo nie powinno ich tam być,
• funkcji takich jak eval() i base64_decode(),
• wywołań typu shell_exec, passthru i system(),
• wstrzykniętych iframe i skryptów w plikach motywu,
• plików PHP zmodyfikowanych w ciągu ostatnich 72 godzin.

To zwykle daje bardzo dobry punkt startowy. Pliki zmodyfikowane w ciągu ostatnich 72 godzin często pokazują faktyczną ścieżkę infekcji. Warto też uruchomić wp core verify-checksums, bo błędy sum kontrolnych rdzenia są twardym sygnałem, że core został zmodyfikowany.

Nie pomijaj logów serwera. Szukaj żądań POST do wp-content/uploads, prób wykonania nieistniejących plików PHP, ataków na wp-login.php i xmlrpc.php oraz nietypowych adresów IP pojawiających się tuż przed objawami infekcji.

Czyszczenie plików

Najważniejsza zasada brzmi: zastępuj, nie łataj. Jeśli plik rdzenia, wtyczki albo motywu został skompromitowany, nie czyść go ręcznie linijka po linijce, tylko podmień na czystą wersję z pewnego źródła.

Rdzeń WordPressa

Najbezpieczniejsza ścieżka to nadpisanie plików rdzenia czystą paczką z WordPress.org bez ruszania wp-content.

Jeśli pracujesz przez WP-CLI, użyj polecenia wp core download --force --skip-content. Flaga --skip-content jest tu kluczowa, bo nie nadpisuje katalogu wp-content.

Wtyczki i motywy

Wtyczki i motywy najlepiej usuwać i instalować ponownie z oficjalnych źródeł. Nie używaj paczek z zainfekowanej instalacji jako materiału do odzyskiwania.

W przypadku WP-CLI reinstalacja wtyczki wygląda na przykład tak: wp plugin install contact-form-7 --force.

Dotyczy to szczególnie rozszerzeń premium i wszelkich nulled pluginów. Jeśli na stronie było coś z niepewnego źródła, traktuj to jako prawdopodobny wektor włamania i usuń bez sentymentu.

Katalog uploads

W katalogu uploads nie powinno być plików PHP. Każdy taki plik jest podejrzany i zwykle oznacza malware albo backdoor.

Jeśli potwierdzisz obecność takich plików, możesz usunąć je poleceniem find ./wp-content/uploads -name "*.php" -delete.

wp-config.php i .htaccess

wp-config.php sprawdź bardzo dokładnie. Szukaj nieznanych include, zakodowanych ciągów, kodu dołączonego przed otwierającym tagiem PHP albo niestandardowych konstrukcji, których wcześniej tam nie było.

.htaccess to drugi klasyczny punkt zaczepienia. Zwróć uwagę na reguły warunkowe dla użytkowników z Google, urządzeń mobilnych, botów i nietypowe przekierowania. Jeśli masz wątpliwości, wygeneruj domyślny plik WordPress i porównaj różnice.

Baza danych — tam gdzie skanery plików nie sięgają

Możesz wymienić każdy plik na serwerze i nadal mieć aktywne malware, jeśli złośliwy kod siedzi w bazie danych. To właśnie ten etap najczęściej odróżnia porządne czyszczenie od kosmetycznej naprawy.

Zanim cokolwiek zmienisz, zrób dump bezpieczeństwa:

Jeśli korzystasz z WP-CLI, zrobisz to poleceniem wp db export ~/db-before-clean.sql.

Konta administratorów

Najpierw sprawdź użytkowników z uprawnieniami administratora:

Przez WP-CLI możesz wypisać administratorów poleceniem wp user list --role=administrator --fields=ID,user_login,user_email,user_registered.

Usuń wszystkie konta, których nie rozpoznajesz. Podejrzane są zwłaszcza losowe loginy, nietypowe daty rejestracji i adresy w egzotycznych domenach.

Tabela wp_options

Szczególną uwagę zwróć na wpisy z autoload = yes, bo są ładowane przy każdym żądaniu. To dobre miejsce do ukrycia malware, złośliwych redirectów i payloadów trzymanych w serializowanych danych.

Tabela wp_posts

W treściach i postach szukaj wstrzykniętych skryptów, iframe oraz spamowych stron z chińskimi albo japońskimi znakami. Przydatne są takie zapytania:

W samej bazie danych warto wyszukiwać wpisy zawierające <script, eval( oraz <iframe. To najczęstsze wzorce przy wstrzyknięciach do treści i spamowych podstronach.

Do szukania i podmian w całej bazie lepiej używać wp search-replace --dry-run niż ręcznych operacji SQL REPLACE, bo WP-CLI poprawnie obsługuje serializowane dane WordPressa.

Backdoory — prawdziwa przyczyna reinfekcji

Jeśli infekcja wraca po kilku dniach, to niemal zawsze znaczy, że przegapiłeś backdoor. To on pozwala napastnikowi wrócić nawet po zmianie haseł i wyczyszczeniu widocznych śladów.

• mu-plugins — ładują się automatycznie i nie rzucają się w oczy,
• uploads — PHP shelle udające obrazy lub pliki techniczne,
• prawdziwe wtyczki — dodatkowe pliki o nazwach przypominających systemowe,
• WP-Cron — zadania odtwarzające malware po czyszczeniu,
• .htaccess w podkatalogach — np. z dyrektywą php_value auto_prepend_file.

Po wyczyszczeniu plików sprawdź zdarzenia cron:

Jeśli używasz WP-CLI, listę takich zdarzeń pokaże polecenie wp cron event list.

Backdoory bardzo często są zaciemnione. Jeśli widzisz w pliku kombinacje eval, base64_decode, gzinflate, str_rot13, dynamicznie składane nazwy funkcji albo include do zewnętrznych zasobów, traktuj to jako sygnał alarmowy.

Testowanie po czyszczeniu

Po usunięciu malware nie zakładaj, że temat jest zamknięty. Potrzebujesz potwierdzenia z kilku niezależnych źródeł.

• uruchom wp core verify-checksums,
• przeskanuj stronę zewnętrznym narzędziem, np. Sucuri SiteCheck,
• sprawdź sekcję Security Issues w Search Console,
• wejdź na stronę jako wylogowany użytkownik na telefonie i z innej sieci,
• zweryfikuj, czy nie pojawiły się nowe konta administratora i nowe zadania cron.

Najważniejsze jest monitorowanie przez 48–72 godziny. Jeśli infekcja wróci w tym czasie, oznacza to, że nadal działa backdoor albo nie został zamknięty pierwotny wektor ataku.

Zabezpieczenie przed kolejnym atakiem

Samo czyszczenie nie wystarczy. Bez twardego domknięcia tematu strona wróci do punktu wyjścia przy pierwszym kolejnym skanie botów.

Zmień wszystko, co mogło wyciec

Po zakończeniu czyszczenia załóż, że wyciekły wszystkie dane dostępowe: WordPress, hosting, baza, FTP/SFTP, SSH, a także klucze API. Zmień je wszystkie i odśwież salts w wp-config.php.

Zablokuj łatwe wektory ataku

Z poziomu WordPressa warto od razu zablokować edycję plików w panelu:

W praktyce sprowadza się to do dodania w wp-config.php stałej define('DISALLOW_FILE_EDIT', true);.

Jeśli nie korzystasz z XML-RPC, wyłącz go. To nadal częsty cel ataków brute force i prób nadużyć.

Włącz warstwę ochronną

WAF, np. Cloudflare, blokuje dużą część znanych exploitów jeszcze zanim dotrą do serwera. Do tego włącz 2FA dla administratorów i usuń wszystkie nieużywane wtyczki oraz motywy — nie deaktywuj, tylko usuń.

Uporządkuj aktualizacje i backupy

WordPress, wtyczki i motywy muszą być aktualne. Przy obecnym tempie publikacji i eksploatacji luk ręczne, sporadyczne aktualizacje zwykle są po prostu za wolne. Równie ważne są codzienne kopie zapasowe trzymane poza serwerem i regularnie testowane pod kątem odtwarzania.

Kiedy wezwać profesjonalistę

Nie każdą infekcję warto czyścić samodzielnie. Jeśli malware wraca mimo czyszczenia, nie możesz znaleźć backdoora, strona obsługuje płatności albo dane klientów, albo po prostu skala problemu jest zbyt duża, rozsądniej jest przekazać temat komuś, kto robi to zawodowo.

Zakończenie

Infekcja WordPressa nie musi oznaczać katastrofy, ale wymaga metodycznego działania. Izolacja strony, kopia zainfekowanego stanu, poprawna diagnoza, wymiana plików na czyste, sprawdzenie bazy danych i usunięcie backdoorów to elementy, których nie da się bezpiecznie pominąć.

To, co odróżnia dwugodzinne odzyskiwanie strony od kilkutygodniowego problemu z SEO i reinfekcją, to przygotowanie. Regularne backupy, aktualizacje, kontrola Search Console i podstawowa higiena bezpieczeństwa sprawiają, że nawet poważny incydent staje się problemem do opanowania, a nie końcem projektu.