Hosting zhakowany: co zmienić w WordPressie i WooCommerce

23 października 2026 r. DreamHost odkrył, że ktoś wszedł na serwer obsługujący jego webowy File Manager. Z listu do klientów wynika, że w ręce atakującego mogły trafić nazwy użytkowników i hasła FTP/SFTP. Jeśli twój sklep stoi na takim hostingu, a SFTP otwiera pliki witryny, to otwiera też wp-config.php. Dalej: co ustalił DreamHost, co zmienić w WordPressie i WooCommerce, w jakiej kolejności, jak sprawdzić, czy ktoś coś zostawił, i co z tego wynika dla ciebie jako administratora danych.

Artykuł nie jest poradą prawną. Opisuję przepisy i dokumenty w brzmieniu z 6 listopada 2026 r.

#Co dokładnie wydarzyło się w DreamHost?

Fakty pochodzą z komunikatu DreamHost z 29 października, z listu zgłoszonego 2 listopada w prokuraturze generalnej Kalifornii (wpis w rejestrze naruszeń) oraz z tekstu TechCrunch z 4 listopada.

• W piątek 23 października po południu DreamHost wykrył, że nieuprawniona osoba weszła na serwer, na którym działa webowy File Manager. Serwery wyłączono, a maszynę zachowano do analizy. Resety haseł do poczty i FTP/SFTP poszły w piątek wieczorem i w weekend.
• Atakujący wykorzystał podatność w oprogramowaniu trzeciej strony, na którym zbudowano File Manager. DreamHost nie podał nazwy produktu. Firma twierdzi też, że incydent nie miał związku z niedawnymi aktualizacjami PHP.
• Wpis w rejestrze kalifornijskim podaje jako datę naruszenia 15 sierpnia 2026 r. Sam list mówi tylko o okresie od sierpnia 2026 r. do 23 października.

Zagrożone dane, według listu: nazwy użytkowników i hasła FTP/SFTP osób, które logowały się w File Managerze mniej więcej od sierpnia do 23 października. Do tego sesje poczty webowej “ograniczonej liczby użytkowników”. List dodaje, że treść poczty i pliki na serwerze FTP/SFTP “mogły” zostać odczytane. DreamHost nie widzi dowodu dostępu do danych logowania panelu ani do danych rozliczeniowych klientów. Skala to według komunikatu “znacznie poniżej około 10%” kont poczty i FTP/SFTP, bez liczby bezwzględnej.

#Dlaczego DreamHost i TechCrunch opisują to różnie?

Teksty rozchodzą się w trzech miejscach.

Poczta webowa. List mówi o informacji o sesji, czyli danych, które utrzymują użytkownika zalogowanego, w tym poświadczeniach sesji. Komunikat opisuje to jako dane logowania do poczty webowej. Oba teksty pochodzą od DreamHost.

Zakres. TechCrunch pisze w nagłówku o kradzieży plików i skrzynek oraz o ataku trwającym miesiące. List DreamHost używa słowa “mogły”. Rejestr kalifornijski podaje 15 sierpnia jako początek, ale nie wiadomo, czy atakujący był na serwerze od połowy sierpnia, czy dopiero od tego czasu zbierał hasła. Tego firma nie wyjaśnia.

Bazy danych. W żadnym z dokumentów nie ma słowa o hasłach MySQL, kluczach API ani użytkownikach powłoki SSH jako takich. Nie wiem więc, czy ktoś odczytał wp-config.php. Z budowy WordPressa wynika tylko, że dostęp odczytu do plików witryny daje taką możliwość. To jest moje wnioskowanie, nie stanowisko DreamHost.

#O co DreamHost prosi klientów?

Firma prosi o zmianę haseł w panelu (panel.dreamhost.com), co może potrwać do 15 minut i może to zrobić tylko właściciel konta. Hasła FTP/SFTP użyte w File Managerze w tym okresie trzeba uznać za przejęte, a to samo lub podobne hasło zmienić wszędzie indziej. Trzeba zaktualizować programy pocztowe i klienty FTP, które trzymają stare hasło, przejrzeć pliki witryny pod kątem nieoczekiwanych zmian oraz ustawienia poczty, w tym reguły przekazywania i filtry. Warto też zastanowić się, czy treść poczty lub plików daje dostęp do innych kont. DreamHost zapowiada, że nigdy nie prosi o hasło mailem.

