Po włamaniu na stronę WordPress pierwsza godzina służy dokumentowaniu, nie sprzątaniu. Najpierw zabezpieczam dowody, potem ustalam wektor ataku, a dopiero wtedy usuwam malware, na kopii strony, z dala od produkcji. Pliki skasowane na ślepo zacierają ślady wektora, a stara kopia przywrócona bez sprawdzenia daty infekcji potrafi przywrócić także złośliwy kod.
Ta strona opisuje objawy włamania, kolejność mojej pracy po incydencie, włamania do sklepów WooCommerce i serwisów na innych systemach oraz obowiązki z RODO, które biegną od chwili wykrycia. Jeśli chcesz samodzielnie przejść przez sprzątanie, pełna instrukcja z komendami jest w przewodniku po czyszczeniu zhakowanej strony WordPress.
Zhakowana strona WordPress: objawy
Objawy, które zwykle oznaczają włamanie, i pierwszy ruch, który wtedy robię.
- Co widzisz: Google pokazuje ostrzeżenie przy twojej stronie albo Search Console zgłasza problem bezpieczeństwa
- Co robięSprawdzam raport Problemy dotyczące bezpieczeństwa w Search Console i listę zgłoszonych adresów. To punkt wyjścia do diagnozy i do późniejszej prośby o przegląd.
- Co widzisz: W Search Console jest właściciel, którego nie dodawałeś
- Co robięZapisuję go jako dowód i usuwam dostęp. Kontrola właścicieli w Search Console należy do pierwszych kroków po wykryciu włamania.
- Co widzisz: Na liście użytkowników jest nieznane konto administratora
- Co robięPrzeglądam wszystkie konta administratorów i zadania cron. Konta, których nikt nie zakładał, usuwam po zapisaniu ich danych jako dowodu.
- Co widzisz: Pliki rdzenia nie zgadzają się z oryginałem
- Co robięUruchamiam wp core verify-checksums i porównuję pliki wtyczek i motywów z wersjami z oficjalnych źródeł.
- Co widzisz: Strona przekierowuje odwiedzających na obce adresy albo rozsyła złośliwy kod
- Co robięWłączam tryb serwisowy, żeby strona nie infekowała odwiedzających, i robię kopię plików i bazy jako dowód.
- Co widzisz: Klienci sklepu zgłaszają dziwne zachowanie strony zamówienia albo płatności
- Co robięTraktuję to jako możliwe naruszenie danych osobowych. Zabezpieczam dowody, zapisuję czas zgłoszenia i informuję cię, bo od tej chwili biegną terminy z RODO.
- Co widzisz: Infekcja wraca kilka dni po sprzątaniu
- Co robięSzukam wektora, którego nie zamknięto: backdoora w bazie, zadania cron, starego konta. Sprzątanie bez zamknięcia wektora nie trzyma.
Pierwsza godzina po włamaniu: co możesz zrobić sam
Zanim napiszesz do mnie albo do kogokolwiek innego, zrób pięć rzeczy. Nie kasuj żadnych plików. Zrób kopię plików i bazy danych, nawet jeśli jest zainfekowana, bo to materiał dowodowy. Zapisz datę i godzinę, kiedy zauważyłeś włamanie. Sprawdź w Search Console, czy na liście właścicieli nie ma nikogo obcego. Jeśli strona rozsyła malware albo przekierowuje odwiedzających, włącz tryb serwisowy.
Potem zmień hasła do panelu WordPress, SFTP i bazy danych. Nie przywracaj starej kopii zapasowej, dopóki nie wiesz, kiedy zaczęła się infekcja. Kopia sprzed tygodnia nie pomoże, jeśli złośliwy kod siedzi na stronie od miesiąca.
Sprzątanie idzie szybciej, gdy od razu dostanę dostęp do panelu hostingu, logów serwera, SFTP, bazy i Search Console. Jeśli dostępy są rozproszone między kilka osób albo firm, zbierz je w jednym miejscu, zanim zaczniemy.
Usuwanie wirusów WordPress: kolejność pracy
Każdy krok kończy się czymś, co można sprawdzić: kopią, raportem, listą zmian.
Umowa powierzenia przed dostępem
Zanim dostanę dostęp do strony, podpisujemy umowę powierzenia przetwarzania danych osobowych (art. 28 RODO). Na zainfekowanej stronie są dane twoich klientów.
Pierwsza godzina: zabezpieczenie dowodów
Kopia plików i bazy jako dowód, zapisany czas wykrycia, tryb serwisowy, jeśli strona rozsyła malware, i kontrola właścicieli w Search Console. Od chwili wykrycia liczą się terminy z RODO.
Diagnoza jako osobny etap
Diagnoza ma swoją cenę i zamknięty zakres. Jej wynik to przyczyna, zakres naprawy i koszt, na piśmie. Czyszczenie zaczynam po potwierdzeniu tego zakresu.
Wektor ataku na kopii strony
Pracuję na kopii, nie na produkcji. Wektor ustalam z logów serwera, z wp core verify-checksums i z porównania plików wtyczek i motywów z czystymi wersjami.
Czyszczenie plików i bazy
Usuwam malware i backdoory z plików i z bazy, sprawdzam konta administratorów i zadania cron, a rdzeń i wtyczki odtwarzam z czystych źródeł.
Nowe hasła i dostępy
Zmieniam hasła do panelu WordPress, SFTP i bazy danych. Stare dane dostępowe traktuję jako znane atakującemu.
Jedno wdrożenie, które da się wycofać
Oczyszczoną wersję wdrażam jednym krokiem z możliwością wycofania. Dodaję zabezpieczenia przeciw ustalonemu wektorowi i opisuję na piśmie przyczynę i sposób zapobiegania.
Prośba o przegląd w Google
Gdy strona jest czysta, zgłaszam prośbę o weryfikację w raporcie Problemy dotyczące bezpieczeństwa w Search Console.
Na ostatni krok nie mam wpływu. Według pomocy Google przegląd trwa od kilku dni do kilku tygodni, a po jego zakończeniu Google wysyła e-mail. Dlatego nie obiecuję daty zdjęcia ostrzeżenia z wyników wyszukiwania.
Ile kosztuje usuwanie wirusów WordPress
Ceny sprzątania nie podaję z góry, bo zależy od tego, co diagnoza znajdzie: czy infekcja dotyczy kilku plików, czy także bazy i kont, czy kopie zapasowe są starsze niż infekcja i czy wektorem jest wtyczka, którą da się po prostu zaktualizować. Diagnoza jest osobnym, zamkniętym etapem z własną ceną. Jej wynik to przyczyna, zakres naprawy i koszt, na piśmie. Sprzątanie zaczynam po twoim potwierdzeniu tego zakresu.
Strona bez umowy opieki idzie przez naprawę WordPress, gdzie cenę podaję po opisie incydentu. Ile kosztuje stała opieka, która obejmuje skan malware i codzienne kopie, opisuję na stronie opieka WordPress cena.
Zhakowany sklep WooCommerce
Włamanie do sklepu różni się od włamania do strony firmowej tym, że prawie zawsze dotyczy danych osobowych. W bazie sklepu są konta klientów, adresy dostaw, numery telefonów i historia zamówień. Dlatego w sklepie od pierwszej godziny zakładam, że może chodzić o naruszenie ochrony danych, i od razu zapisuję czas wykrycia, który przekazuję tobie jako administratorowi.
Kolejność pracy jest taka sama jak przy stronie firmowej, ale zakres sprawdzania jest szerszy. Oprócz plików, bazy, kont i zadań cron sprawdzam wtyczki płatności, kurierskie i łączniki z innymi systemami, bo każda z nich ma własne klucze API. Klucze, które mogły wyciec, trzeba wymienić także po stronie bramki płatności, ERP czy programu księgowego, nie tylko w WordPressie. Ich wymiana wymaga dostępu do paneli tych usług, więc zwykle robimy ją razem.
Po sprzątaniu sprawdzam scenariusz koszyk, dane, dostawa, płatność, bez składania prawdziwego zamówienia, zanim sklep wróci do sprzedaży. Sklep, w którym ten test ma się odbywać stale, prowadzę w Store Reliability Plan. Gdy po włamaniu koszyk albo płatność nie działa i trzeba przywrócić sprzedaż, właściwą usługą jest sprint naprawy WooCommerce.
Typowy scenariusz: sklep z kontami klientów i nieaktualną wtyczką
Typowy przypadek, z jakim przychodzą właściciele sklepów, wygląda tak: sklep działa od kilku lat, ma konta klientów i kilkanaście wtyczek, z których część nie była aktualizowana od miesięcy. Ktoś zauważa obce konto administratora albo dziwne zachowanie strony zamówienia. W takim sklepie najpierw zabezpieczam dowody i zapisuję czas wykrycia, potem sprawdzam, czy i jakie dane klientów mogły zostać odczytane. Ten opis przekazuję tobie, bo to ty decydujesz, czy i kiedy zgłosić naruszenie do UODO.
Typowy scenariusz: strona firmowa przekierowuje odwiedzających z telefonów
Inny typowy scenariusz: właściciel strony firmowej dowiaduje się od klienta, że strona otwarta z telefonu przenosi na obcą witrynę, a z komputera wygląda normalnie. Taki objaw oznacza zwykle złośliwy kod w plikach albo w bazie, który działa tylko dla wybranych odwiedzających. Tu też zaczynam od kopii jako dowodu i trybu serwisowego, a wektor szukam w logach serwera i w porównaniu plików z czystymi wersjami. Jeśli strona ma formularz kontaktowy, sprawdzam też, czy złośliwy kod miał dostęp do zgłoszeń, bo to dane osobowe.
Włamanie na stronę na Drupalu, TYPO3, Laravelu lub Symfony
Ta sama kolejność pracy (dowody, wektor, czyszczenie na kopii, nowe dostępy, jedno wdrożenie z możliwością wycofania) obowiązuje w systemach spoza WordPressa. Różnią się narzędzia: w Drupalu i TYPO3 rdzeń i moduły odtwarzam z czystych źródeł przez Composera, w aplikacji Laravel lub Symfony porównuję kod na serwerze z repozytorium.
Wersja bez wsparcia bezpieczeństwa nie dostaje poprawek nowych luk. Drupal 7 nie ma wsparcia bezpieczeństwa od 5 stycznia 2025, a Drupal 10 traci je 9 grudnia 2026. Bezpłatne wsparcie dla TYPO3 12.4 skończyło się 30 kwietnia 2026. Po sprzątaniu serwisu na takiej wersji samo usunięcie złośliwego kodu nie wystarczy, potrzebny jest plan aktualizacji albo migracji do WordPressa. Przy Drupalu 10 opcje opisuję we wpisie Drupal 10 koniec wsparcia.
Włamanie na stronę a RODO: 72 godziny i UODO
Jeśli przez włamanie ktoś mógł dostać się do danych osobowych (konta klientów, zamówienia, zgłoszenia z formularza), zaczynają biec terminy z RODO. Art. 33 ust. 1 RODO mówi, że administrator zgłasza naruszenie organowi nadzorczemu bez zbędnej zwłoki, w miarę możliwości nie później niż w terminie 72 godzin od jego stwierdzenia, chyba że naruszenie raczej nie powoduje ryzyka naruszenia praw lub wolności osób fizycznych. Zgłoszenie po terminie wymaga wyjaśnienia przyczyn opóźnienia. Gdy ryzyko jest wysokie, art. 34 ust. 1 wymaga też zawiadomienia osób, których dane dotyczą, bez zbędnej zwłoki.
W Polsce naruszenie zgłasza się Prezesowi UODO. Zgłoszenie naruszenia ochrony danych składa się elektronicznie, przez dedykowany formularz, a instrukcja na stronie UODO opisuje, jak go wypełnić. Sam incydent bezpieczeństwa możesz zgłosić do CERT Polska przez formularz Zgłoś incydent.
Kto za co odpowiada przy naruszeniu danych
Podział ról wynika z RODO i z umowy powierzenia, którą podpisujemy przed dostępem do strony.
Ty, jako administrator danych
- Decydujesz, czy naruszenie trzeba zgłosić Prezesowi UODO (art. 33 RODO)
- Decydujesz, czy zawiadomić osoby, których dane dotyczą (art. 34 RODO)
- Składasz zgłoszenie do UODO i liczysz termin 72 godzin od stwierdzenia naruszenia
- Prowadzisz kontakt z klientami, których dane mogły wyciec
Ja, jako podmiot przetwarzający
- Informuję cię o naruszeniu bez zbędnej zwłoki po jego stwierdzeniu (art. 33 ust. 2 RODO)
- Przekazuję fakty potrzebne do zgłoszenia: czas wykrycia, zakres plików i danych, ustalony wektor
- Nie zgłaszam naruszenia do UODO w twoim imieniu, chyba że umowa tak stanowi
- Usuwam skutki włamania i zamykam wektor w zakresie zapisanym w umowie
Odpowiedzialność stron, także za skutki włamania, określa umowa. Dlatego umowę powierzenia podpisujemy przed pierwszym dostępem do strony, a nie w dniu incydentu. Do zgłoszenia przydaje się to, co powstaje w pierwszych krokach mojej pracy: czas wykrycia, zakres plików i tabel, których dotyczyła infekcja, i ustalony wektor. Pełny raport z przyczyną dostajesz na piśmie.
Jeśli twoja firma działa w sektorze objętym NIS2 albo DORA, obowiązki zgłoszeniowe mogą być szersze niż RODO. Przygotowanie infrastruktury WordPress na te wymagania obejmuje audyt gotowości NIS2 i DORA.
Czyścić, przywracać czy wymieniać
Wybór zależy od tego, kiedy zaczęła się infekcja i co jest jej źródłem.
Masz kopię zapasową na pewno starszą niż infekcja, a wektor jest już znany.
Przywracam tę kopię na kopii roboczej, zamykam wektor i dopiero wtedy wdrażam. Treści i zamówienia dodane od daty kopii trzeba przenieść osobno.
Nie wiesz, kiedy zaczęła się infekcja, albo wszystkie kopie są młodsze niż ona.
Czyszczę stronę na kopii: pliki, baza, konta, zadania cron, rdzeń i wtyczki z czystych źródeł.
Źródłem jest motyw albo wtyczka, której nikt już nie rozwija.
Usuwam ją albo proponuję zamiennik. Jeśli zamiana wymaga nowego kodu, dostaje osobną wycenę.
Serwis stoi na wersji CMS bez wsparcia bezpieczeństwa.
Po sprzątaniu potrzebny jest plan aktualizacji albo migracji. Bez niego wektor zostaje otwarty.
Strona nie działa po włamaniu, a nie masz umowy opieki.
Nic nie wskazuje na włamanie, ale chcesz wiedzieć, czy strona jest czysta.
Audyt bezpieczeństwa: raport w ciągu 5 dni roboczych, uporządkowany według priorytetów.
Jak wykryć włamanie, zanim zrobi to Google
Ostrzeżenie w wynikach Google to późny objaw. Wcześniej włamanie zostawia ślady w plikach i w bazie. W opiece porównuję pliki rdzenia, wtyczek i motywów z sumami kontrolnymi z oficjalnych źródeł (wp checksum core, wp checksum plugin --all), więc zmieniony plik widać w ciągu doby. Skan malware szuka znanych wzorców złośliwego kodu, a comiesięczny przegląd kont administratorów wyłapuje konta, których nikt nie zakładał.
Drugie źródło to bazy podatności, między innymi Patchstack i WPScan. Gdy pojawia się luka we wtyczce, którą masz na stronie, aktualizuję ją poza cotygodniowym cyklem. To zamyka wektor, zanim ktoś z niego skorzysta.
Poprawki kodu po włamaniu
Gdy wektorem był własny kod strony, na przykład formularz we wtyczce napisanej dla firmy albo funkcja w motywie, która nie sprawdzała danych wejściowych, poprawiam go jako część zabezpieczenia przeciw ustalonemu wektorowi. Poprawka trafia do systemu kontroli wersji, a kod sprawdzam narzędziem PHP_CodeSniffer z regułami WordPress Coding Standards, które obejmują także reguły bezpieczeństwa, i analizą statyczną PHPStan. W serwisach spoza WordPressa trzymam się standardu PSR-12. Przed wdrożeniem przeglądam zmianę jeszcze raz, osobno od pisania. Jeśli poprawka wymaga przebudowy większej części kodu, opisuję ją i wyceniam osobno.
Co dostajesz po sprzątaniu
Po sprzątaniu dostajesz opis na piśmie: jak doszło do włamania, co zostało zmienione w plikach i w bazie, jakie dostępy zostały wymienione i jakie zabezpieczenia dodałem przeciw ustalonemu wektorowi. Ten opis przydaje się przy zgłoszeniu do UODO, jeśli je składasz, i przy rozmowie z hostingiem. Oczyszczona wersja jest wdrożona jednym krokiem z możliwością wycofania, a kopia zainfekowanej wersji zostaje jako dowód.
Jeśli chcesz, żeby po sprzątaniu ktoś stale pilnował strony, przechodzi ona do opieki w zwykłym abonamencie.
Czego nie obiecuję po włamaniu
Nie daję gwarancji, że strona nigdy więcej nie zostanie zhakowana. Sprzątanie usuwa złośliwy kod i zamyka wektor, który udało się ustalić, ale nowe luki we wtyczkach pojawiają się stale. Nie gwarantuję też czasu naprawy: zależy od zakresu infekcji, od dostępu do hostingu i od tego, czy kopie zapasowe są starsze niż infekcja. Nie obiecuję daty zdjęcia ostrzeżenia przez Google, bo przegląd prowadzi Google.
Obiecuję kolejność pracy opisaną wyżej, wynik diagnozy na piśmie przed sprzątaniem i raport z przyczyną i sposobem zapobiegania po nim.
Jak opieka zmniejsza ryzyko kolejnego włamania
W ramach opieki nad stroną WordPress codziennie robię kopie zapasowe i przechowuję je co najmniej 30 dni, skanuję pliki pod kątem malware i kontroluję integralność plików, a raz w miesiącu przeglądam konta administratorów. Monitoring sprawdza dostępność strony co 1 do 5 minut i wysyła mi alert, gdy strona przestaje odpowiadać. Gdy skan coś wykryje, izoluję zainfekowane elementy, przywracam czystą wersję z kopii, dodaję zabezpieczenia przeciw wektorowi i opisuję incydent w raporcie miesięcznym.
Trzydzieści dni kopii ma znaczenie przy włamaniach wykrytych z opóźnieniem. Gdy infekcja ma dwa tygodnie, w historii kopii nadal jest wersja sprzed niej. Nadal sprawdzam datę infekcji, zanim cokolwiek przywrócę.
Nieaktualna wtyczka z opublikowaną luką to otwarty wektor ataku. Przed nim chroni regularny cykl aktualizacji, który opisuję na stronie aktualizacje WordPress. Ile kosztuje opieka, która obejmuje skan i kopie, znajdziesz na stronie opieka WordPress cena.
Następny krok, jeśli strona jest zainfekowana teraz: nie kasuj niczego, zrób kopię plików i bazy, zapisz godzinę wykrycia i napisz do mnie z adresem strony i opisem objawów.
