Po czym poznasz, że Twój WordPress został zainfekowany?
Z naszego doświadczenia rzadko zdarza się, żeby właściciel strony pierwszy zauważył problem. Zwykle dzwoni klient, partner biznesowy albo dostawca hostingu, który właśnie wyłączył witrynę za rozsyłanie spamu. Czasem pierwszym sygnałem jest gwałtowny spadek ruchu w Search Console.
Najczęstsze objawy infekcji, które widzimy u nowych klientów, to:
biały ekran zamiast strony (tzw. White Screen of Death),
przekierowania na podejrzane domeny - zwłaszcza z urządzeń mobilnych, podczas gdy z komputera strona wygląda poprawnie,
nowi „administratorzy” w panelu WordPressa, których nikt nie dodawał,
setki postów w obcych językach, indeksowane przez Google,
ostrzeżenie „Strona, którą próbujesz odwiedzić, może zawierać złośliwe oprogramowanie”,
gwałtowny wzrost zużycia zasobów serwera bez powodu.
Szczególnie podstępne są infekcje, które filtrują ruch. Strona pokazuje czystą wersję robotom Google i Tobie, a złośliwy kod uruchamia się tylko dla użytkowników mobilnych. Dlatego sam fakt, że „u mnie wszystko wygląda dobrze”, niczego nie przesądza.
Pierwsza godzina po wykryciu - czego nie wolno robić
Najgorsze, co można zrobić w panice, to zalogować się przez FTP, otworzyć kilka losowych plików i zacząć kasować podejrzane fragmenty kodu. Często widzimy, że taka „samodzielna naprawa” doprowadza do nieodwracalnego uszkodzenia bazy danych albo zostawia w systemie głęboko ukryte tylne furtki, których właściciel nawet nie zauważył.
Druga klasyczna pułapka to natychmiastowe nadpisanie zainfekowanej strony backupem sprzed tygodnia. Problem w tym, że atakujący prawdopodobnie był w systemie znacznie dłużej, więc backup też jest skażony. Po przywróceniu kopii infekcja wraca w ciągu kilku godzin.
Co zrobić zamiast tego:
odetnij ruch publiczny przez konfigurację serwera (nie przez wtyczkę - atakujący ma do niej dostęp),
wykonaj pełną kopię zainfekowanego stanu (pliki + baza), zanim cokolwiek ruszysz,
zmień hasła do hostingu, FTP/SSH i bazy danych z innego, czystego urządzenia,
nie loguj się do WordPressa z komputera, który mógł być źródłem wycieku poświadczeń.
Ten zestaw działań zajmuje kilkanaście minut i daje punkt wyjścia do bezpiecznej naprawy.
Odwirusowanie strony WordPress krok po kroku
Skuteczne odwirusowanie ma stały rytm. Próba pójścia na skróty zawsze kończy się powrotem infekcji.
Wymiana plików rdzenia
Wszystkie pliki rdzenia WordPressa (folder wp-admin, wp-includes i pliki w katalogu głównym) wymieniamy na świeże, pobrane z oficjalnego źródła. Nie szukamy „brzydkiego kodu” - po prostu kasujemy i wgrywamy wersję czystą. To eliminuje zdecydowaną większość typowych backdoorów.
Plik wp-config.php zostawiamy w spokoju, ale przeglądamy go linijka po linijce. Jeśli na samej górze widzimy długi ciąg eval(base64_decode(...)) albo podobne konstrukcje - to złośliwy kod, który trzeba usunąć.
Czyszczenie wtyczek i motywów
Według raportów branżowych z 2025 i 2026 roku ponad 90% udanych włamań na WordPress wchodzi przez wtyczki i motywy, a nie przez sam rdzeń systemu. Dlatego cały folder wp-content/plugins i wp-content/themes traktujemy jako podejrzany.
Z naszego doświadczenia jedyna sensowna procedura to:
spisać listę wtyczek i ich wersji,
skasować całą zawartość katalogu
plugins,zainstalować od nowa tylko te wtyczki, które są aktywnie wspierane przez autora,
bezwzględnie usunąć wtyczki porzucone przez deweloperów (tzw. plugin graveyard),
motyw, który nie jest własnym dziełem agencji, pobrać ponownie z oryginalnego źródła.
W folderze wp-content/uploads szukamy plików z rozszerzeniem .php - tam ich być po prostu nie powinno. Każdy taki plik to backdoor.
Sanacja bazy danych
Po plikach przechodzimy do bazy. Sprawdzamy tabelę wp_users pod kątem nieznanych kont z uprawnieniami administratora i tabelę wp_options - tam atakujący często podmieniają wartości siteurl i home, żeby przekierować ruch.
Drugi obowiązkowy krok to przeszukanie postów i metadanych pod kątem wstrzykniętego JavaScriptu. Pomijając ten etap, infekcja wraca w momencie, gdy administrator po raz kolejny się zaloguje - bo złośliwy skrypt po prostu doda nowego użytkownika z poziomu zaufanej sesji.
Reset całego środowiska
Na końcu regenerujemy klucze szyfrujące w wp-config.php (sekcja AUTH_KEY i pokrewne), wymuszamy reset haseł wszystkich użytkowników i zmieniamy dane dostępowe do bazy. To wyrzuca z systemu każdą aktywną sesję atakującego, nawet jeśli jakiś backdoor pominęliśmy.
Dlaczego sama aktualizacja wtyczek już nie wystarcza?
Przez lata standardową radą było „regularnie aktualizuj WordPressa i wtyczki”. W 2026 roku ta rada przestała być wystarczająca. Z danych branżowych wynika, że średni czas od ujawnienia luki do pierwszych zmasowanych prób jej wykorzystania wynosi około pięciu godzin. To okno, w którym żaden człowiek fizycznie nie zdąży wgrać łatki.
Co gorsza, blisko połowa publikowanych podatności w ogóle nie ma w momencie ujawnienia gotowej aktualizacji. Sam autor wtyczki dopiero zaczyna pracę nad poprawką, a botnety już skanują internet w jej poszukiwaniu.
W praktyce oznacza to, że obrona oparta wyłącznie na aktualizacjach jest spóźniona z definicji. Trzeba ją uzupełnić warstwą, która chroni stronę także wtedy, gdy łatki jeszcze nie ma - czyli zaporą aplikacyjną (WAF) na poziomie serwera, a nie tylko wtyczką w panelu WordPressa.
Jak realnie zapobiegać atakom w 2026 roku?
Skuteczna prewencja to kilka warstw, które działają niezależnie od siebie. Jedna zawodzi - druga łapie atak. Z naszego doświadczenia minimum, które naprawdę robi różnicę, to:
WAF na poziomie serwera lub CDN - dobrze skonfigurowany Wordfence (w trybie Extended Protection, nie Basic) lub Cloudflare WAF łapią większość ataków, zanim w ogóle dotrą do PHP,
dwuskładnikowe logowanie dla każdego konta z uprawnieniami administratora i edytora - to pojedyncza zmiana, która eliminuje 80% udanych włamań przez słabe hasła,
ograniczenie uprawnień użytkownika bazy danych do tych, które WordPress faktycznie wykorzystuje - uniemożliwia atakującemu skasowanie tabel,
wyłączenie edycji plików
z panelu
define('DISALLOW_FILE_EDIT', true)wwp-config.phpkopie zapasowe poza hostingiem - minimum 30 dni rotacji, w niezależnej lokalizacji,
regularny przegląd wtyczek i bezlitosne kasowanie tych, które nie były aktualizowane od ponad roku.
Każdy z tych punktów z osobna jest tani. Razem zmieniają stronę z łatwego celu w taki, który botnety pomijają, bo szukają prostszych ofiar.
Stała opieka kontra gaszenie pożarów
Mediana kosztu likwidacji skutków udanego włamania na WordPressa to - według danych z 2026 roku - około 5-10 tys zł. Do tego dochodzą przestój sklepu, utracona sprzedaż, kary algorytmiczne od Google i utrata zaufania klientów. Spadek pozycji w wyszukiwarce odbudowuje się tygodniami.
Z drugiej strony stała opieka techniczna nad witryną - z monitoringiem, testowanym backupem, kontrolą aktualizacji w środowisku staging i szybkim reagowaniem - kosztuje ułamek tej kwoty miesięcznie. To zwykła matematyka zarządzania ryzykiem.
W Kodiwo prowadzimy strony klientów w takim właśnie modelu: aktualizacje testujemy najpierw w środowisku deweloperskim, scenariusze E2E w Playwright sprawdzają, czy po łatce nadal działa kluczowa ścieżka zakupowa, a alerty z WAF trafiają wprost do nas, a nie do skrzynki klienta, gdzie nikt by ich nie przeczytał.
Najważniejsze nie jest jednak narzędzie, tylko fakt, że ktoś codziennie patrzy na stan strony. Większość włamań, które rozplątujemy, byłaby do uniknięcia, gdyby ktoś zareagował na pierwszy alert - zwykle przychodzi on dni albo tygodnie przed faktycznym przejęciem witryny.
Podsumowanie
Pierwsza godzina po wykryciu infekcji decyduje o skali strat - nie próbuj naprawiać na własną rękę przez FTP.
Odwirusowanie ma stały rytm: kwarantanna, wymiana rdzenia, czyszczenie wtyczek i bazy, reset wszystkich poświadczeń.
Same aktualizacje to za mało - okno między ujawnieniem luki a pierwszym atakiem to dziś około pięciu godzin.
Skuteczna obrona to kilka warstw: WAF, 2FA, ograniczone uprawnienia, kopie poza hostingiem.
Stała opieka techniczna jest wielokrotnie tańsza niż ratowanie strony po włamaniu.
Jeśli czytasz ten artykuł, bo właśnie coś dziwnego dzieje się z Twoją stroną - nie czekaj, aż „samo przejdzie”. Każda godzina zwiększa zasięg infekcji i koszt naprawy. A jeśli czytasz go profilaktycznie i nie masz pewności, czy Twój WordPress jest realnie chroniony, chętnie spojrzymy na to świeżym okiem podczas krótkiej, niezobowiązującej rozmowy. Czasem wystarczy 30 minut, żeby zobaczyć, gdzie strona jest dzisiaj naprawdę odsłonięta.