To dobry punkt wyjścia, ale dotyczy kont hostingu. Sklep na WordPressie ma jeszcze własne sekrety i konta, których DreamHost nie zna.

#Co zmienić w WordPressie i WooCommerce po ataku na hosting, w jakiej kolejności?

Dokumentacja WordPressa każe zmienić wszystkie punkty dostępu: FTP/SFTP, wp-admin, panel hostingu lub inny panel administracyjny i MySQL, dla wszystkich użytkowników, którzy mają dostęp. Zmiany trzeba też powtórzyć po tym, jak upewnisz się, że witryna jest czysta. Jeśli hasła zmieniłeś tuż po wykryciu włamania, zmień je jeszcze raz (WordPress.org, FAQ: my site was hacked).

Kolejność, którą stosuję, wynika z tego, co od czego zależy:

1. Własny komputer. Pełny skan antywirusowy, bo trojany podsłuchują loginy FTP i wp-admin. Zmieniasz hasła z maszyny, której ufasz.
2. Poczta. Na adresy skrzynek przychodzą linki do resetu hasła wp-admin, a DreamHost prosi wprost o przejrzenie reguł przekazywania i filtrów. Zmień hasła do skrzynek i sprawdź reguły przekazywania oraz filtry. Atakujący z dostępem do poczty może przejąć każde konto, któremu zresetuje hasło.
3. Panel hostingu i dostęp SFTP/SSH. Nowe hasła, a tam gdzie można, klucze. Zaktualizuj klienty FTP i skrypty wdrożeniowe, które trzymają stare dane.
4. Hasło do bazy danych. Zmień użytkownika lub hasło w panelu hostingu, a nowe dane wpisz do wp-config.php. WordPress sam sugeruje rozważenie takiej zmiany.
5. Klucze uwierzytelniania i sole. Wygeneruj nowe z generatora WordPress.org i nadpisz je w wp-config.php albo uruchom wp config shuffle-salts (dokumentacja WP-CLI). Skutek jest taki, że wszyscy zalogowani zostaną wylogowani, a ciasteczka przestaną działać.
6. Konta WordPressa. Przejrzyj administratorów, usuń nieznane konta, zmień hasła pozostałych i unieważnij hasła aplikacji.
7. Klucze integracji: WooCommerce, Stripe, webhooki.

Dlaczego sole przed kontami: dopóki działają stare klucze, ciasteczko sesji skradzione wcześniej nadal może być ważne.

To samo w tabeli:

Reguły przekazywania sprawdzasz w ustawieniach każdej skrzynki, która jest adresem administratora WordPressa, adresem sklepu lub adresem kontaktowym z faktur. Szukasz reguły, której nie założyłeś: automatycznego przekazania wszystkich wiadomości na obcy adres albo filtra, który usuwa wiadomości o resecie hasła lub z płatności. Po stronie hostingu zrób to samo dla aliasów i przekierowań domen. Kolejność ma tu znaczenie: dopóki atakujący może czytać pocztę, zmiana hasła w wp-admin niewiele daje.

#Jak sprawdzić, czy ktoś zostawił coś w witrynie?

Większość pracy wykonują trzy polecenia WP-CLI. Uruchom je na serwerze przez SSH w katalogu witryny.

wp user list --role=administrator
wp core verify-checksums
wp plugin verify-checksums --all

wp user list --role=administrator pokazuje administratorów razem z datą rejestracji (dokumentacja). Konto założone w sierpniu lub październiku, którego nie rozpoznajesz, jest sygnałem alarmowym.

wp core verify-checksums porównuje pliki rdzenia z sumami z WordPress.org (dokumentacja). Opcja --include-root ostrzega o plikach w katalogu głównym, które nie należą do WordPressa.

