Infekcja WordPress wraca po czyszczeniu — co sprawdzić?

27 października, 2026 autor soban

Strona po czyszczeniu działa przez kilka dni, a potem wracają przekierowania, obce pliki albo spam w Google? Powtarzające się objawy wymagają sprawdzenia przyczyny. Samo usunięcie znalezionego pliku nie wyjaśnia, jak się tam dostał i czy ktoś nadal ma dostęp.

Ten poradnik dotyczy WordPressa i pomaga przygotować naprawę. W PrestaShop trzeba sprawdzić również moduły, konta zaplecza i integracje sklepu; nie należy przenosić poleceń WordPressa na inną aplikację.

Pomoc w naprawie strony po włamaniu

Czy infekcja rzeczywiście wróciła?

Zapisz konkretny adres, godzinę i objaw. Nowy plik na serwerze, nieznane konto administratora lub nowe przekierowanie to inny problem niż stary tytuł w wynikach wyszukiwania. Wyniki Google mogą nadal pokazywać ślady wcześniejszej infekcji, mimo że dana strona została usunięta. Sprawdź odpowiedź adresu i aktualną treść, a nie sam fragment wyniku.

W diagnozie pomagają porównania wejścia bezpośredniego i z wyszukiwarki oraz urządzeń, na których wystąpił problem. Nie otwieraj podejrzanych przekierowań na komputerze służącym do administracji. Więcej o rozróżnieniu objawów: japońskie znaki i spam SEO w Google.

Co może powodować nawrót?

  • Nieusunięta droga wejścia: podatna wtyczka, motyw albo komponent nadal działa po czyszczeniu.
  • Pozostawiony dostęp: dodatkowe konto, aktywna sesja lub nieprzejrzana integracja umożliwia kolejne zmiany.
  • Niepełny zakres naprawy: sprawdzono katalog główny, ale pominięto inne pliki, bazę, MU plugins lub zadania cykliczne.
  • Niewłaściwa kopia: przywrócony backup pochodzi już z okresu naruszenia.
  • Inne zainfekowane środowisko: stara kopia strony lub druga witryna na tym samym koncie wymaga sprawdzenia. To hipoteza do potwierdzenia, nie automatyczny dowód winy hostingu.

Najpierw zachowaj informacje

Przed masowym usuwaniem zabezpiecz kopię plików, bazy oraz dostępnych logów. Oznacz ją jako potencjalnie zainfekowaną i przechowuj poza publicznym katalogiem. Zanotuj wcześniejsze czyszczenie, aktualizacje i datę ostatniego znanego poprawnego działania. Jeżeli strona szkodzi odwiedzającym, uzgodnij z administratorem ograniczenie jej dostępności podczas naprawy.

W sklepie potrzebny jest osobny plan dla nowych zamówień i danych klientów. Przywrócenie starej bazy bez porównania zmian może utracić prawidłowe transakcje. Nie wykonuj przypadkowego odtwarzania „na próbę” na produkcji.

Co powinien objąć przegląd techniczny?

Administrator powinien porównać pliki z zaufanymi źródłami, przejrzeć użytkowników i role, konfigurację, bazę oraz harmonogram zadań. Ważna jest oś czasu: co pojawiło się po naprawie, a co istniało już wcześniej. Sam czas modyfikacji pliku ani pojedynczy wynik skanera nie rozstrzyga sprawy.

Na odizolowanej kopii WordPressa pomocna jest kontrola sum:

wp core verify-checksums --include-root
wp plugin verify-checksums --all

Pierwsze polecenie sprawdza pliki rdzenia względem sum WordPress.org. Drugie porównuje obsługiwane wtyczki z repozytorium. Dla wtyczek komercyjnych i własnych może nie być sum do porównania; ostrzeżenie nie oznacza automatycznie infekcji. Prawidłowy wynik nie sprawdza całej bazy, uploadów ani wszystkich dodatkowych plików. Nie dodawaj opcji wyłączającej sprawdzanie certyfikatów.

Na podejrzanej instalacji nie uruchamiaj przypadkowych skryptów ani narzędzi z uprawnieniami root. Kontrola wtyczek może ładować elementy WordPressa — pracuj na odpowiednio odizolowanej kopii i zachowaj materiał do analizy.

Jak zaplanować trwałą naprawę?

  1. Ustal zakres i zabezpiecz materiał do porównania.
  2. Odzyskaj zaufane pliki oraz usuń potwierdzone obce zmiany w danych i konfiguracji.
  3. Usuń przyczynę lub wyłącz komponent, którego nie da się bezpiecznie utrzymywać.
  4. Z zaufanego urządzenia uporządkuj konta i dostępy, zmień dotknięte poświadczenia oraz unieważnij odpowiednie sesje.
  5. Sprawdź działanie strony, formularzy i integracji; w sklepie także proces zamówienia na środowisku testowym.
  6. Obserwuj logi, zmiany plików i ponowne objawy. Zapisz zakres monitoringu oraz odpowiedzialność za aktualizacje i backup.

Co wysłać, zgłaszając problem?

Podaj domenę, objawy, datę poprzedniego czyszczenia, ostatnie zmiany i informację, czy masz kopie zapasowe. Nie przesyłaj haseł ani danych klientów w pierwszej wiadomości. Dostęp do naprawy ustalimy osobno. Jeżeli problem dotyczy nieaktualnego środowiska, sprawdzimy też możliwość aktualizacji PHP i aplikacji.

Zgłoś nawracającą infekcję. Zakres i koszt naprawy zależą od diagnozy; sam wygląd objawów nie pozwala obiecać pełnego oczyszczenia ani terminu odzyskania pozycji.

Źródła i dalsza lektura