Zainfekowana strona WordPress: objawy i co zrobić w pierwszej godzinie

Zainfekowany WordPress najczęściej zdradza się przekierowaniami na obce strony, nieznanymi kontami administratorów, spamem w wynikach Google i ostrzeżeniami od hostingu lub przeglądarki. W pierwszej godzinie nie kasuj plików na ślepo: udokumentuj objawy, zrób kopię do analizy, odetnij ruch, zmień hasła z czystego komputera i zabezpiecz logi.

Po czym poznać, że WordPress jest zainfekowany?

Pojedynczy objaw nie przesądza sprawy, ale dwa lub trzy naraz to już mocny sygnał. Pamiętaj, że złośliwy kod często ukrywa się przed zalogowanymi użytkownikami. Rapid7 opisał w 2026 r. wstrzyknięcia, które sprawdzały ciasteczka sesji WordPressa i nie pokazywały się administratorom, dlatego wiele infekcji zgłaszają najpierw klienci.

Dokumentacja WordPress.org dopisuje do tej listy jeszcze dwa sygnały: antywirusy odwiedzających blokują stronę albo ktoś informuje, że Twój serwer atakuje inne witryny. Każdy z objawów ma osobny tok postępowania. Fałszywe weryfikacje opisuję w tekście o ClickFix, fałszywe aktualizacje w tekście o SocGholish, a spam w wynikach wyszukiwania we wpisie o japońskim spamie SEO i przekierowaniach.

Dlaczego WordPress w ogóle zostaje zainfekowany?

Rdzeń WordPressa jest dziś rzadko problemem. Według raportu Patchstack w 2025 r. zgłoszono w ekosystemie 11 334 nowe podatności, o 42% więcej niż rok wcześniej. 91% dotyczyło wtyczek, 9% motywów, a w samym rdzeniu było ich sześć, wszystkie o niskim priorytecie.

Czas na reakcję jest krótki. Patchstack podaje, że dla najczęściej atakowanych podatności ważona mediana czasu do pierwszego exploita wynosi 5 godzin, a mniej więcej połowa podatności o wysokim wpływie jest wykorzystywana w ciągu doby. W testach Patchstack typowe zabezpieczenia hostingu zablokowały tylko 26% ataków.

Drugą drogą są hasła. GoDaddy opisał w 2024 r. ponad 6000 stron, na które przestępcy weszli z prawidłowymi danymi administratora i wgrali fałszywe wtyczki. Hasła pochodzą z wycieków, ataków słownikowych albo z infostealerów na komputerach osób zarządzających stroną.

Co zrobić w pierwszej godzinie po wykryciu infekcji?

Pierwsza godzina nie służy do sprzątania. Masz opanować sytuację: zatrzymać szkody dla odwiedzających, odciąć atakującego i zachować ślady, bez których nie ustalisz, jak wszedł. Podział na minuty jest orientacyjny, liczy się kolejność.

Minuty 0–10: zapisz, co widzisz

• Zanotuj objawy, godzinę ich zauważenia i strefę czasową. Tak zaczyna też procedurę dokumentacja WordPress.org.
• Zrób zrzuty ekranu przekierowań, ostrzeżeń, nieznanych kont i maili od hostingu.
• Zapisz, co zmieniało się ostatnio: nowe wtyczki, aktualizacje, nowe osoby z dostępem.
• Nie usuwaj niczego i nie przywracaj kopii zapasowej. Oba kroki niszczą ślady.

Minuty 10–20: zrób kopię do analizy

Najpierw sprawdź, czy hosting pozwala wykonać migawkę konta. Jeśli nie, zrób kopię ręcznie i zapisz ją poza katalogiem publicznym:

# Pliki strony (z datami modyfikacji) poza katalogiem publicznym
tar -czf ~/incydent-$(date +%F-%H%M)-pliki.tar.gz -C /sciezka/do public_html

# Zrzut bazy danych bez uruchamiania kodu wtyczek i motywu
wp db export ~/incydent-$(date +%F-%H%M)-baza.sql --path=/sciezka/do/public_html --skip-plugins --skip-themes

# Sumy kontrolne, żeby później wykazać, że kopia nie była zmieniana
sha256sum ~/incydent-*

Minuty 20–35: odetnij ruch i atakującego

Przerwę techniczną ustaw na poziomie serwera, a nie wtyczką w zainfekowanym WordPressie. Na Apache wystarczy reguła na początku pliku .htaccess, która zwraca kod 503 wszystkim poza Twoim adresem IP:

RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^203\.0\.113\.10$
RewriteRule ^ - [R=503,L]

Podmień przykładowy adres na swój. Kod 503 informuje roboty wyszukiwarek, że przerwa jest chwilowa. Potem, z komputera, co do którego masz pewność, że jest czysty:

