Zainfekowany WordPress – dlaczego backup i aktualizacja nie wystarczyły

Zainfekowany WordPress nie zawsze daje jednoznaczny komunikat o włamaniu. Czasem strona po prostu zwraca błąd 500, przestaje łączyć się z bazą albo działa tylko przez chwilę. W opisanym przypadku samo przywrócenie backupu i wykonanie aktualizacji nie wystarczyło, ponieważ część mechanizmów infekcji działała poza standardowymi plikami strony.

To nie jest uniwersalna instrukcja usunięcia każdego wirusa. Pokazujemy rzeczywisty przebieg diagnozy i odzyskiwania strony firmowej, na której znaleźliśmy kilka niezależnych sposobów utrzymania dostępu. Szczegóły identyfikujące klienta zostały pominięte.

Krótka odpowiedź: jeśli hosting zgłosił złośliwe pliki, samo przywrócenie backupu i wykonanie aktualizacji może nie wystarczyć. Trzeba sprawdzić, czy na koncie nie pozostały backdoory, zadania cron, przejęte konta albo pliki znajdujące się poza przywróconym katalogiem. W przeciwnym razie infekcja może się odtworzyć.

Błąd 500 był objawem, nie diagnozą

HTTP 500 mówi tylko, że serwer nie był w stanie prawidłowo obsłużyć żądania. Przyczyną może być błąd PHP, brak pamięci, uszkodzona wtyczka, problem z bazą albo złośliwy kod. Dlatego naprawianie samego komunikatu bez sprawdzenia całego środowiska może jedynie ukryć właściwy problem.

W tym przypadku sytuacja zmieniała się w czasie. Pojawiał się błąd 500, później timeout, błąd 503 i problemy z połączeniem z bazą danych. Hosting oraz Imunify360 potwierdziły obecność złośliwych plików. To był moment, w którym zwykłe szukanie konfliktu wtyczek przestało mieć sens. Trzeba było potraktować zdarzenie jako incydent bezpieczeństwa.

Pierwszym zadaniem nie było więc „uruchomienie strony za wszelką cenę”, ale ustalenie:

• co zostało zmienione,
• które pliki są złośliwe,
• w jaki sposób infekcja może się odtwarzać,
• czy problem dotyczy wyłącznie WordPressa, czy całego konta hostingowego,
• które legalne funkcje trzeba będzie później przywrócić.

Dlaczego przywrócenie backupu nie rozwiązało problemu

Backup przywraca zapisany stan plików i bazy objętych kopią. Nie gwarantuje jednak usunięcia zadań cron konta, plików znajdujących się poza przywracanym katalogiem, zmienionych danych dostępowych ani mechanizmu, który ponownie pobiera złośliwy kod. Kopia jest ważnym narzędziem odzyskiwania, ale nie zastępuje diagnozy.

Przywróciliśmy kopię strony z okresu sprzed wystąpienia widocznej awarii. Strona nadal nie była jednak gotowa do bezpiecznego uruchomienia. Na koncie znajdowały się elementy, które mogły działać niezależnie od przywróconych plików WordPressa albo ponownie ingerować w instalację.

To ważna różnica: przywrócenie działania strony nie oznacza jeszcze usunięcia przyczyny. Jeśli po backupie zostanie aktywny backdoor, zadanie cron albo przejęte hasło, problem może wrócić po kilku minutach, godzinach lub dniach.

Co pozwalało infekcji przetrwać i wracać

W analizowanym środowisku nie znaleźliśmy jednego podejrzanego pliku, którego usunięcie kończyło sprawę. Infekcja miała kilka warstw. Część elementów udawała składniki WordPressa, inne znajdowały się w miejscach, których właściciel strony zwykle nie kontroluje.

Webshelle i fałszywe wtyczki

Webshell to plik umożliwiający wykonywanie poleceń na serwerze przez przeglądarkę lub zdalne żądanie. Może wyglądać niepozornie, mieć nazwę podobną do legalnej wtyczki albo zawierać zaciemniony kod. Znaleźliśmy również elementy podszywające się pod poprawne rozszerzenia.

Samo wyłączenie takiej „wtyczki” w panelu nie wystarcza. Trzeba sprawdzić jej pliki, miejsce ładowania i powiązane mechanizmy, które mogły ją odtworzyć.

Kod PHP w uploads i złośliwy mu-plugin

Katalog uploads powinien służyć głównie do przechowywania mediów. Pliki PHP w tym miejscu wymagają szczególnej uwagi, ponieważ mogą zostać uruchomione poza zwykłym mechanizmem wtyczek.

Drugim miejscem był katalog mu-plugins. Wtyczki typu must-use uruchamiają się automatycznie i zwykle nie można ich wyłączyć standardowym przełącznikiem w panelu. To dobre narzędzie dla administratora, ale również atrakcyjne miejsce do ukrycia złośliwego kodu.

WP-Cron i cron konta hostingowego

