Naprawa strony WordPress po ataku — case study i 3 opcje wyjścia

Telefon zadzwonił o 9:17 rano. Klientka — właścicielka małej kliniki rehabilitacyjnej — mówiła szybko, wyraźnie zdenerwowana: „Moja strona coś robi. Wyświetlają się na niej dziwne teksty po angielsku, a Google wyrzuca ostrzeżenie, że to strona niebezpieczna. Co to w ogóle jest?"

Wszedłem na adres. Zamiast schludnej strony wizytówki kliniki — chaos. Połowa menu nie działała, stopka była wypełniona dziesiątkami linków prowadzących na podejrzane kasyna i apteki internetowe, a w tytule strony widniał tekst: „Buy cheap Viagra online — best prices". Między treściami o rehabilitacji pojawiały się losowe paragrafy ze słowami kluczowymi o lekach na receptę. Google Search Console pokazywał alert z przed trzech tygodni — klientka przez ten czas do panelu nie zaglądała.

Strona stała bez aktualizacji od ponad dwóch lat. Wtyczki przestarzałe o kilkanaście wersji, motyw nieaktualizowany od 2022 roku, WordPress w wersji 5.9. Wystarczył jeden znany exploit w popularnej wtyczce formularzy — i boty zrobiły swoje w ciągu minut.

To nie jest wyjątkowy przypadek. Opisuję go szczegółowo, bo w ciągu ostatniego roku pomogłem naprawić osiem stron z podobnym scenariuszem. Mechanizm jest zawsze ten sam — i zawsze można go było przewidzieć.

Co właściwie się stało — anatomia ataku

Zanim przejdziemy do naprawy, warto zrozumieć jak działają takie ataki — bo wiedza ta zmienia sposób myślenia o utrzymaniu strony.

WordPress napędza około 43% wszystkich stron w internecie. To gigantyczna baza potencjalnych celów. Hakerzy nie siedzą przy klawiaturze i ręcznie nie szukają ofiar — uruchamiają zautomatyzowane boty, które bez przerwy skanują sieć w poszukiwaniu znanych podatności. Gdy tylko pojawia się publiczny raport o błędzie w popularnej wtyczce (a pojawiają się regularnie), boty mają nowe „zadanie" na liście.

W przypadku kliniki winowajcą okazała się wtyczka do formularzy kontaktowych — wersja z 2022 roku zawierała lukę klasy SQL injection umożliwiającą nieautoryzowane zapisywanie plików na serwerze. Łatka wyszła w ciągu 48 godzin od publicznego ujawnienia błędu. Strona klientki miała jeszcze tę starą wersję — i przez prawie dwa lata była otwarta na atak, który w końcu nastąpił.

Po udanym wejściu atakujący zainstalował tzw. backdoor — ukryty skrypt PHP, który pozwala na zdalne zarządzanie stroną nawet po usunięciu pierwotnej luki. Następnie wstrzyknął spam SEO (ang. SEO spam injection): ukryte linki i treści, niewidoczne dla zwykłego użytkownika, ale indeksowane przez Google. Cel? Przekazanie „mocy" strony kliniki na wskazane domeny — apteki, kasyna, strony z lekami.

Diagnoza: co dokładnie było uszkodzone

Pierwszym krokiem była pełna diagnoza. Korzystam przy tym ze sprawdzonego zestawu narzędzi:

1. Skan wtyczką Wordfence — identyfikacja zainfekowanych plików PHP, nieznanych plików w katalogach wtyczek i motywów, zmian w plikach rdzenia WordPress.
2. Przegląd bazy danych — wyszukanie wstrzykniętych skryptów i linków w tabelach wp_posts, wp_options i wp_usermeta.
3. Sprawdzenie Google Search Console — raport bezpieczeństwa pokazuje dokładnie które URL-e zostały oznaczone jako złośliwe i od kiedy.
4. Analiza pliku .htaccess — atakujący często modyfikują go, żeby przekierowywać ruch mobilny lub ruch z wyszukiwarek na swoje strony.
5. Lista użytkowników administracyjnych — sprawdzenie czy nie zostały dodane nieznane konta z rolą administratora.

