Mój WordPress został zhakowany — co teraz?

Telefon dzwoni o 7 rano: „Franek, moja strona przekierowuje na jakieś kasyno”. Albo dostajesz maila od Google, że Twoja witryna „może być niebezpieczna”. Pierwsza reakcja to panika — i właśnie ona każe ludziom robić rzeczy, które tylko pogarszają sprawę. Ten poradnik to spokojny, uporządkowany plan: co robić, w jakiej kolejności i czego absolutnie nie kasować, zanim zabezpieczysz dowody.

Jeśli wolisz zapobiegać niż leczyć, zacznij od poradnika o hartowaniu WordPressa. Ale skoro już tu jesteś — działajmy.

Najpierw: czy to na pewno włamanie?

Zanim wpadniesz w panikę, upewnij się, że to faktycznie atak, a nie awaria wtyczki. Typowe objawy realnego włamania:

• Przekierowania — strona (zwłaszcza z wyników Google albo na telefonie) odbija na obce domeny: kasyna, „leki”, pornografię.
• Spam w treści — w stopce, w nowych wpisach albo „ukryty” tekst pojawiają się linki do podejrzanych stron (tzw. SEO spam).
• Ostrzeżenie Google / przeglądarki — czerwony ekran „Strona wprowadzająca w błąd” albo komunikat w Search Console „Wykryto złośliwe oprogramowanie”.
• Nieznane konta administratora — w Użytkownicy widzisz login, którego nie tworzyłeś.
• Podejrzane pliki — dziwne .php w katalogu głównym albo w wp-content/uploads (np. wp-x3f.php, class-wp-loader.php).
• Strona zżera zasoby — hosting przysyła ostrzeżenie o przekroczeniu CPU (zhakowany WP często rozsyła spam albo kopie kryptowaluty).

Jeśli przynajmniej jeden z tych objawów pasuje — traktuj to jak włamanie. Lepiej przesadzić z ostrożnością.

Pierwsze 15 minut — opanuj sytuację

Cel tej fazy nie brzmi „naprawić wszystko”, tylko zatrzymać krwawienie i zabezpieczyć dowody. Po kolei.

1. Włącz tryb konserwacji (offline)

Nie chcesz, żeby zainfekowana strona dalej szkodziła odwiedzającym i Twojemu SEO. Najprościej — wgraj do katalogu głównego plik .maintenance:

<?php $upgrading = time(); ?>

WordPress pokaże wtedy komunikat „Strona w trakcie konserwacji”. Alternatywnie zablokuj ruch z zewnątrz w .htaccess, dopuszczając tylko swoje IP:

Order Deny,Allow
Deny from all
Allow from TWOJE.IP.TU.XXX

2. Zrób kopię AKTUALNEGO, zainfekowanego stanu

To brzmi nielogicznie — „po co mi kopia zawirusowanej strony?” — ale to najważniejszy krok w całym procesie. Zrób pełny zrzut plików (przez FTP/SFTP albo tar) i bazy danych, zanim cokolwiek usuniesz.

# Pliki
tar -czf ~/dowod-pliki-$(date +%F).tar.gz public_html/

# Baza (dane do logowania weź z wp-config.php)
mysqldump -u USER -p BAZA > ~/dowod-baza-$(date +%F).sql

3. Zmień wszystkie hasła i sole

Zakładaj, że atakujący zna wszystkie Twoje hasła. Zmień:

• hasła wszystkich kont administratora WordPressa,
• hasło do bazy danych (i zaktualizuj je w wp-config.php),
• hasła FTP/SFTP i konta hostingowego (DirectAdmin/cPanel),
• sole w wp-config.php — wygeneruj nowe na api.wordpress.org/secret-key i podmień cały blok define('AUTH_KEY', ...).

Zmiana soli wyloguje wszystkich — w tym intruza, który ma aktywną sesję. O to chodzi.

Diagnoza — gdzie się ukrył

Masz kopię, zmieniłeś hasła, strona jest offline. Teraz spokojnie szukamy, co i gdzie zostało podmienione.

Sprawdź integralność plików core

WordPress udostępnia oficjalne sumy kontrolne każdego pliku. Jedno polecenie WP-CLI pokaże, które pliki rdzenia zostały podmienione:

wp core verify-checksums

Każda linia typu Warning: File doesn't verify against checksum: wp-load.php to czerwona flaga — ktoś dopisał kod do pliku WordPressa.

Poluj na webshelle w uploads

Folder wp-content/uploads powinien zawierać tylko media — zdjęcia, PDF-y. Żaden plik .php nie ma prawa tam być:

find wp-content/uploads -name "*.php" -o -name "*.phtml" -o -name "*.phar"

Jeśli cokolwiek znajdzie — to niemal na pewno webshell. Druga przydatna komenda szuka klasycznych „flag” złośliwego kodu:

grep -rEl "eval\s*\(|base64_decode|gzinflate|str_rot13|assert\s*\(" wp-content/ --include="*.php"

Sprawdź bazę: siteurl, home i ukryte konta admin

Klasyk: atakujący podmienia adres strony, żeby przekierować ruch. Sprawdź tabelę wp_options:

SELECT option_name, option_value FROM wp_options
WHERE option_name IN ('siteurl', 'home');

Jeśli widzisz tam obcą domenę — to źródło przekierowań. Następnie poszukaj ukrytych administratorów:

SELECT u.ID, u.user_login, u.user_email
FROM wp_users u
JOIN wp_usermeta m ON u.ID = m.user_id
WHERE m.meta_key = 'wp_capabilities'
AND m.meta_value LIKE '%administrator%';

Każde konto, którego nie rozpoznajesz — do usunięcia. Zajrzyj też do tabeli wp_users po wpisy z datą rejestracji z okresu włamania.

Czyszczenie — krok po kroku

Teraz właściwa robota. Najbezpieczniejsza zasada: nie leczyć pojedynczych plików, tylko podmienić je na czyste.

Element	Co zrobić
Rdzeń WordPressa	Skasuj wp-admin/ i wp-includes/, wgraj świeże z wordpress.org (ta sama wersja). Najprościej: wp core download --force.
Wtyczki	Usuń wszystkie i zainstaluj na nowo z oficjalnego repozytorium. Płatne — pobierz od autora, nie z „darmowych” paczek (częste źródło infekcji).
Motyw	To samo: czysta kopia od autora. Zmiany w functions.php nanieś ręcznie po weryfikacji.
uploads	Usuń znalezione pliki .php. Mediów (zdjęć) zwykle nie ruszamy.
Pliki w root	Sprawdź index.php, wp-config.php, .htaccess — czy nie dopisano kodu na początku/końcu.
Baza	Usuń obce konta admin, napraw siteurl/home, przejrzyj wp_options pod kątem dziwnych autoload-ów i wpisy wp_posts ze spamem.

Po czyszczeniu jeszcze raz uruchom wp core verify-checksums i skan (np. wtyczką Wordfence albo skanerem hostingu) — żeby potwierdzić, że jest czysto.

Najszybsza droga: czysty backup

Jeśli masz kopię zapasową sprzed włamania (i pewność, że jest czysta) — przywrócenie jej bywa szybsze i pewniejsze niż ręczne dłubanie. Ale uwaga na dwie pułapki:

1. Kiedy nastąpiło włamanie? Jeśli infekcja siedziała tygodniami, „świeży” backup też może być zarażony. Cofnij się do kopii sprzed pierwszych objawów.
2. Dziura nadal istnieje. Backup przywraca też podatność, którą weszli. Bez hardeningu (niżej) zhakują Cię ponownie w kilka dni.

Po przywróceniu i tak zmień wszystkie hasła i sole — backup ma w sobie stare.

Po incydencie — żeby się nie powtórzyło

Sprzątnięte? Świetnie. Teraz najważniejsza część, którą większość ludzi pomija: zamknięcie drzwi, którymi weszli. Pełny plan opisałem w osobnym tekście — jak naprawdę zabezpieczyć WordPressa — ale minimum to:

• Aktualizacje rdzenia, wtyczek i motywów (przestarzała wtyczka to przyczyna #1).
• 2FA dla każdego administratora.
• Blokada PHP w wp-content/uploads — jedna reguła .htaccess, która neutralizuje większość webshelli.
• DISALLOW_FILE_EDIT w wp-config.php.
• Backupy poza serwerem + monitoring integralności (cron z verify-checksums).
• Rozważ Cloudflare przed WordPressem — za darmo odetnie sporo ruchu botów, zanim dotrze do serwera.

Na koniec poproś Google o ponowne sprawdzenie strony w Search Console (Bezpieczeństwo → Problemy z bezpieczeństwem → Poproś o sprawdzenie), żeby zdjąć ostrzeżenie z wyników.

Kiedy oddać to specjaliście

Zrób to sam, jeśli masz jedną stronę, kopię dowodową i czujesz się pewnie w terminalu. Wezwij pomoc, gdy:

• infekcja wraca po każdym czyszczeniu (to znak, że został ukryty backdoor albo zarażonych jest więcej stron na koncie),
• masz na hostingu wiele witryn i nie wiesz, która jest źródłem,
• wyciekły dane osobowe klientów (kwestia RODO i terminów zgłoszenia),
• po prostu nie chcesz ryzykować, że coś przeoczysz.

Jeśli Twój WordPress oberwał i potrzebujesz kogoś, kto spokojnie go posprząta, znajdzie dziurę i zahartuje stronę na przyszłość — napisz do mnie. Im szybciej, tym mniej szkód.