wp plugin verify-checksums --all robi to samo dla wtyczek (dokumentacja). Opcja --strict oznacza także zmiany w plikach readme. Sumy pochodzą z WordPress.org, więc wtyczki płatne i własny kod nie są objęte. To wniosek z opisu polecenia, nie osobne oświadczenie dokumentacji.

Czego te polecenia nie znajdą: dodatkowych plików w katalogu uploads, zmian w motywie i kodu we wtyczkach spoza repozytorium. Dokumentacja WordPressa wskazuje pliki do ręcznego przeglądu: .htaccess w katalogu głównym i podkatalogach, index.php oraz header.php, footer.php i functions.php motywu. Można też podmienić /wp-admin i /wp-includes plikami tej samej wersji.

Hasła aplikacji sprawdzisz w profilu użytkownika. Zapisują datę i adres IP ostatniego użycia, z dokładnością do 24 godzin. Z linii poleceń: wp user application-password list <użytkownik> i wp user application-password delete (dokumentacja). Jeśli któreś hasło ma ostatnie użycie z adresu, którego nie znasz, traktuj to jak ślad włamania.

Jak czytać wyniki? Poprawny przebieg wp core verify-checksums kończy się komunikatem o powodzeniu. Gdy plik się różni, polecenie wypisuje jego ścieżkę z uwagą, że suma nie zgadza się, albo że pliku nie powinno być w instalacji. Pierwsze znaczy zmieniony plik rdzenia, drugie dodany. W obu przypadkach zapisz listę, zanim cokolwiek skasujesz, bo posłuży jako dowód i jako mapa miejsc do przejrzenia. Przy wp plugin verify-checksums --all zwróć uwagę na wtyczki, dla których polecenie nie może pobrać sum: to najczęściej wtyczki spoza repozytorium, czyli te, których ten test nie sprawdza.

Przy wp user list --role=administrator czytaj kolumnę z datą rejestracji. Szukasz konta założonego w okresie od sierpnia do 23 października, adresu e-mail z obcej domeny albo loginu udającego techniczny (na przykład kopii nazwy motywu). Nie traktuj jednak braku nowych kont jako dowodu czystości: atakujący z dostępem do bazy może zmienić hasło istniejącemu administratorowi.

Opisane wyniki to ogólna zasada działania poleceń, nie zapis z konkretnego serwera. Dokładny tekst komunikatów zależy od wersji WP-CLI.

Jeżeli którakolwiek z tych kontroli coś wykryje, przejdź do osobnego przewodnika: jak wyczyścić zhakowaną stronę WordPress.

#Jak wymienić klucze WooCommerce, Stripe i webhooków bez przerwy w sprzedaży?

Klucze REST API WooCommerce odwołujesz w panelu: WooCommerce, Ustawienia, Zaawansowane, REST API, przy kluczu przycisk odwołania. Następnie wystawiasz nowe dla każdej integracji, która z nich korzysta (dokumentacja WooCommerce). Przy kilku integracjach (hurtownia, program księgowy, system magazynowy) rób to po jednej, żeby wiedzieć, która przestała działać. Zanim odwołasz klucz, sprawdź w tej samej tabeli, kiedy był ostatnio używany i przez jakiego użytkownika. Klucz bez śladu użycia możesz odwołać bez wystawiania następcy.

Klucze Stripe wymieniasz, jeśli klucz tajny lub ograniczony mógł wyciec. Stripe wymienia tę sytuację wprost jako powód rotacji: gdy klucz jest przejęty, trzeba go unieważnić, żeby zablokować żądania, które mogłyby go użyć (Stripe, klucze API). Kroki w panelu, według dokumentacji:

1. Na stronie kluczy API otwórz menu (trzy kropki) przy kluczu i wybierz “Rotate key”.
2. W polu wygaśnięcia wybierz czas. Przy “Now” stary klucz jest od razu usuwany. Jeśli wskażesz czas, oba klucze działają do tego momentu, maksymalnie 7 dni.
3. Skopiuj nowy klucz i zapisz go od razu, bo później go nie odczytasz. Wpisz nowy klucz w ustawieniach wtyczki płatności albo, jeśli trzymasz go w wp-config.php, w pliku.
4. Przed wygaśnięciem starego klucza obejrzyj jego dziennik żądań w panelu i wygaś go dopiero wtedy, gdy ruch spadnie do zera.