W tym konkretnym przypadku znalazłem: 34 zainfekowane pliki PHP (w tym cztery ukryte backdoory w katalogu uploads/), 3 nieznane konta administratorów, ponad 2 000 wstrzykniętych wierszy w bazie danych z linkami i treściami SEO spam, zmodyfikowany plik .htaccess z regułami przekierowującymi użytkowników z urządzeń mobilnych, oraz kompletnie przestarzały stos: WordPress 5.9, PHP 7.4 (wspierany tylko przez 6 miesięcy po wydaniu PHP 8.1).

Skutki ataku — co traciła klientka każdego dnia

Warto to powiedzieć wprost, bo wiele osób bagatelizuje wycięty spam z „brzydkimi linkami": skutki trwają długo po samej naprawie.

• Utrata pozycji w Google — zainfekowana strona traci ranking, często na kluczowe lokalne frazy. Powrót do poprzednich pozycji może zająć 2–6 miesięcy nawet po pełnej naprawie.
• Alert Google Safe Browsing — przez kilka tygodni strona wyświetlała w wynikach wyszukiwania komunikat ostrzegawczy. Pacjenci, którzy trafiali na wizytówkę, natychmiast ją opuszczali. Odbicie od strony z alertem to 95%+ użytkowników.
• Zawieszone konto hostingowe — część hostingów automatycznie zawiesza strony rozsyłające spam. W tym przypadku hosting wysłał trzy ostrzeżenia e-mailem — klientka ich nie czytała, bo filtrowały do folderu spam.
• Reputacja marki — klienci przychodzący z polecenia wpisywali adres w Google i widzieli ostrzeżenie bezpieczeństwa. Kilku zadzwoniło pytając „czy ta klinika to pańska firma, bo chyba jest jakoś przejęta?".
• Naruszenie RODO — formularz kontaktowy zbierał dane osobowe pacjentów. Jeśli atakujący miał dostęp do bazy danych, mogło dojść do wycieku danych — co jest incydentem wymagającym zgłoszenia do UODO.

Naprawa strony WordPress — krok po kroku

Po diagnozie przyszedł czas na działanie. Oto dokładnie co zrobiłem:

1. Backup stanu przed naprawą — zawsze, nawet zainfekowaną stronę. Backup pozwala wrócić do konkretnego stanu jeśli coś pójdzie nie tak podczas naprawy, a dla kwestii prawnych dokumentuje zakres infekcji.
2. Zmiana wszystkich haseł i usunięcie nieznanych kont — hasło do wp-admin, FTP, bazy danych, panelu hostingu i e-maila powiązanego ze stroną. Trzy konta administratorów zostały usunięte.
3. Izolacja strony — tymczasowe ustawienie trybu maintenance i blokada zewnętrzna na poziomie .htaccess, żeby boty nie mogły dalej używać backdoorów w trakcie naprawy.
4. Czyszczenie zainfekowanych plików — ręczne usunięcie lub zastąpienie czystymi wersjami 34 zainfekowanych plików. Pliki rdzenia WordPress zastąpione świeżą kopią z oficjalnego repozytorium.
5. Czyszczenie bazy danych — usunięcie ponad 2 000 wierszy spamu. Sprawdzenie tabeli wp_options pod kątem nieznanych opcji z zewnętrznymi URL-ami.
6. Przywrócenie poprawnego .htaccess — zastąpienie zmodyfikowanego pliku czystą wersją wygenerowaną przez WordPress, a następnie dodanie reguł wzmacniających bezpieczeństwo.
7. Aktualizacja wszystkiego — WordPress do aktualnej wersji, wszystkie wtyczki, motyw. Usunięcie 4 wtyczek, które nie były aktualizowane od ponad roku i których autorzy porzucili projekt.
8. Wdrożenie zabezpieczeń — instalacja i konfiguracja Wordfence z firewallem, blokadą prób logowania, powiadomieniami e-mail o nieudanych logowaniach.
9. Aktualizacja PHP — migracja z PHP 7.4 na 8.2 na poziomie hostingu.
10. Zgłoszenie recenzji do Google Search Console — po wyczyszczeniu strony złożenie wniosku o usunięcie alertu bezpieczeństwa. Google usuwa flagę zazwyczaj w ciągu 1–7 dni od recenzji.

