Jak sprawdzić, czy strona WordPress jest zainfekowana — 9 objawów i 5 testów

Większość infekcji WordPressa nie wygląda jak w filmach. Nie ma czaszki na stronie głównej. Jest za to dziwne przekierowanie z telefonu, spadek pozycji w Google albo mail od hostingu, że „na koncie wykryto złośliwe oprogramowanie”. Poniżej objawy, które warto znać, i testy, które możesz zrobić sam w kwadrans.

9 objawów, że WordPress może być zainfekowany

1. Przekierowania na obce strony, często tylko z telefonu albo tylko z wyników Google. Z komputera, po wpisaniu adresu ręcznie, wszystko wygląda normalnie. To klasyczny cloaking: złośliwy kod sprawdza, kto wchodzi.
2. Ostrzeżenie w Google („Ta strona może być niebezpieczna”) lub w przeglądarce, albo nagły spadek ruchu z wyszukiwarki.
3. Obce podstrony w indeksie Google — wpisz site:twojadomena.pl i poszukaj wpisów o farmaceutykach, kasynach czy w obcym języku.
4. Mail z hostingu o malware lub blokada strony z komunikatem „Malware detected”.
5. Nowi administratorzy w Użytkownicy → Wszyscy, których nikt nie dodawał.
6. Nieznane wtyczki lub motywy, często o nazwach udających systemowe (wp-core-helper, security-update).
7. Pliki PHP w katalogu wp-content/uploads. W katalogu na obrazki nie powinno być kodu.
8. Wysyłka spamu z Twojej domeny, skrzynki klientów odbijają Twoje maile.
9. Nagły wzrost zużycia zasobów na hostingu bez wzrostu ruchu.

Jeden objaw to podejrzenie, dwa to niemal pewność.

5 testów, które zrobisz sam

1. Sprawdź stronę „oczami Google”

W Google Search Console zajrzyj do sekcji Bezpieczeństwo. Jeśli nie masz Search Console, użyj Google Safe Browsing — wpisujesz adres i widzisz, czy Google oznaczył stronę.

2. Porównaj to, co widzi Googlebot, z tym, co widzisz Ty

Cloaking polega na tym, że robotom i użytkownikom z wyszukiwarki serwowana jest inna treść. Z terminala:

curl -A "Googlebot" -sL https://twojadomena.pl | head -50

Jeśli w odpowiedzi widzisz treść o lekach, zakładach albo przekierowanie, którego nie ma w przeglądarce, strona jest zainfekowana.

3. Poszukaj świeżo zmienionych plików

Po SSH, w katalogu strony:

find . -name "*.php" -mtime -7 -not -path "./wp-content/cache/*"

Pliki rdzenia WordPressa zmieniają się tylko przy aktualizacji. Jeśli index.php, wp-config.php albo pliki w wp-includes mają datę z wczoraj, a nikt nie aktualizował, to ślad.

4. Poszukaj typowych wzorców w kodzie

grep -rl "base64_decode\|eval(\|gzinflate\|str_rot13" --include="*.php" . | head

Nie każde trafienie to malware (wtyczki czasem używają tych funkcji legalnie), ale trafienia w uploads, w szablonie albo w index.php są bardzo podejrzane.

5. Sprawdź pliki .htaccess w podkatalogach

Jedna z najczęstszych technik ukrywania shelli, którą widzimy w naprawach, to plik .htaccess, który blokuje wykonywanie wszystkich plików PHP w katalogu oprócz kilku o konkretnych nazwach, np. radio.php, lock360.php, wp-l0gin.php. Taki plik nie jest kodem, więc skanery go pomijają, a atakujący ma wygodne, chronione wejście.

find . -name ".htaccess" -newer wp-config.php

Co zrobić, gdy wynik jest pozytywny

• Nie kasuj plików na oko. Usunięcie pliku, który strona potrzebuje, zamieni infekcję w białą stronę. Lepiej przenosić pliki do kwarantanny, żeby móc je przywrócić.
• Zmień hasła: do panelu WordPressa, do bazy (wp-config.php), do FTP/SSH i do panelu hostingu. Wyloguj wszystkie sesje.
• Porównaj pliki rdzenia z oficjalnym wydaniem tej samej wersji. Zmodyfikowany plik rdzenia nie wymaga „leczenia” — wystarczy przywrócić oryginał.
• Sprawdź uploads, motyw i .htaccess — to trzy miejsca, gdzie infekcja wraca najczęściej.
• Po czyszczeniu zaktualizuj wszystko: WordPress, wtyczki, motyw. 91 % luk w ekosystemie WordPressa jest we wtyczkach, a mediana czasu od ujawnienia luki do jej masowego wykorzystania to pięć godzin.

Jeśli wolisz, żeby zrobił to automat, który porównuje pliki z oficjalnym wydaniem, przenosi złośliwe do kwarantanny i pozwala cofnąć każdą zmianę, dokładnie to robi CleanOps. Sprawdzenie strony jest bezpłatne i niczego nie zmienia.