Przy podejrzeniu włamania wybieram “Now”, bo zachowanie starego klucza przez 7 dni zostawia atakującemu okno. To moja decyzja, nie zalecenie Stripe, który dla spokojnej rotacji proponuje okres przejściowy. Jeśli sklep nie może stanąć, wdrażam nowy klucz przed rotacją i klikam “Now” zaraz po sprawdzeniu pierwszej płatności testowej.

Dobrą praktyką z tej samej strony jest ograniczenie kluczy produkcyjnych politykami dostępu: według adresu IP albo, w trybie zaawansowanym, według numeru ASN, kraju i kategorii źródeł (na przykład Tor). Stripe zaleca polityki dla wszystkich kluczy produkcyjnych i zapowiada powiadomienie przy próbie użycia klucza spoza dozwolonych adresów. Stripe zaleca też klucze ograniczone (rk_) zamiast pełnych kluczy tajnych (sk_) w nowych integracjach.

Sekret podpisu webhooka (zaczyna się od whsec_) to coś innego niż klucz API i ma osobną rotację (Stripe, webhooki):

1. W Workbench otwórz zakładkę Webhooks i kliknij endpoint, którego dotyczy zmiana.
2. W menu (trzy kropki) wybierz “Roll secret”.
3. Wybierz, czy bieżący sekret wygasa natychmiast, czy po czasie do 24 godzin. W tym czasie aktywnych jest kilka sekretów, a Stripe dołącza jeden podpis na każdy z nich.
4. Wpisz nowy sekret w ustawieniach wtyczki, która odbiera webhooki, i sprawdź dostarczanie zdarzeń w zakładce z dostawami.

Stripe zaznacza, że weryfikacja podpisu wymaga surowej treści żądania. Jeśli po zmianie sekretu płatności przestają się księgować, najpierw sprawdź, czy wtyczka nie dostaje już zmodyfikowanej treści, na przykład po wdrożeniu nowej reguły zapory.

Na stronie WordPress.org nie znalazłem oficjalnej listy “wymień klucze bramek płatności po włamaniu do hostingu”. Ta część jest zbiorem dokumentacji poszczególnych dostawców, połączonym moim wnioskiem: skoro SFTP daje odczyt wp-config.php i bazy, sekrety z nich należy uznać za ujawnione.

#Czy muszę zgłosić takie włamanie do UODO?

Hosting jest podmiotem przetwarzającym, a właściciel sklepu administratorem danych. Obowiązek zgłoszenia do organu nadzorczego i zawiadomienia klientów spoczywa na administratorze. Hostingowi wolno tylko przekazać mu informację o naruszeniu.

Przepisy RODO (rozporządzenie 2016/679, tłumaczenie własne):

• Art. 28 ust. 3 lit. f: podmiot przetwarzający pomaga administratorowi wypełniać obowiązki z art. 32 do 36.
• Art. 33 ust. 2: podmiot przetwarzający zgłasza naruszenie administratorowi bez zbędnej zwłoki po jego stwierdzeniu.
• Art. 33 ust. 1: administrator zgłasza naruszenie organowi nadzorczemu bez zbędnej zwłoki i, o ile to możliwe, w ciągu 72 godzin od stwierdzenia, chyba że jest mało prawdopodobne, by naruszenie skutkowało ryzykiem naruszenia praw lub wolności osób. Spóźnione zgłoszenie wymaga uzasadnienia.
• Art. 34 ust. 1: osoby, których dane dotyczą, zawiadamiasz bez zbędnej zwłoki, gdy naruszenie może powodować wysokie ryzyko.
• Art. 33 ust. 5: każde naruszenie dokumentujesz (fakty, skutki, działania naprawcze), także to, którego nie zgłaszasz.