Zadania cykliczne mogą uruchamiać zaplanowane działania WordPressa albo polecenia na poziomie konta hostingowego. Jeśli takie zadanie ponownie pobiera usunięty plik, ręczne kasowanie skutku działa tylko do następnego uruchomienia harmonogramu.

W tym przypadku konieczne było sprawdzenie zarówno WP-Cron, jak i crona konta. Znaleźliśmy mechanizmy wykorzystujące zewnętrzne pobieranie i ponowne uruchamianie komponentów infekcji.

Fałszywy proces SSH i samoodtwarzający się plik tymczasowy

Jednym z bardziej niepokojących elementów były pliki udające składniki usługi SSH oraz prywatne klucze. Pojawiał się też ładunek tymczasowy, który mógł zostać ponownie utworzony. Takie artefakty pokazują, dlaczego analiza nie może kończyć się na katalogu wp-content/plugins.

Spamowe podstrony SEO

Infekcja wykorzystywała stronę również do tworzenia podstron niezwiązanych z działalnością firmy. Taki spam może prowadzić do indeksowania obcych treści, utraty zaufania użytkowników i problemów z widocznością domeny. Po usunięciu plików trzeba więc sprawdzić także adresy widoczne w Google, sitemapę oraz nietypowe wyniki wyszukiwania dla domeny.

Jak odzyskaliśmy kontrolę nad stroną

Odzyskiwanie zainfekowanego WordPressa wymagało połączenia kilku działań. Kolejność ma znaczenie: aktualizacja wykonana przed usunięciem mechanizmu trwałości nie zamknie dostępu, a zmiana jednego hasła nie pomoże, jeśli aktywny backdoor nadal pozwala wykonywać kod.

Zakres prac objął:

1. Zabezpieczenie i analizę bieżącego stanu oraz potwierdzenie infekcji z hostingiem.
2. Przywrócenie kopii, która pozwoliła odzyskać legalne pliki i dane strony.
3. Usunięcie wykrytych webshelli, fałszywych wtyczek, kodu PHP w niewłaściwych katalogach i złośliwego mu-plugina.
4. Usunięcie zadań WP-Cron i crona konta, które nie należały do prawidłowej konfiguracji.
5. Usunięcie plików udających usługę SSH, kluczy i samoodtwarzających się ładunków.
6. Zmianę haseł, tokenów oraz saltów WordPressa.
7. Aktualizację WordPressa, motywu i wtyczek po oczyszczeniu środowiska.
8. Instalację i konfigurację dodatkowej ochrony oraz ograniczenie wybranych funkcji PHP po stronie hostingu.
9. Pełne skanowanie całego konta, nie tylko jednego katalogu strony.
10. Przywrócenie legalnych funkcji cofniętych przez backup, między innymi formularzy, wysyłki wiadomości i integracji rezerwacji.

Pełny skan objął ponad 51 tysięcy plików. Ostatnie wskazanie dotyczyło pliku znajdującego się już w koszu. Po jego usunięciu i kolejnej obserwacji nie zauważyliśmy ponownego tworzenia wykrytych elementów. To potwierdza stan w chwili kontroli, ale nie jest obietnicą, że jakakolwiek strona będzie odtąd odporna na każdy atak.

WordPress 7.0.2 łata poważne luki bezpieczeństwa

17 lipca 2026 roku opublikowano WordPress 7.0.2. Aktualizacja usuwa dwie poważne podatności oznaczone jako CVE-2026-60137 oraz CVE-2026-63030. Ich połączenie w WordPressie 6.9 i 7.0 może prowadzić do wykorzystania SQL Injection i zdalnego wykonania kodu.

Stan informacji o podatnych wersjach: 3 sierpnia 2026 roku.

• WordPress 7.0.0-7.0.1 – obie podatności, poprawka w wersji 7.0.2,
• WordPress 6.9.0-6.9.4 – obie podatności, poprawka w wersji 6.9.5,
• WordPress 6.8.0-6.8.5 – podatność CVE-2026-60137, poprawka w wersji 6.8.6.

Wersje starsze niż 6.8 nie są objęte tymi dwoma konkretnymi podatnościami. Nie oznacza to jednak, że stara instalacja jest bezpieczna – może zawierać inne niezałatane luki, a WordPress aktywnie wspiera przede wszystkim najnowszą wersję.

Aktualizacja zamyka podatność, ale nie usuwa automatycznie kodu, który wcześniej znalazł się na serwerze. Jeśli hosting wykrył malware albo strona zachowuje się nietypowo, oprócz aktualizacji potrzebne jest sprawdzenie plików, dostępów, zadań cron i całego konta hostingowego.

W opisanym przypadku nie udało się wskazać jednego potwierdzonego punktu wejścia. Dlatego odzyskiwanie strony obejmowało zarówno aktualizację legalnych komponentów, jak i usunięcie mechanizmów pozwalających infekcji przetrwać i powracać.

