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.

Dlaczego właśnie SEO spam? Strona kliniki działała kilka lat, miała pewną historię i autorytet w Google. Atakujący wykorzystują ten autorytet jak „pożyczkę" - i ta pożyczka kosztuje właściciela strony utratę pozycji w wyszukiwarce, flagowanie przez Google i potencjalne kary algorytmiczne trwające miesiącami.

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).

Ważne: Sam skan wtyczką to za mało. Wordfence i podobne narzędzia dobrze wykrywają znane sygnatury złośliwego kodu, ale zaawansowane backdoory mogą być skonstruowane tak, żeby wyglądały jak legalne funkcje PHP. Pełna diagnoza wymaga ręcznego przeglądu podejrzanych plików.

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.

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.

Opcja A
Serwisowanie samodzielnie (DIY)

Regularnie sam aktualizujesz WordPress, wtyczki i motyw. Monitorujesz Google Search Console. Wykonujesz backupy.

  • Bezpłatne poza czasem
  • Pełna kontrola
  • Wymaga regularności - minimum raz na 2 tygodnie
  • Brak monitoringu 24/7
  • Ryzyko przeoczenia krytycznej luki
  • Co robisz gdy aktualizacja psuje stronę?
Opcja B
Opieka serwisowa u specjalisty

Zlecasz miesięczną opiekę - specjalista aktualizuje, monitoruje, reaguje na problemy i raz w miesiącu wysyła raport.

  • Spokój ducha - problem z głowy
  • Szybka reakcja przy incydencie
  • Backup i monitoring w pakiecie
  • Regularne raporty
  • Koszt: 150-400 zł/miesiąc
  • Zależność od jednej osoby
Opcja C
Migracja na stronę statyczną

Strona wizytówkowa zamieniana na statyczny HTML. Żadnego CMS, żadnych wtyczek, żadnych aktualizacji do pilnowania.

  • Zero podatności na włamania do CMS
  • Szybsza strona - brak PHP i bazy danych
  • Niższe koszty hostingu
  • Brak miesięcznych kosztów serwisowania
  • Brak panelu edycji treści
  • Koszt jednorazowej migracji
  • Edycja wymaga technicznej wiedzy

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.

Pułapka aktualizacji: Aktualizacja wtyczki może zepsuć stronę - szczególnie gdy nowa wersja zmienia sposób działania lub jest niekompatybilna z motywem. Dlatego aktualizacje powinny być wykonywane zawsze po wykonaniu backupu i na staging (środowisko testowe), a nie bezpośrednio na produkcji.

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:

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.

Dobra wiadomość: Nawet jeśli strona jest rozległa, sama treść - artykuły, opisy usług, galerie - jest stosunkowo prosta do przeniesienia. Problemem jest kod, nie treść. Eksport i import postów przez WordPress XML to operacja na kilka minut.

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.
Bezpłatna konsultacja: Jeśli nie jesteś pewien kondycji swojej strony WordPress lub chcesz omówić opcje - umów 30-minutową rozmowę. Nie sprzedaję usług na siłę. Jeśli Twoja strona jest w dobrej kondycji - powiem Ci to wprost.

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.

Często zadawane pytania

Jak sprawdzić czy WordPress jest zawirusowany?
Pierwsze sygnały to alert w Google Search Console, komunikat bezpieczeństwa w wynikach Google, nieznane treści lub linki na stronie, zawieszone konto hostingowe. Możesz też uruchomić wtyczkę Wordfence lub Sucuri Security - skanują pliki i bazę danych w poszukiwaniu złośliwego kodu. Sprawdź też listę użytkowników administratorów - nieznane konta to pewny sygnał włamania.
Ile kosztuje naprawa zawirusowanej strony WordPress?
Koszt zależy od skali infekcji. Prosta naprawa małej strony: 400-800 zł. Głęboka infekcja z audytem i wdrożeniem zabezpieczeń: 1 000-2 500 zł. Pełna reinstalacja z migracją treści: od 2 000 zł. Dla porównania: roczna opieka serwisowa kosztuje 150-400 zł miesięcznie i zapobiega takim sytuacjom.
Czy WordPress wymaga regularnych aktualizacji?
Tak - rdzeń, wtyczki i motyw powinny być aktualizowane co 1-2 tygodnie. Ponad 97% ataków na WordPressa wykorzystuje znane podatności w przestarzałych komponentach, które mają już dostępną łatkę. Aktualizacja trwa minuty, a atak może nastąpić w dowolnym momencie po publikacji informacji o luce.
Jak długo trwa naprawa zawirusowanego WordPressa?
Prosta infekcja: 4-8 godzin. Rozległa infekcja z zanieczyszczoną bazą danych: 1-3 dni robocze. Pełna reinstalacja z migracją treści: dodatkowe 1-2 dni. Alert bezpieczeństwa Google znika zazwyczaj 1-7 dni po zgłoszeniu recenzji do Search Console.
Kiedy warto rozważyć migrację z WordPressa na stronę statyczną?
Kiedy strona to głównie wizytówka bez częstej edycji treści, wolisz nie martwić się aktualizacjami, zależy Ci na maksymalnej prędkości i bezpieczeństwie, lub masz ograniczony budżet na utrzymanie. Strony statyczne nie mają bazy danych ani PHP - nie ma co zaatakować w tradycyjnym sensie.
Co to jest serwisowanie WordPress i co obejmuje?
Serwisowanie WordPress to regularna opieka techniczna: aktualizacje rdzenia, wtyczek i motywu, codzienne backupy poza serwerem, monitoring dostępności, skanowanie złośliwego kodu, przegląd logów, optymalizacja bazy danych i monitorowanie Google Search Console. Dobra opieka zawiera też alert e-mailowy gdy strona przestaje działać.