Łączny czas pracy: 11 godzin. Strona wróciła do działania po 18 godzinach od pierwszego telefonu. Alert Google zniknął po 4 dniach.

Trzy opcje dla właściciela strony WordPress — co wybrać

Gdy strona jest już wyczyszczona i działa, pojawia się pytanie strategiczne: co dalej, żeby to się nie powtórzyło? Są trzy drogi.

W przypadku kliniki rehabilitacyjnej wybraliśmy opcję B — opiekę serwisową. Strona ma formularz rezerwacji online, który wymaga PHP i jest regularnie modyfikowana przez właścicielkę. Całkowita migracja na static byłaby zbyt dużą zmianą w sposobie pracy.

Dla klientów, którzy mają stronę-wizytówkę z treściami rzadko zmienianymi — firmowy profil, landing page usługi, portfolio — opcja C jest coraz częściej moją pierwszą rekomendacją. Strona, którą czytasz właśnie teraz, to czysty statyczny HTML — bez CMS, bez wtyczek, bez ryzyka włamania do panelu administracyjnego.

Porównanie: WordPress vs strona statyczna pod kątem bezpieczeństwa

Aspekt	WordPress	Strona statyczna
Podatność na włamania CMS	Tak — wymaga aktualizacji	Nie dotyczy
Wymagane aktualizacje	Co 1–2 tygodnie	Brak
Panel edycji treści	Tak	Nie (wymagana edycja pliku)
Prędkość ładowania	Zależy od wtyczek i hostingu	Bardzo szybka
Koszt hostingu	60–200 zł/rok (z PHP i MySQL)	Nawet bezpłatny (GitHub Pages, Netlify)
Koszt utrzymania	150–400 zł/miesiąc (opieka) lub własny czas	Minimalny
Sklep internetowy	Tak (WooCommerce)	Ograniczony (Stripe, zewnętrzny koszyk)
Blog z CMS	Tak	Nie bez SSG (Jekyll, Hugo, Eleventy)

Jak działające serwisowanie WordPress powinno wyglądać

Jeśli zostajesz przy WordPressie — niezależnie czy robisz to sam, czy zlecasz — oto minimum, które musi być zrobione regularnie. To nie jest lista „fajnych rzeczy do zrobienia". To lista rzeczy, których brak skończył się atakiem u klientki.

• Aktualizacja rdzenia WordPress — co najmniej raz w miesiącu, krytyczne łatki bezpieczeństwa — w ciągu 48 godzin od wydania
• Aktualizacja wszystkich wtyczek i motywu — co 1–2 tygodnie
• Codzienny automatyczny backup plików i bazy danych — przechowywany poza serwerem (np. Google Drive, Dropbox lub dedykowane usługi jak ManageWP czy MainWP)
• Testy przywrócenia z backupu — raz na kwartał. Backup który nigdy nie był testowany to nie backup
• Monitoring dostępności strony — alerty e-mail lub SMS gdy strona przestaje odpowiadać (np. UptimeRobot w wersji bezpłatnej sprawdza co 5 minut)
• Skan złośliwego oprogramowania — tygodniowy lub po każdej aktualizacji
• Monitorowanie Google Search Console — szczególnie zakładka Bezpieczeństwo i ręczne działania
• Weryfikacja listy użytkowników administracyjnych — raz na miesiąc
• Aktualna wersja PHP — minimum PHP 8.1, optymalnie 8.2 lub 8.3
• Usunięcie nieużywanych wtyczek i motywów — nawet dezaktywowane mogą zawierać podatności

Kiedy nie warto naprawiać — i lepiej zacząć od zera