• zmień hasło do panelu hostingu i włącz w nim MFA;
• zmień hasła SFTP/SSH i usuń klucze SSH, których nie znasz;
• zmień hasło użytkownika bazy danych i wpisz nowe do wp-config.php;
• usuń nieznanych administratorów, zmień hasła pozostałych i skasuj ich hasła aplikacji;
• wygeneruj nowe klucze i sole (wp config shuffle-salts), co wyloguje wszystkie sesje.

Po wyczyszczeniu strony zmień hasła jeszcze raz. Dokumentacja WordPress.org zaleca to wprost, bo pierwsza zmiana następuje, gdy backdoor może jeszcze działać.

Minuty 35–50: zabezpiecz logi i ustal zakres

• Pobierz logi dostępu i błędów serwera WWW, logi FTP i historię logowań do panelu. Hostingi rotują je automatycznie, więc później może ich już nie być.
• Wyszukaj w logach żądania POST do wp-login.php i xmlrpc.php, wgrywanie wtyczek oraz odwołania do plików PHP w uploads.
• Uruchom wp core verify-checksums i sprawdź listę plików zmienionych w ostatnich tygodniach (find . -type f -mtime -30).
• Sprawdź inne strony na tym samym koncie hostingowym. Dokumentacja WordPress.org przypomina, że zwłaszcza na hostingu współdzielonym włamanie może objąć więcej niż jedną witrynę.
• Zajrzyj do raportu „Problemy dotyczące bezpieczeństwa” w Search Console, żeby zobaczyć, co widzi Google.
• Ustal, czy strona przetwarza dane osobowe: formularze, konta klientów, zamówienia.

Minuty 50–60: zdecyduj, kto i jak sprząta

Masz już kopię, logi, odcięty ruch i nowe hasła. Teraz oceń, czy dasz radę wyczyścić stronę sam, i poinformuj osoby, których to dotyczy: wspólnika, dział obsługi klienta, hosting. Jeśli w grę wchodzą dane osobowe, uruchom procedurę RODO. UODO przypomina, że zgłoszenie naruszenia powinno nastąpić nie później niż w terminie 72 godzin od jego stwierdzenia.

Czego nie robić po wykryciu włamania?

• Nie kasuj całej strony w panice. Stracisz dowody i często treści, których nie ma w żadnej kopii.
• Nie przywracaj od razu starej kopii. Wróci ta sama podatność, a kopia mogła powstać już po włamaniu.
• Nie instaluj pięciu wtyczek bezpieczeństwa naraz. Działają wewnątrz zainfekowanej instalacji i wprowadzają kolejne zmiany do analizy.
• Nie zmieniaj haseł z komputera, który mógł być źródłem wycieku.
• Nie proś Google o ponowne sprawdzenie, zanim skończysz. Odrzucona prośba wydłuża cały proces.

Jak wyczyścić stronę po pierwszej godzinie?

Sprzątanie to osobny etap, który zależy od rodzaju infekcji. Ogólny schemat, zgodny z zaleceniami WordPress.org, wygląda tak:

1. Zastąp katalogi wp-admin i wp-includes czystą kopią tej samej wersji WordPressa.
2. Wgraj ponownie wtyczki i motyw z oficjalnych źródeł, usuń wszystko, czego nie używasz.
3. Przejrzyj pliki, które najczęściej są modyfikowane: .htaccess (także w podkatalogach), index.php, header.php, footer.php, functions.php, wp-config.php.
4. Znajdź backdoory. To one sprawiają, że infekcja wraca po „wyczyszczeniu”. Typowe wzorce opisuję w tekście o backdoorach i web shellach PHP.
5. Wyczyść bazę danych ze wstrzykniętych skryptów, spamowych wpisów i obcych opcji.
6. Zaktualizuj wszystko, zmień hasła drugi raz, włącz MFA i ogranicz dostęp do panelu.
7. Zdejmij przerwę techniczną, sprawdź stronę z zewnątrz i obserwuj logi przez kolejne tygodnie.
8. Jeśli Google oznaczył stronę, poproś o ponowne sprawdzenie. Proces opisuję we wpisie o ostrzeżeniu Google „strona niebezpieczna”.

Kiedy wezwać specjalistę od bezpieczeństwa?

Część infekcji właściciel z doświadczeniem technicznym posprząta sam. Pomoc z zewnątrz ma sens, gdy:

• strona to sklep lub przetwarza dane osobowe i musisz wiedzieć, czy dane wyciekły;
• infekcja wróciła po samodzielnym czyszczeniu;
• nie masz dostępu SSH, kopii zapasowych ani logów, a hosting zablokował konto;
• na jednym serwerze działa kilka stron i nie wiesz, która była pierwsza;
• widzisz ślady na poziomie serwera: nieznane procesy, zadania cron, konta systemowe;
• potrzebujesz udokumentowanej analizy dla ubezpieczyciela, klienta lub UODO.

W takich sytuacjach liczy się czas i kolejność działań. Jeśli potrzebujesz wsparcia przy incydencie, napisz lub zadzwoń, pomożemy opanować sytuację i ustalić, jak doszło do włamania.