Źródła: oficjalny komunikat WordPress 7.0.2, GHSA-fpp7-x2x2-2mjf oraz GHSA-ff9f-jf42-662q.

Co zrobić po alarmie od hostingu

Nie usuwaj w pośpiechu pierwszego wskazanego pliku i nie zakładaj, że problem został rozwiązany. Najpierw ogranicz możliwość dalszych zmian, zachowaj informacje z alertu i ustal, czy skan dotyczył pojedynczej instalacji, czy całego konta. Potem sprawdź wszystkie miejsca, z których kod może się ponownie uruchomić.

Praktyczna kolejność wygląda następująco:

• zapisz listę wykrytych ścieżek i komunikaty hostingu,
• skontaktuj się z hostingiem i ustal zakres skanu,
• ogranicz dostęp do strony, jeśli nadal rozsyła spam lub przekierowuje użytkowników,
• sprawdź konta administratorów, WP-Cron, cron hostingu, mu-plugins, uploads i pliki poza instalacją,
• ustal, z którego dnia pochodzi ostatnia wiarygodna kopia,
• po oczyszczeniu zmień hasła do WordPressa, hostingu, bazy, FTP lub SSH oraz odśwież klucze i tokeny,
• zaktualizuj wszystkie legalne komponenty,
• wykonaj ponowny skan całego konta i obserwuj, czy pliki nie wracają,
• dopiero później przywracaj funkcje cofnięte przez backup.

Jeżeli strona obsługuje formularze, rezerwacje, płatności albo dane klientów, trzeba dodatkowo sprawdzić wpływ incydentu na te procesy. Sam fakt, że strona znów się otwiera, nie kończy pracy.

Jak ograniczyć ryzyko kolejnej infekcji

Nie istnieje jedna wtyczka, która gwarantuje bezpieczeństwo WordPressa. Ryzyko ogranicza dopiero zestaw działań: aktualizacje, kopie przechowywane poza kontem, ograniczone uprawnienia, mocne i unikalne hasła, uwierzytelnianie dwuskładnikowe, monitoring zmian oraz możliwość szybkiego skanowania całego środowiska.

Warto też wiedzieć, kto odpowiada za utrzymanie strony po wdrożeniu. Model bez miesięcznego abonamentu daje właścicielowi kontrolę, ale nie oznacza, że aktualizacje, kopie i reakcja na alerty wykonują się bez nadzoru. Więcej o tej różnicy wyjaśniamy w artykule strona internetowa bez abonamentu.

Jeśli dopiero wybierasz firmę do wykonania strony, zapytaj również o przekazanie dostępów, kopie, aktualizacje i zakres pomocy po wdrożeniu. Podpowiadamy, co jeszcze sprawdzić, w poradniku jak wybrać wykonawcę strony internetowej.

Strona działa ponownie – co dalej

Najważniejszy wniosek z tego przypadku jest prosty: backup służy do odzyskiwania danych, ale nie jest pełnym procesem usuwania infekcji. Zainfekowany WordPress może mieć kilka mechanizmów trwałości działających w plikach strony, bazie, zadaniach cyklicznych i na poziomie całego konta hostingowego.

Dlatego potrzebne było nie tylko przywrócenie strony, lecz także znalezienie sposobów odtwarzania złośliwego kodu, zmiana dostępów, aktualizacje, pełny skan i ponowna kontrola. Dopiero potem można było bezpiecznie przywrócić formularze i integracje potrzebne firmie w codziennej pracy.

WEB Koncept projektuje i porządkuje strony internetowe dla firm, ale pomaga również w diagnozie istniejących witryn, gdy awaria lub infekcja zatrzymuje ich działanie. W tym przypadku odzyskanie strony obejmowało także sprawdzenie i ponowne uruchomienie funkcji potrzebnych firmie, takich jak formularze, wysyłka wiadomości i integracja rezerwacji.

Kiedy warto przekazać stronę do pełnej diagnozy

Samodzielne przywrócenie kopii może pomóc przy zwykłej awarii. Jeśli jednak występuje któryś z poniższych objawów, potrzebna jest analiza źródła problemu, a nie tylko ponowne uruchomienie strony:

• błędy wracają po przywróceniu backupu,
• hosting ponownie wykrywa złośliwe pliki albo wskazuje problem poza katalogiem WordPressa,
• strona przekierowuje użytkowników lub tworzy obce podstrony,
• na koncie pojawiają się nieznane zadania cron, administratorzy albo pliki PHP,
• nie wiadomo, z którego dnia pochodzi ostatnia bezpieczna kopia ani którędy doszło do infekcji.

W takiej sytuacji kolejne przywracanie kopii może usuwać objawy tylko tymczasowo. Najpierw trzeba zabezpieczyć bieżący stan, ustalić zakres infekcji i sprawdzić, czy zagrożenie może się odtworzyć. Dopiero później warto ponownie uruchamiać stronę i przywracać jej funkcje.