Są sytuacje, w których naprawa zainfekowanej strony jest droższa i mniej bezpieczna niż reinstalacja od zera. Oto kiedy rekomendowałem klientom nową instalację zamiast czyszczenia:

• Infekcja jest rozległa i obejmuje setki plików — ryzyko przeoczenia ukrytego backdoora jest zbyt wysokie
• Strona działa na PHP 7.x lub starszym — czas na modernizację stosu technicznego
• Nie ma żadnych backupów z okresu przed infekcją — nie wiadomo od kiedy trwa problem
• Atakujący miał dostęp przez kilka miesięcy — trudno ocenić pełny zakres zmian
• Właściciel strony chce przy okazji odświeżyć design lub zmienić hosting

W takim przypadku najlepszym podejściem jest: wyeksportowanie samej treści (posty, strony, dane kontaktowe) z bazy danych do czystego pliku XML, a następnie zaimportowanie jej na świeżej instalacji WordPress na nowym lub wyresetowanym hostingu. Motyw i wtyczki instalujemy od zera z oficjalnych repozytoriów.

Koszt naprawy vs koszt serwisowania — prosta matematyka

Klientka zapłaciła za naprawę 1 800 zł. Do tego doliczyć trzeba utratę ruchu organicznego przez kilka tygodni — jej strona w trakcie ataku nie przynosiła nowych pacjentów z Google. Szacunkowo przez 4 tygodnie obecności alertu straciła 8–12 zapytań online, które przy jej cennikach to 2 400–3 600 zł utraconych przychodów.

Całkowity koszt incydentu (naprawa + utracone przychody): 4 200–5 400 zł.

Koszt rocznej opieki serwisowej, która by temu zapobiegła: 2 400 zł (200 zł/miesiąc).

Serwisowanie WordPress to nie koszt — to ubezpieczenie. I jak większość ubezpieczeń, żałujesz że go nie miałeś dopiero gdy coś się stanie.

Co powinieneś zrobić teraz

Jeśli masz stronę WordPress i nie wiesz kiedy ostatnio była aktualizowana — sprawdź to dzisiaj. Zaloguj się do wp-admin i zerknij na listę wtyczek. Jeśli przy którejkolwiek widzisz komunikat „dostępna aktualizacja" i data ostatniej aktualizacji jest starsza niż miesiąc — jesteś w grupie ryzyka.

Trzy kroki do zrobienia teraz:

1. Sprawdź Google Search Console — zakładka Bezpieczeństwo i ręczne działania. Brak alertów to dobra wiadomość. Jeśli ich tam nie ma, sprawdź kiedy ostatnio się logowałeś — brak alertów które widzisz to nie to samo co brak alertów które zostały wysłane.
2. Zrób backup teraz — nawet UpdraftPlus w wersji bezpłatnej to coś. Backup na ten sam hosting gdzie strona to minimum; lepiej od razu skonfigurować eksport do Google Drive lub Dropbox.
3. Zaktualizuj wszystko — WordPress, wtyczki, motyw. Zrób to na backupie, nie na żywej stronie. Jeśli nie wiesz jak — to dobry moment żeby zastanowić się nad opcją B.

Podsumowanie — WordPress wymaga opieki

WordPress to doskonałe narzędzie — elastyczne, popularne i z ogromnym ekosystemem wtyczek. Ale ta popularność ma cenę: jest najczęściej atakowanym CMS-em na świecie. Nie ma czegoś takiego jak „zainstalowałem i zapomniałem" w przypadku WordPressa.

Masz trzy drogi: pilnować aktualizacji samemu, zlecić to specjaliście, albo rozważyć migrację na prostszą platformę jeśli Twoje potrzeby są skromne. Każda z nich jest lepsza niż brak działania.

Klientka z początku tego artykułu dziś ma aktualnego WordPressa, codzienne backupy i miesięczny raport z opieki serwisowej. Jej strona ładuje się szybciej, Google Search Console jest czyste, a ona sama może skupić się na rehabilitacji pacjentów zamiast zastanawiać się co wyświetla jej witryna.

Taki powinien być stan domyślny — nie wyjątek.

---