WordPress po włamaniu: co zrobić w pierwszych 24 godzinach

Po czym poznać, że strona jest zhakowana?

Najczęstsze objawy, z którymi przychodzą do nas właściciele małych firm:

• strona przekierowuje na obce adresy, często tylko na telefonie albo tylko dla osób wchodzących z Google,
• w wynikach Google pod Twoją domeną pojawiają się obce tytuły, na przykład w innym języku,
• przeglądarka pokazuje czerwone ostrzeżenie o niebezpiecznej stronie,
• w panelu WordPressa są konta administratorów, których nikt nie zakładał,
• hosting przysłał informację o blokadzie konta albo o rozsyłaniu spamu z Twojego serwera.

Jeśli widzisz choć jeden z tych objawów, potraktuj stronę jak zainfekowaną, dopóki nie sprawdzisz, że jest inaczej.

Godzina 0–1: zatrzymaj szkody i zabezpiecz dowody

Zapisz, co widzisz

Oficjalny poradnik WordPress.org zaczyna od dokumentacji. Zapisz, co się dzieje, kiedy to zauważyłeś i jakie zmiany robiłeś ostatnio na stronie: nowa wtyczka, nowy motyw, zmiana w ustawieniach. Zrób zrzuty ekranu. Te informacje skrócą szukanie przyczyny.

Zrób kopię obecnego stanu

Skopiuj pliki i bazę danych w obecnym, zainfekowanym stanie. Brzmi dziwnie, ale ta kopia jest potrzebna: pozwala ustalić, co zmienili włamywacze, i chroni przed utratą danych, jeśli czyszczenie pójdzie źle. Zapisz ją poza serwerem i opisz jako zainfekowaną, żeby nikt jej przypadkiem nie przywrócił.

Skontaktuj się z hostingiem

Na hostingu współdzielonym włamanie może dotyczyć też innych stron na Twoim koncie. Hosting potwierdzi, czy to włamanie, czy awaria, i często ma własne narzędzia do skanowania oraz kopie z poprzednich dni.

Rozważ tymczasowe wyłączenie strony

Jeśli strona przekierowuje klientów na podejrzane adresy, lepiej pokazać przez kilka godzin komunikat o pracach technicznych niż narażać odwiedzających.

Godzina 1–3: hasła i dostępy

WordPress.org zaleca zmianę haseł we wszystkich punktach dostępu: FTP lub SFTP, panel WordPressa, panel hostingu i baza danych MySQL. Dodajmy do tego pocztę, bo część włamań zaczyna się od przejętej skrzynki.

Kolejność ma znaczenie:

1. Przeskanuj swój komputer programem antywirusowym. Poradnik WordPress.org zwraca uwagę, że hasła mogły zostać wykradzione z zainfekowanego komputera, z którego logujesz się do strony. Zmiana haseł na takim komputerze nic nie da.
2. Zmień hasło do panelu hostingu i poczty.
3. Zmień hasła FTP i bazy danych. Po zmianie hasła bazy zaktualizuj je w pliku wp-config.php, inaczej strona przestanie działać.
4. Zmień hasła wszystkich administratorów WordPressa i usuń konta, których nie znasz. Zapisz ich nazwy i daty utworzenia, przydadzą się do ustalenia przyczyny.
5. Wygeneruj nowe klucze bezpieczeństwa w wp-config.php. WordPress udostępnia generator pod adresem api.wordpress.org/secret-key/1.1/salt/. Nowe klucze wylogowują wszystkie aktywne sesje, także włamywacza.
6. Włącz logowanie dwuetapowe dla administratorów. Zaleca je zarówno poradnik o włamaniach, jak i oficjalna instrukcja zabezpieczania WordPressa.

Godzina 3–12: czyszczenie albo przywrócenie kopii

Masz dwie drogi.

Droga 1: przywrócenie czystej kopii

Jeśli masz kopię zapasową sprzed włamania i wiesz, kiedy do niego doszło, przywrócenie jej bywa najszybsze. Warunek: kopia musi być naprawdę sprzed infekcji, a zaraz po przywróceniu trzeba zaktualizować WordPressa, motyw i wtyczki. Luka, przez którą weszli włamywacze, nadal istnieje w przywróconej wersji.

Jeśli nie masz kopii albo nie wiesz, czy jest czysta, przeczytaj potem tekst Kopie zapasowe strony: zasada 3-2-1 i test odtworzenia. Następnym razem oszczędzi Ci to wielu godzin.

Droga 2: ręczne czyszczenie

Ręczne czyszczenie zaczyna się od plików WordPressa. Narzędzie wiersza poleceń WP-CLI ma polecenie `wp core verify-checksums`, które porównuje pliki rdzenia z sumami kontrolnymi pobranymi z WordPress.org i pokazuje każdy zmieniony plik.

Poradnik WordPress.org zaleca ponowne wgranie rdzenia WordPressa w tej samej wersji przez FTP lub SFTP. Katalogi wp-admin i wp-includes można w ten sposób bezpiecznie podmienić. Poradnik wprost odradza do tego opcję ponownej instalacji w panelu WordPressa.

Potem sprawdź miejsca, które włamywacze modyfikują najczęściej:

• plik .htaccess (przekierowania),
• index.php w katalogu głównym,
• pliki motywu: header.php, footer.php, functions.php,
• katalog uploads, w którym nie powinno być plików PHP,
• listę wtyczek, także tych wyłączonych,
• tabelę użytkowników i opcje w bazie danych.

Wtyczki i motywy najlepiej usunąć i wgrać od nowa z oficjalnego źródła, zamiast czyścić je plik po pliku. Wtyczki, których nie używasz, po prostu usuń.

Godzina 12–24: aktualizacje, zabezpieczenie i Google

Zaktualizuj wszystko

Gdy strona jest czysta, zaktualizuj WordPressa, motyw i wtyczki do najnowszych wersji. Oficjalna instrukcja zabezpieczania WordPressa przypomina, że starsze wersje nie dostają poprawek bezpieczeństwa. Po aktualizacji zmień hasła jeszcze raz.

Zamknij drogę, którą przyszedł atak

Samo czyszczenie nie wystarczy. Trzeba ustalić, jak włamywacze weszli, inaczej wrócą tą samą drogą. W małych firmach to zwykle:

• nieaktualna wtyczka albo motyw ze znaną luką,
• słabe lub wykradzione hasło administratora,
• zapomniana kopia starej strony w katalogu na tym samym hostingu.

Przy okazji wprowadź podstawowe zabezpieczenia z oficjalnej instrukcji WordPressa: wyłącz edycję plików z panelu stałą `DISALLOW_FILE_EDIT`, ustaw właściwe uprawnienia plików i katalogów, używaj SFTP zamiast FTP.

Sprawdź pocztę

Jeśli z serwera wychodził spam, Twoja domena mogła trafić na listy blokujące, a maile od Ciebie mogą lądować w spamie u klientów. Jak to sprawdzić i jak ustawić SPF, DKIM i DMARC, opisujemy w tekście Poczta firmowa we własnej domenie.

Poproś Google o ponowne sprawdzenie

Jeśli Google oznaczył stronę jako zhakowaną, w Google Search Console, w raporcie „Problemy dotyczące bezpieczeństwa”, zobaczysz szczegóły i przykładowe adresy. Według poradnika Google na web.dev przed prośbą o sprawdzenie musisz mieć zweryfikowaną stronę w Search Console, oczyścić ją, naprawić lukę i przywrócić czystą stronę do sieci.

W prośbie opisz, co dokładnie zrobiłeś, na przykład: „usunąłem wstrzyknięte strony ze spamem i zaktualizowałem nieaktualną wtyczkę, przez którą doszło do włamania”.

Ile to trwa według Google:

Google zaznacza, że nie należy wysyłać kolejnej prośby, zanim nie przyjdzie decyzja w sprawie poprzedniej. Gdy strona zostanie uznana za czystą, ostrzeżenia znikają w ciągu 72 godzin.

Czego nie robić?

• Nie kasuj plików na podstawie samej nazwy. Możesz zepsuć stronę, a złośliwy kod zostanie w innym miejscu.
• Nie instaluj kilku wtyczek bezpieczeństwa naraz. Spowolnią stronę, a nie usuną tylnych furtek, które już są w plikach.
• Nie przywracaj kopii bez aktualizacji. Włamanie powtórzy się tą samą drogą.
• Nie proś Google o sprawdzenie za wcześnie. Odrzucona prośba wydłuża czas rozpatrzenia następnej.

Jak nie dopuścić do kolejnego włamania?

Po opanowaniu sytuacji zrób krótką listę stałych nawyków. Wszystkie wynikają z oficjalnej instrukcji zabezpieczania WordPressa:

• aktualizacje WordPressa, motywu i wtyczek co tydzień, nie raz na pół roku,
• usunięcie wtyczek i motywów, których nie używasz,
• silne, unikalne hasła i logowanie dwuetapowe dla każdego administratora,
• kopie zapasowe zapisywane poza serwerem i co jakiś czas testowo odtwarzane,
• SFTP zamiast FTP i wyłączona edycja plików z panelu.

Jeśli nie masz czasu pilnować tego samodzielnie, zleć to komuś na stałe. Regularna opieka kosztuje zwykle mniej niż jedno porządne czyszczenie strony.

Kiedy oddać to specjaliście?

Jeśli strona przekierowuje klientów, Google pokazuje ostrzeżenie albo hosting zablokował konto, każdy dzień kosztuje Cię klientów. Ręczne czyszczenie bez doświadczenia często zostawia ukryte furtki i włamanie wraca po kilku dniach. Koszt profesjonalnej naprawy porównaj z kosztem regularnej opieki, o czym piszemy w tekście Ile kosztuje strona firmowa przez 3 lata.

Źródła

• WordPress.org, FAQ My site was hacked, wordpress.org/documentation/article/faq-my-site-was-hacked/, dostęp 2.11.2026
• WordPress.org, Hardening WordPress, developer.wordpress.org/advanced-administration/security/hardening/, dostęp 2.11.2026
• WP-CLI, wp core verify-checksums, developer.wordpress.org/cli/commands/core/verify-checksums/, dostęp 2.11.2026
• Google, Request a review (web.dev), web.dev/articles/request-a-review, dostęp 2.11.2026
• Google, Raport „Problemy dotyczące bezpieczeństwa”, support.google.com/webmasters/answer/9044101, dostęp 2.11.2026