Od kiedy płyną 72 godziny? Wytyczne EDPB 9/2022 w pkt 44 przyjmują, że co do zasady administrator “dowiaduje się” o naruszeniu, gdy poinformuje go podmiot przetwarzający (wytyczne EDPB 9/2022, wersja 2.0). W sprawie DreamHost zegar zaczyna więc, zgodnie z tą zasadą, biec w chwili, gdy dotarło do ciebie powiadomienie hostingu (mail z resetem hasła z 23 do 25 października albo formalny list), a nie 15 sierpnia. Ocena ryzyka należy do ciebie, nie do hostingu.

Co z tego wynika w praktyce, to moja interpretacja, a nie rozstrzygnięcie organu w tej sprawie. Sklep, w którym po SFTP można było dojść do wp-config.php i bazy z imionami, adresami i historią zamówień klientów, wskazuje na naruszenie, które prawdopodobnie trzeba zgłosić. Strona wizytówkowa bez danych osobowych może wymagać tylko wpisu do wewnętrznego rejestru z art. 33 ust. 5.

W Polsce zgłoszenie składasz do Prezesa UODO. Urząd opisuje kolejne kroki na stronie uodo.gov.pl:

1. Termin: bez zbędnej zwłoki, w miarę możliwości nie później niż 72 godziny po stwierdzeniu naruszenia. Obowiązek nie dotyczy sytuacji, gdy naruszenie raczej nie powoduje ryzyka dla osób.
2. Ocena ryzyka: robi ją administrator, czyli ty. Strona zaznacza, że oceny trzeba dokonać szybko po wykryciu.
3. Podmiot przetwarzający, czyli hosting, ma zawiadomić administratora bez zbędnej zwłoki po stwierdzeniu naruszenia.
4. Zgłoszenie składasz na formularzu UODO. Jeśli to zgłoszenie wstępne, zaznacz pole “Zgłoszenie wstępne” w punkcie 1 formularza.
5. Gdy nie masz jeszcze wszystkich informacji, wyślij to, co masz, w tym samym terminie, a resztę uzupełnij później.
6. Jeśli trzeba, administrator zawiadamia też osoby, których dane dotyczą. Strona nie opisuje treści ani formy takiego zawiadomienia.

Lista pól zgłoszenia jest w formularzu, nie na stronie, więc przed wysłaniem przeczytaj formularz do końca. Gdzie dokładnie go znajdziesz, sprawdź na stronie UODO, bo kanału online w samym serwisie nie potwierdzałem.

Jest jeszcze komunikat UODO z 12 sierpnia 2026 r. o naruszeniu po stronie podmiotu przetwarzającego (uodo.gov.pl/pl/138/4538), w którym urząd pisze, że administrator, zanim przystąpi do obowiązków z art. 33 ust. 1 i art. 34, powinien otrzymać od podmiotu przetwarzającego informację potwierdzającą, że incydent dotyczył danych osobowych związanych z jego działalnością. Jeśli DreamHost nie napisał tego wprost, poproś o to potwierdzenie przez formularz wsparcia, temat “Account security”.

#Co jeszcze zostaje niewyjaśnione?

• Nazwa podatnego oprogramowania i ewentualny numer CVE.
• Liczba poszkodowanych klientów: tylko “znacznie poniżej 10%”, przy około 400 000 płacących klientów deklarowanych przez DreamHost, według TechCrunch.
• To, czy ktoś odczytał wp-config.php, klucze SSH lub hasła do baz.
• Czy atakujący był na serwerze od połowy sierpnia, czy hasła zbierano od tej daty.

DreamHost może dopowiedzieć szczegóły, więc sprawdź komunikat przed decyzją.

#Od czego zacząć, jeśli twój hosting miał incydent?

Zrób kopię plików i bazy do osobnego miejsca, potem przejdź kolejnymi punktami z listy powyżej i zapisz godziny, w których dowiedziałeś się o incydencie i co zrobiłeś. Ten zapis jest podstawą wpisu z art. 33 ust. 5 i pokaże, od kiedy liczyć 72 godziny.

Jeśli sklep stoi na WooCommerce i chcesz, żebym przeszedł tę listę na twoim serwerze, zacznij od strony programista WooCommerce. Napisz, kto jest twoim hostingiem i jakie bramki płatności podpiąłeś, a odpowiem, od czego zacząć.