TL;DR: Zhakowana strona WordPress zdradza się zwykle przez dziwne przekierowania, nowe podstrony ze spamem, nieznanych administratorów, ostrzeżenia Google w wynikach wyszukiwania i w Search Console albo komunikat od hostingu. W pierwszej godzinie zabezpiecz dowody (kopię stanu zainfekowanego), zmień hasła i sprawdź konta, ale nie kasuj plików na ślepo i nie przywracaj od razu kopii zapasowej, dopóki nie wiesz, którędy wszedł atakujący. Profesjonalne czyszczenie obejmuje pliki, bazę danych, konta, zadania cron i całe konto hostingowe, a dopiero na końcu prośbę do Google o ponowne sprawdzenie. Bez zamknięcia furtki strona prawie na pewno zostanie zainfekowana ponownie.
Na co dzień zajmuję się naprawą stron, które ktoś przejął. Najczęściej dzwoni do mnie właściciel firmy, który usłyszał od klienta, że „strona przekierowuje na kasyno”, albo zobaczył w Google ostrzeżenie przy własnej domenie. W tym wpisie pokazuję, po czym poznać, że Twoja strona WordPress została zhakowana, co zrobić od razu, a czego robić nie wolno, i jak wygląda czyszczenie, po którym włamywacz nie wraca następnego dnia.
Dlaczego akurat WordPress? Bo jest najpopularniejszy, więc to on jest głównym celem. W raporcie Sucuri za 2023 rok aż 95,5% wykrytych infekcji dotyczyło stron na WordPressie, a 39,1% zainfekowanych stron miało nieaktualny system[1]. To nie znaczy, że WordPress jest dziurawy z natury. Znaczy, że zaniedbana instalacja jest łatwym łupem.
Objawy włamania na stronę WordPress
Sucuri wymienia dziesięć typowych objawów zhakowanego WordPressa, od alertów wtyczki bezpieczeństwa o nowych plikach, przez nagłe spowolnienie, po niewyjaśnione przekierowania i nowe strony, których nikt nie dodawał[2]. Najłatwiej je zrozumieć, dzieląc na trzy grupy: co widzisz Ty, co widzi klient i co widzi Google.
Co widzisz Ty jako właściciel
- Powiadomienie od hostingu o nietypowej aktywności albo zablokowanie konta[2].
- Alerty wtyczki bezpieczeństwa o zmienionych lub nowych plikach[2].
- Nieznani użytkownicy z rolą administratora, nowe wtyczki, których nie instalowałeś, zmieniona nazwa strony w ustawieniach.
- Strona nagle zwalnia albo pokazuje błąd 500.
- Wiadomość, że ktoś nieznany zweryfikował Twoją witrynę w Google Search Console. Google pisze wprost, że w takiej sytuacji istnieje duże prawdopodobieństwo, że strona została zhakowana, bo hakerzy dodają się jako właściciele usługi, żeby podmieniać np. mapy witryny[3].
Co widzi Twój klient
- Przekierowanie na inną stronę (kasyno, apteka, sklep z podróbkami), często tylko z telefonu albo tylko po wejściu z Google, więc Ty możesz tego nie zauważyć[2].
- Pełnoekranowe ostrzeżenie przeglądarki, że strona jest niebezpieczna[4].
- Fałszywe okienko „weryfikacji Cloudflare” albo „nie jestem robotem”, które każe wkleić komendę do systemu. To mechanizm ClickFix, a CERT Polska opisał przypadek, w którym taki łańcuch prowadził do złośliwego oprogramowania często poprzedzającego ransomware[5].
- W sklepach: zgłoszenia o kradzieży danych kart płatniczych[2].
Co widzi Google
Google może dodać w wynikach wyszukiwania ostrzeżenie przy Twojej domenie. Etykieta „This site may be hacked” (w polskiej wersji Google pokazuje analogiczny komunikat o możliwym ataku hakerów) pojawia się, gdy Google uważa, że haker zmienił istniejące strony albo dodał nowe strony ze spamem[6]. Przy złośliwym oprogramowaniu jest druga etykieta, „This site may harm your computer”[4].
W Search Console zajrzyj do raportu „Problemy dotyczące bezpieczeństwa”. Google rozróżnia tam wstrzyknięcie kodu (np. złośliwe przekierowania, koparki kryptowalut), wstrzyknięcie treści (spamowe linki i tekst) oraz wstrzyknięcie URL, czyli nowe strony utworzone przez hakera[7]. Szerzej o tym, jak włamywacze zarabiają na cudzych stronach, piszę we wpisie o spamie SEO i złośliwych przekierowaniach.
Jedna ważna uwaga: Google radzi, żeby nie otwierać zainfekowanych stron w przeglądarce, bo strona z malware może uszkodzić komputer. Zamiast tego lepiej użyć narzędzia Sprawdzanie adresu URL w Search Console albo cURL[7].
Z mojej praktyki: w jednym przypadku spam (podstrony w rodzaju /cennik/ z treściami kasyn) siedział jako fizyczne katalogi na serwerze, a baza danych była czysta. Panel WordPressa nie pokazywał nic podejrzanego, a Google spokojnie indeksował spam. Właściciel dowiedział się o problemie dopiero z wyników wyszukiwania.
Pierwsza godzina: co zrobić od razu
Google w poradniku dla zhakowanych stron proponuje kolejność: odcięcie strony (kwarantanna), Search Console, ocena szkód, znalezienie podatności, oczyszczenie i dopiero na końcu prośba o ponowne sprawdzenie[8]. W praktyce pierwsza godzina wygląda u mnie tak:
- Zrób kopię stanu zainfekowanego i odłóż ją osobno. Wordfence też to zaleca[9]. To Twój materiał dowodowy: daty modyfikacji plików i logi pokażą, którędy wszedł atakujący.
- Zmień wszystkie hasła, zwłaszcza administratorów WordPressa, a także hasła do hostingu, FTP i bazy danych[9].
- Sprawdź listę użytkowników i usuń konta, których nie znasz. Sprawdź też hasła aplikacji przypisane do kont, bo one działają niezależnie od zwykłego hasła.
- Zaloguj się do Search Console, zobacz raport bezpieczeństwa i usuń nieznanych właścicieli usługi[3].
- Jeśli strona aktywnie szkodzi odwiedzającym (przekierowania, fałszywe CAPTCHA), wyłącz ją na czas czyszczenia, np. trybem konserwacji na poziomie serwera.
Czego NIE robić
- Nie kasuj plików na ślepo. Usunięcie jednego podejrzanego pliku zwykle nic nie daje. Sucuri opisało we wrześniu 2026 rodzinę malware „SC”, która żyła w ośmiu miejscach naraz, m.in. w .user.ini, w drop-inach, w functions.php motywu i w mu-plugins, a do tego miała kopie w bazie danych. Jak piszą badacze: usuń wtyczkę, a drop-in ją odtworzy; wyczyść każdy plik na dysku, a kolejne załadowanie strony przywróci całość z bazy[10].
- Nie przywracaj od razu kopii zapasowej. Jeśli nie wiesz, którędy wszedł włamywacz, przywrócisz stronę z tą samą dziurą, a często z backdoorem, który siedział w niej od tygodni. W raporcie Sucuri prawie połowa zainfekowanych stron (49,21%) miała co najmniej jeden backdoor, czyli ukrytą furtkę do ponownego wejścia[1].
- Nie ufaj samej kwarantannie antywirusa. Miałem przypadek, w którym antywirus na hostingu przeniósł zainfekowany functions.php do „kwarantanny”, czyli po prostu zmienił mu nazwę na .VIRUS. Strona padła z błędem 500, a webshell (skrypt dający włamywaczowi pełną kontrolę nad serwerem) dalej był dostępny z internetu. Automatyczne czyszczenie to nie naprawa.
- Nie otwieraj zainfekowanych podstron w przeglądarce na komputerze, na którym masz bankowość firmową[7].
Jak wygląda profesjonalne czyszczenie krok po kroku
Gdy zajmuję się naprawą zhakowanej strony WordPress, nie zaczynam od skanera. Zaczynam od pytania: kiedy i którędy?
1. Szybki przegląd śladów
Pierwsze rzeczy, które sprawdzam przy każdym audycie włamania: czy zmieniła się nazwa strony, czy domyślna rola nowych użytkowników nie jest ustawiona na „administrator”, czy są nowi użytkownicy z rolą admina, jakie pliki zmieniły się w oknie czasowym widocznym w logach serwera oraz czy w katalogach wtyczek i mu-plugins (wtyczek ładowanych automatycznie, niewidocznych na zwykłej liście) nie ma czegoś obcego. Raport Sucuri pokazuje, że 55,2% stron ze skompromitowaną bazą miało złośliwe konta administratorów[1].
2. Szukanie po dacie i rozmiarze, nie tylko po sygnaturach
Wordfence zaleca, by przez SSH wyszukać pliki zmienione w ostatnich dniach i odwołania do base64, a zmienione pliki rdzenia i wtyczek porównać z oryginałami[9]. W jednym z moich przypadków znalazłem około 20 plików o identycznym rozmiarze (webshell) i mini-loadery pobierające kod z zewnętrznej domeny. W bazie nie było żadnego śladu. Skaner sygnatur część z nich przepuścił, a wyszukanie po rozmiarze i dacie modyfikacji wyłapało wszystkie.
3. Baza danych, nie tylko pliki
Coraz więcej złośliwego kodu żyje w bazie. Przy masowym włamaniu przez endpoint wsadowy REST API (ta sama ścieżka, którą wykorzystywał łańcuch wp2shell, działający na domyślnej instalacji bez wtyczek i bez logowania[11]) atakujący podmienił stronę główną, dodał ukrytego administratora, a backdoory schował w tabeli wtyczki do snippetów kodu. W plikach ich nie było. Sprawca wracał kilka razy, aż usunąłem wszystkie furtki.
4. Konta, hasła aplikacji i crony
W innym przypadku fałszywa wtyczka udawała narzędzie do czyszczenia cache. W rzeczywistości wystawiała własny endpoint, przez który atakujący wstrzykiwał linki do treści, a do tego miał własne hasło aplikacji. Zmiana hasła admina niczego nie zmieniała, bo hasło aplikacji działało dalej. Sprawdzam też zadania cron: zdarzyło mi się konto hostingowe z kilkoma stronami, na którym backdoor w crontabie co chwilę reinfekował pliki. Czyszczenie jednej strony nic nie dawało, trzeba było posprzątać całe konto.
5. Czyste źródła i właściwa kolejność
Pliki rdzenia WordPressa, motywów i wtyczek przeinstalowuję z czystych źródeł, wymieniam .htaccess na czystą kopię i usuwam podejrzane mapy witryny, tak jak zaleca Google[3]. Kolejność ma znaczenie: najpierw elementy, które odtwarzają infekcję (dyrektywy w .user.ini, kopie w bazie, crony, ukryci admini), a dopiero potem pliki, jednym przebiegiem. Później obserwuję, czy usunięte pliki się nie odtwarzają[10].
6. Zamknięcie furtki
Aktualizuję WordPressa, motywy i wtyczki[9], usuwam porzucone dodatki i wyłączam to, co posłużyło za wejście. Google pisze jasno: jeśli nie naprawisz problemu, który pozwolił zainfekować stronę, strona prawdopodobnie zostanie zainfekowana ponownie[6]. Na koniec robię ponowny skan[9].
Po włamaniu warto też spojrzeć na profil linków. U jednego klienta już po wyczyszczeniu plików strona dostała dziesiątki tysięcy spamowych linków zwrotnych z około stu domen. Kampania żyła dalej, więc potrzebny był plik disavow i monitoring. To element technicznej optymalizacji SEO, o którym przy włamaniach mało kto pamięta.
Zgłoszenie do Google o ponowne sprawdzenie
Ostrzeżenie w wynikach wyszukiwania nie zniknie samo. Trzeba zweryfikować witrynę w Search Console, przejrzeć przykładowe adresy w sekcji bezpieczeństwa, usunąć przyczynę i dopiero po pełnym oczyszczeniu poprosić o weryfikację[6]. Nie wysyłaj prośby „na próbę”, zanim skończysz.
Ile to trwa? Przy złośliwym oprogramowaniu Google podaje kilka dni, a przy zhakowanych treściach ze spamem do kilku tygodni, bo może to wymagać ręcznej analizy. Synchronizacja między Safe Browsing, Chrome i Search Console też może potrwać kilka dni[4]. Jeśli stronę oznaczyły także inne listy (Bing, programy antywirusowe), o zdjęcie trzeba poprosić każdą z nich osobno, a czasem także hosting o odblokowanie konta[2].
Co jeśli wyciekły dane klientów
Jeśli na stronie są formularze, konta klientów albo sklep, sprawdź, czy włamywacz miał dostęp do danych osobowych. Wyciek takich danych może oznaczać obowiązek zgłoszenia naruszenia do Prezesa UODO i poinformowania osób, których dotyczy, dlatego w takiej sytuacji skonsultuj się od razu ze swoim inspektorem ochrony danych lub prawnikiem. Sam incydent możesz zgłosić do CERT Polska przez portal incydent.cert.pl[12]. Zachowana kopia stanu zainfekowanego bardzo się wtedy przydaje.
Jak nie dopuścić do powtórki
Najczęstsze wejścia, które widzę, to nieaktualne wtyczki, słabe lub wyciekłe hasła i porzucone konta. Jeden z przypadków: boty logowały się przez XML-RPC (stary interfejs do zdalnego publikowania) hasłem admina, które krążyło w wyciekach, i publikowały spam. Potem ktoś włączył menedżer plików i wstrzyknął do functions.php fałszywą „weryfikację Cloudflare”, która kazała odwiedzającym wklejać komendę do systemu.
W skrócie: aktualizacje, silne i unikalne hasła z 2FA, wyłączone XML-RPC, jeśli go nie używasz, kopie zapasowe trzymane poza serwerem i regularny przegląd użytkowników. Pełną listę opisałem we wpisie jak zabezpieczyć stronę WordPress przed włamaniem. Jeśli nie masz czasu pilnować tego sam, zajmuję się też stałą administracją stron: aktualizacjami, kopiami i monitoringiem.
FAQ - zhakowana strona WordPress
Skąd mam wiedzieć, czy moja strona WordPress jest zhakowana?
Najczęstsze sygnały to przekierowania na obce strony, nowe podstrony ze spamem, nieznani administratorzy, ostrzeżenie Google przy domenie i komunikat od hostingu. Sprawdź raport „Problemy dotyczące bezpieczeństwa” w Search Console i listę użytkowników w panelu. Pamiętaj, że część infekcji pokazuje się tylko Google albo tylko użytkownikom telefonów.
Czy wystarczy przywrócić kopię zapasową?
Zwykle nie. Kopia może już zawierać backdoor, a nawet czysta kopia ma tę samą lukę, przez którą wszedł atakujący. Kopię przywracam dopiero wtedy, gdy wiem, którędy nastąpiło włamanie, i mogę tę drogę zamknąć.
Wtyczka bezpieczeństwa pokazuje, że strona jest czysta. Czy mogę spać spokojnie?
Niekoniecznie. Skanery szukają znanych sygnatur, a złośliwy kod coraz częściej siedzi w bazie danych, w mu-plugins albo w crontabie. Ręczny przegląd plików zmienionych w oknie czasowym z logów i przegląd bazy wyłapuje to, czego skaner nie widzi.
Jak długo znika ostrzeżenie Google po oczyszczeniu strony?
Po wysłaniu prośby o ponowne sprawdzenie Google weryfikuje strony z malware zwykle w kilka dni, a strony ze spamem do kilku tygodni. Prośbę wysyłaj dopiero po pełnym oczyszczeniu, bo odrzucenie wydłuża cały proces.
Czy włamanie może wrócić po wyczyszczeniu?
Tak, jeśli zostanie choć jedna furtka: ukryty admin, hasło aplikacji, cron albo zainfekowana sąsiednia strona na tym samym koncie hostingowym. Dlatego po czyszczeniu monitoruję stronę i sprawdzam, czy usunięte pliki się nie odtwarzają.
Twoja strona pokazuje któryś z tych objawów?
Nie czekaj, aż Google lub klienci zrobią to za Ciebie. Zajmuję się naprawą i czyszczeniem zhakowanych stron WordPress: znajduję furtkę, usuwam infekcję z plików i bazy, zamykam lukę i prowadzę zgłoszenie do Google. Zadzwoń: +48 606 719 343 albo napisz: lukasz@freelancerka.com.
Przypisy i źródła
Wszystkie źródła zweryfikowane; dostęp: 8 października 2026.
- Sucuri, „2023 Hacked Website & Malware Threat Report” (czerwiec 2024) - sucuri.net
- Sucuri, „How to Clean a Hacked WordPress Site” (b.d.) - sucuri.net
- Google, web.dev, „Fix the Japanese keyword hack” (b.d.) - web.dev
- Google Search Console Help, „Why is my site labeled as dangerous in Google Search?” (b.d.) - support.google.com
- CERT Polska, „ClickFix w akcji: jak fake captcha może zaszyfrować całą firmę” (17.02.2026) - cert.pl
- Google Search Help, „"This site may be hacked" message” (b.d.) - support.google.com
- Google Search Console Help, „Security Issues report” (b.d.) - support.google.com
- Google, web.dev, „Help for hacked sites” (b.d.) - web.dev
- Wordfence, „How to Clean a Hacked WordPress Site using Wordfence” (b.d.) - wordfence.com
- Sucuri Blog, Gabriel Barbosa, „SC WordPress Malware: A Self-Healing Mesh of Loaders, Drop-Ins, and a Blockchain-Controlled Backdoor” (30.09.2026) - blog.sucuri.net
- Rapid7, „CVE-2026-63030: wp2shell, a Critical Remote Code Execution Vulnerability in WordPress Core” (17.07.2026) - rapid7.com
- CyberDefence24, Tymoteusz Netter, „Potwierdź, że nie jesteś robotem. Uwaga na fałszywe CAPTCHA” (03.08.2026) - cyberdefence24.pl
