Zhakowany WordPress: czyszczenie malware, kopie i zabezpieczenia

Dowiedz się więcej o usługach audytu bezpieczeństwa WordPress na WPPoland. Jeśli wolisz oddać sprzątanie komuś innemu, zobacz, jak wygląda usuwanie wirusów WordPress u mnie.

Ten przewodnik prowadzi krok po kroku przez czyszczenie zainfekowanej strony WordPress. Opiera się na narzędziach wiersza poleceń (SSH, WP-CLI), ponieważ są szybsze i dokładniejsze niż jakakolwiek wtyczka; skanery w postaci wtyczek pojawiają się niżej, w sekcji o dokumentacji WordPress.org.

#Oznaki zhakowania WordPressa

Przed rozpoczęciem czyszczenia potwierdź, że Twoja strona rzeczywiście jest skompromitowana. Najczęstsze oznaki to:

• Niechciane przekierowania: Odwiedzający są przekierowywani na strony ze spamem, farmacją lub kasynami
• Wstrzyknięty spam: Strony z tekstem w języku japońskim, chińskim lub linkami do złośliwych stron
• Nieznani administratorzy: Nowe konta administratorów, których nie tworzyłeś
• Ostatnio zmodyfikowane pliki: Pliki rdzenia, motywów lub wtyczek zmienione bez Twojej wiedzy
• Ostrzeżenia Google: etykieta ostrzegawcza w wynikach wyszukiwania albo pełnoekranowe ostrzeżenie w przeglądarce
• Spadek ruchu SEO: Google ukarał lub deindeksował Twoją stronę
• Wysyłanie spamu mailowego: Twój serwer wysyła niechciane maile
• Pogorszona wydajność: Strona stała się zauważalnie wolniejsza

Jeśli pierwszym sygnałem były japońskie strony w Google, a nie coś widocznego na samej stronie, najpewniej masz do czynienia z wariantem maskowanym (cloaking), który wymaga innego pierwszego kroku: zanim cokolwiek usuniesz, przeczytaj o japońskim hacku słów kluczowych.

#Jak atakujący dostają się do WordPressa

Złośliwe boty przeszukują sieć pod kątem znanych podatności, zgadują hasła administratorów metodą brute force i wykorzystują źle skonfigurowane serwery. Żeby wyczyścić stronę, trzeba najpierw zrozumieć, którędy wszedł atakujący.

#Podatności w nieaktualnych wtyczkach i motywach

Podatności takie jak SQL Injection (SQLi), Local File Inclusion (LFI) i Remote Code Execution (RCE) regularnie wychodzą w nieaktualnych wtyczkach. Atakujący automatycznie wyszukują strony ze znanymi podatnymi wersjami i uruchamiają na nich ładunki. Dwie klasy podatności są szczególnie groźne:

• PHP Object Injection (deserializacja): występuje, gdy dane od użytkownika trafiają wprost do funkcji unserialize() w PHP. Jeśli kod zawiera klasy pomocnicze nadające się na “POP chain”, atakujący może tworzyć dowolne obiekty PHP, wykonywać kod i zapisywać pliki w systemie.
• Nieograniczone przesyłanie plików: jeśli wtyczka źle sprawdza pliki wysyłane przez własne formularze (na przykład weryfikuje rozszerzenie tylko w przeglądarce, a nie na serwerze), atakujący może wgrać web shell udający obrazek, zapisać go w /wp-content/uploads/ i uruchomić bezpośrednim żądaniem HTTP.

#Słabe hasła i ataki brute force

Boty bez przerwy odpytują /wp-login.php i /xmlrpc.php listami popularnych haseł. Jeśli konto administratora ma słabe hasło, prędzej czy później zostanie przejęte.

#Jak atakujący wykorzystują xmlrpc.php

Starszy plik xmlrpc.php pozwala komunikować się z API WordPressa przez XML. Ponieważ obsługuje żądania multicall, atakujący może sprawdzić setki kombinacji loginu i hasła w jednym żądaniu HTTP i ominąć zwykłe limity logowania.

#Infekcja z innych stron na hostingu współdzielonym

Jeśli strona stoi na serwerze współdzielonym, podatność na stronie sąsiada może pozwolić atakującemu zapisywać pliki w drzewie katalogów i zainfekować Twoje czyste pliki.

#Co według WordPress.org zrobić najpierw, gdy strona została zhakowana

Artykuł pomocy WordPress.org FAQ Ja site was hacked traktuje pierwszą godzinę jako pracę dokumentacyjną, a nie czyszczenie. Pierwszy konkretny krok to zapisać, co widzisz, kiedy to zauważyłeś (ze strefą czasową) i co ostatnio się zmieniło: nowa wtyczka, edycja motywu, zmiana widżetu. Ta notatka staje się podstawą raportu z incydentu, niezależnie od tego, czy czyścisz stronę sam, czy przekazujesz ją komuś innemu.

Ten sam artykuł wymienia wskaźniki naruszenia, które wskazują na prawdziwe włamanie, a nie awarię: strona trafiła na czarną listę Google lub Bing, hosting ją wyłączył, jest oznaczona jako rozsyłająca malware, antywirusy odwiedzających ją blokują, ktoś zgłasza, że atakuje inne strony, albo pojawiają się konta, których nikt nie zakładał.

Do skanowania artykuł łączy skanery działające w aplikacji (wtyczki Wordfence, Sucuri, Quttera i GOTMLS) ze skanerami zdalnymi, takimi jak VirusTotal i Sucuri SiteCheck, bo każdy rodzaj wykrywa co innego.

Cztery punkty z tego artykułu łatwo pominąć w stresie:

• Przeskanuj też własny komputer. Artykuł zauważa, że infekcja często zaczyna się na komputerze właściciela, gdzie trojan przechwytuje dane logowania do FTP i wp-admin. Nowe hasła wpisane na zainfekowanym laptopie trafiają prosto do atakującego.
• Wcześnie porozmawiaj z hostingiem. Na hostingu współdzielonym włamanie może sięgać poza jedną stronę, a strona wykorzystana do wysyłki spamu może wprowadzić IP serwera na czarne listy pocztowe, co uderza w pocztę wysyłaną z tego samego serwera.
• Zainstaluj ponownie tę samą wersję i nie z poziomu wp-admin. Artykuł odradza opcje ponownej instalacji w kokpicie, bo takie instalatory często tylko nadpisują istniejące pliki, a włamania dodają nowe. Jako katalogi, które można bezpiecznie podmienić, wskazuje /wp-admin i /wp-includes.
• Zmień hasła dwa razy. Raz po wykryciu włamania i drugi raz po potwierdzeniu, że strona jest czysta, we wszystkich punktach dostępu: SFTP, wp-admin, panel hostingu i MySQL. Artykuł sugeruje też zmianę użytkownika i hasła bazy danych oraz odpowiednią aktualizację wp-config.php.

Wymienia również pliki, które warto przejrzeć ręcznie niezależnie od rodzaju infekcji, bo zmiana w nich wpływa na każde żądanie: .htaccess (w katalogu głównym i w każdym podkatalogu, który go ma), index.php oraz pliki motywu header.php, footer.php i functions.php.

#Jak wyłączyć zhakowanego WordPressa na czas czyszczenia

Przewodnik Google Quarantine your site zaleca zdjęcie zhakowanej strony z sieci, tak by przestała serwować treści użytkownikom, i odpowiadanie kodem 503, który oznacza chwilową niedostępność. Dla WordPressa ważne są dwa szczegóły:

• Serwuj 503 spoza zainfekowanego drzewa katalogów, na przykład z konfiguracji serwera WWW lub proxy, którą kontroluje hosting. Wtyczka trybu konserwacji albo plik PHP wewnątrz zainfekowanej instalacji działa obok malware.
• Sama odpowiedź 4xx lub 5xx nie wystarczy, bo “z tymi kodami stanu nadal można zwracać użytkownikom szkodliwe treści” (Google, Quarantine your site, tłumaczenie własne). Reguła disallow w robots.txt też nie wystarczy: blokuje tylko roboty wyszukiwarek, a nie odwiedzających.

Przewodnik stwierdza, że tymczasowe wyłączenie strony na czas naprawy raczej nie wpłynie na przyszłe pozycje. Pozostałe dwa kroki pokrywają się z zaleceniami WordPress.org: powiadom hosting, przejrzyj listę użytkowników, usuń konta założone przez atakującego i zmień wszystkie hasła (FTP, baza danych, administrator systemu i CMS).

Przywróć stronę do sieci przed zgłoszeniem jej do weryfikacji w Google, bo weryfikacja wymaga stron, które Googlebot może zaindeksować.

#Jak zrobić backup zhakowanego WordPressa

Przed wprowadzeniem jakichkolwiek zmian utwórz kompletny backup zainfekowanego stanu. To kluczowe z dwóch powodów: (1) jeśli coś pójdzie nie tak podczas czyszczenia, możesz przywrócić, i (2) możesz później przeanalizować malware, aby zrozumieć, jak doszło do naruszenia.

# Utworz kompletny backup plikow
tar -czf /tmp/backup-zainfekowany-$(date +%Y%m%d).tar.gz /var/www/html/

# Eksportuj baze danych
wp db export /tmp/backup-db-zainfekowany-$(date +%Y%m%d).sql --path=/var/www/html/

#Jak przejrzeć logi dostępu WordPressa przez SSH

Żeby ustalić punkt wejścia i czas włamania, przejrzyj logi dostępu serwera WWW poleceniami SSH. Znajdziesz w nich złośliwe żądania POST, które pokrywają się z datami modyfikacji plików.

# Adresy IP z duza liczba zadan POST do logowania lub XML-RPC
grep -h "POST /wp-login.php" /var/log/nginx/access.log* | awk '{print $1}' | sort | uniq -c | sort -nr | head -n 20
grep -h "POST /xmlrpc.php" /var/log/nginx/access.log* | awk '{print $1}' | sort | uniq -c | sort -nr | head -n 20

# Proby wykorzystania znanych sciezek
grep -E "wp-config\.php|\.env|eval\(|union\+select" /var/log/nginx/access.log

# Zadania IP, ktore modyfikowalo pliki w oknie ataku
grep "192.168.1.100" /var/log/nginx/access.log | grep -E "POST|PUT"

Ustalenie adresu IP i konkretnego skryptu, który obsłużył żądanie, wskazuje wykorzystaną wtyczkę lub motyw, więc możesz załatać podatność.

#Jak znaleźć malware na zhakowanym WordPressie

#Jak znaleźć podejrzane pliki PHP

Użyj grep do wyszukiwania typowych wzorców malware w plikach:

# Szukaj typowych funkcji obfuskacji
grep -rn "eval(" /var/www/html/wp-content/ --include="*.php"
grep -rn "base64_decode" /var/www/html/wp-content/ --include="*.php"
grep -rn "str_rot13" /var/www/html/wp-content/ --include="*.php"
grep -rn "gzinflate" /var/www/html/wp-content/ --include="*.php"

# Szukaj plikow PHP w uploads (NIE powinno ich być)
find /var/www/html/wp-content/uploads/ -name "*.php" -type f

# Szukaj plikow zmodyfikowanych w ostatnich 7 dniach
find /var/www/html/ -name "*.php" -mtime -7 -type f

#Jak sprawdzić administratorów w bazie danych

-- Szukaj podejrzanych administratorów
SELECT ID, user_login, user_email, user_registered
FROM wp_users
WHERE ID IN (
    SELECT user_id FROM wp_usermeta
    WHERE meta_key = 'wp_capabilities'
    AND meta_value LIKE '%administrator%'
);

#Najczęstsze rodzaje hacków WordPressa w 2026

#Jak wymienić rdzeń WordPressa po hacku

Najbezpieczniejsza metoda to zastąpienie wszystkich plików rdzenia czystymi wersjami:

# Pobierz czysty rdzen bez ruszania wp-content
wp core download --force --skip-content --path=/var/www/html/

# Zweryfikuj integralnosc
wp core verify-checksums --path=/var/www/html/

To zastępuje wp-admin/, wp-includes/ i wszystkie pliki rdzenia w katalogu głównym czystymi oryginałami, usuwając złośliwe modyfikacje tych plików.

#Jak czytać wynik wp core verify-checksums i weryfikacji wtyczek

wp core verify-checksums pobiera z WordPress.org sumy md5 dla zainstalowanej wersji i porównuje je z plikami na dysku. Według dokumentacji polecenia robi to bez ładowania WordPressa, co ma znaczenie na stronie, na której samo załadowanie WordPressa uruchamia malware.

Czysty rdzeń kończy się komunikatem Success: WordPress installation verifies against checksums. Każdy zmieniony plik daje linię w rodzaju Warning: File doesn't verify against checksum: wp-includes/version.php, a przebieg kończy się komunikatem Error: WordPress installation doesn't verify against checksums.

Opcje przydatne po włamaniu:

• --include-root sprawdza też katalog główny i ostrzega o elementach, które nie należą do WordPressa, a właśnie tam lądują loadery podrzucone obok wp-load.php.
• --version=<version> i --locale=<locale> porównują z konkretnym wydaniem i wersją językową.
• --format=json zwraca wynik do przetworzenia przez skrypt albo do zgłoszenia incydentu.
• --insecure ponawia pobieranie bez weryfikacji certyfikatu. Dokumentacja ostrzega, że naraża to żądanie na atak typu man-in-the-middle, więc na skompromitowanym serwerze go nie używaj.

wp core download --force jedynie nadpisuje istniejące pliki, jak podaje dokumentacja pobierania. Pliki dodane przez atakującego w wp-admin/ lub wp-includes/ mogą to przetrwać. Bezpieczniejsza kolejność to usunąć te dwa katalogi, które FAQ WordPress.org uznaje za bezpieczne do podmiany, a potem pobrać rdzeń i zweryfikować sumy.

Dla wtyczek wp plugin verify-checksums --all porównuje pliki z sumami z WordPress.org, a --strict sprawia, że błąd dają nawet “drobne zmiany”, takie jak edycja readme.txt (dokumentacja). Sumy pochodzą z WordPress.org, więc polecenie obejmuje wtyczki z katalogu WordPress.org. Wtyczki premium i pisane na zamówienie wymagają świeżej paczki od dostawcy albo z własnego repozytorium.

wp core verify-checksums --include-root --path=/var/www/html
wp plugin verify-checksums --all --strict --path=/var/www/html

#Jak wyczyścić wp-content na zainfekowanym WordPressie

#Jak przeinstalować wtyczki po hacku

Najbezpieczniejszy sposób to usunięcie i ponowna instalacja wszystkich wtyczek:

# Lista aktywnych wtyczek
wp plugin list --status=active --path=/var/www/html/

# Zainstaluj ponownie każda wtyczke z repozytorium
wp plugin install nazwa-wtyczki --force --path=/var/www/html/

Dla wtyczek premium pobierz świeże wersje od oryginalnego dostawcy.

#Co zrobić z motywami po hacku

Usuń wszystkie motywy oprócz aktywnego. Dla aktywnego motywu porównaj pliki z oryginalną wersją linia po linii.

#Jak usunąć pliki PHP z folderu uploads

Folder uploads NIGDY nie powinien zawierać plików PHP. Usuń wszystkie, które znajdziesz:

find /var/www/html/wp-content/uploads/ -name "*.php" -delete
find /var/www/html/wp-content/uploads/ -name "*.phtml" -delete
# Plik .htaccess tylko wylistuj i sprawdź, nie usuwaj: WooCommerce chroni woocommerce_uploads/ własnym .htaccess
find /var/www/html/wp-content/uploads/ -name ".htaccess"

#Jak wyczyścić bazę danych zhakowanego WordPressa

#Jak usunąć fałszywych administratorów

-- Usun podejrzanych użytkowników (najpierw zweryfikuj ID)
DELETE FROM wp_users WHERE ID IN (lista_podejrzanych_id);
DELETE FROM wp_usermeta WHERE user_id IN (lista_podejrzanych_id);

#Jak znaleźć wstrzyknięte skrypty w wp_posts i wp_options

-- Szukaj wstrzyknietych skryptow w postach
SELECT ID, post_title
FROM wp_posts
WHERE post_content LIKE '%<script%'
OR post_content LIKE '%eval(%';

-- Szukaj podejrzanych opcji
SELECT option_name, option_value
FROM wp_options
WHERE option_name LIKE '%hack%'
OR option_name LIKE '%inject%'
OR option_value LIKE '%base64_decode%';

#Jak usunąć backdoory z crona i konfiguracji WordPressa

Malware często planuje zadania cron, które ponownie infekują wyczyszczone pliki. Dlatego nawet po podmianie wszystkich plików systemowych strona może zostać zainfekowana ponownie w ciągu kilku godzin.

#Jak przejrzeć zadania cron WordPressa

Wszystkie zaplanowane zadania są zapisane jako zserializowane tablice w tabeli wp_options, w opcji cron. To polecenie WP-CLI pokazuje zaplanowane zdarzenia:

# Lista wszystkich zaplanowanych zdarzen cron
wp cron event list --path=/var/www/html

#Jak usunąć złośliwe zdarzenie cron w PHP

Jeśli znajdziesz nieznany hook crona (na przykład wp_update_system_cache odwołujący się do dynamicznego kodu), ten skrypt PHP go usunie:

declare(strict_types=1);

namespace WPPoland\Security\Cron;

/**
 * Usuwa złośliwe hooki crona z harmonogramu.
 */
function remove_malicious_cron_event(): void {
    $target_hook = 'wp_update_system_cache';

    // Usun hook, jesli jest zaplanowany
    $timestamp = wp_next_scheduled( $target_hook );
    if ( $timestamp ) {
        wp_unschedule_event( $timestamp, $target_hook );
        error_log( sprintf( 'Security Action: Unscheduled backdoor hook "%s".', $target_hook ) );
    }
}
add_action( 'init', __NAMESPACE__ . '\\remove_malicious_cron_event' );

#Jak znaleźć backdoory w .user.ini i .htaccess

Popularny sposób na utrzymanie dostępu to wstrzyknięcie plików .user.ini lub .htaccess w katalogu głównym strony. Atakujący ustawia dyrektywy PHP takie jak auto_prepend_file, żeby uruchomić złośliwy skrypt, zanim załaduje się jakikolwiek kod WordPressa:

; Zlosliwy backdoor w .user.ini
auto_prepend_file = "/var/www/html/wp-content/uploads/2026/06/backdoor.jpg"

Ponieważ ten plik działa globalnie, każde żądanie PHP, łącznie z ekranem logowania, uruchamia backdoor. Sprawdź zmiany w .user.ini i .htaccess w katalogu głównym i upewnij się, że żaden nieautoryzowany skrypt nie jest dołączany przed ani po kodzie strony.

#Jak wzmocnić WordPressa po usunięciu malware

Po czyszczeniu wzmocnij swoją stronę przed przyszłymi atakami:

#Jak zmienić hasło admina i klucze salt

# Zmien haslo administratora
wp user update admin --user_pass="nowe-bezpieczne-haslo" --path=/var/www/html/

# Regeneruj Salt Keys (wylogowuje wszystkie aktywne sesje)
wp config shuffle-salts --path=/var/www/html/

#Jakie zabezpieczenia dodać w wp-config.php

// Wylacz edycje plikow z panelu admin
define('DISALLOW_FILE_EDIT', true);

// Wylacz instalacje wtyczek/motywow z panelu admin
define('DISALLOW_FILE_MODS', true);

// Wymus SSL w panelu admin
define('FORCE_SSL_ADMIN', true);

#Jakie uprawnienia plików ustawić w WordPressie

# Katalogi: 755
find /var/www/html/ -type d -exec chmod 755 {} \;

# Pliki: 644
find /var/www/html/ -type f -exec chmod 644 {} \;

# wp-config.php: 400 (tylko do odczytu)
chmod 400 /var/www/html/wp-config.php

#Kto powinien być właścicielem plików WordPressa

Poza uprawnieniami sprawdź właściciela plików. Proces serwera WWW (na przykład www-data lub apache) nie powinien być właścicielem plików PHP WordPressa. Ustaw jako właściciela osobnego użytkownika wdrożeniowego (na przykład wp-user), a jako grupę www-data. Wtedy przejęty proces serwera WWW nie zapisze ani nie zmieni żadnego pliku .php w strukturze systemu:

# Wlasciciel: uzytkownik wdrozeniowy, grupa: serwer WWW
chown -R wp-user:www-data /var/www/html/

# Zapis dla serwera WWW tylko w uploads
chown -R www-data:www-data /var/www/html/wp-content/uploads/

#System plików tylko do odczytu dla WordPressa w Dockerze

Oficjalna dokumentacja obrazu (docker-library/docs) opisuje wdrożenie statyczne: zbuduj własny obraz z kodem w /usr/src/wordpress i uruchom go w trybie tylko do odczytu, z zapisywalnym miejscem wyłącznie dla /tmp, /run i opcjonalnie wp-content/uploads. Domyślnie obraz trzyma WordPressa w zapisywalnym wolumenie /var/www/html i tam się aktualizuje, więc read_only: true na standardowym obrazie nie daje tej ochrony.

FROM wordpress:apache
WORKDIR /usr/src/wordpress
RUN set -eux; \
	find /etc/apache2 -name '*.conf' -type f -exec sed -ri -e "s!/var/www/html!$PWD!g" -e "s!Directory /var/www/!Directory $PWD!g" '{}' +; \
	cp -s wp-config-docker.php wp-config.php
COPY custom-theme/ ./wp-content/themes/custom-theme/
COPY custom-plugin/ ./wp-content/plugins/custom-plugin/

# docker-compose.yml: wlasny obraz tylko do odczytu
services:
  wordpress:
    image: custom-wordpress:tag
    read_only: true
    tmpfs:
      - /tmp
      - /run
    volumes:
      - ./uploads:/usr/src/wordpress/wp-content/uploads

Przy zamkniętej warstwie kodu błąd pozwalający zapisywać pliki sięga tylko wolumenu uploads, dlatego kontrole folderu uploads z tego przewodnika nadal są potrzebne. Aktualizacja oznacza wtedy przebudowanie i ponowne wdrożenie obrazu, a dokumentacja przypomina, by robić to regularnie, żeby dostawać poprawki bezpieczeństwa WordPressa.

#Co dodaje przewodnik po zabezpieczaniu WordPressa po czyszczeniu

Przewodnik Hardening WordPress ustawia wp-config.php na 400 lub 440, tak by czytać go mogli tylko Ty i serwer WWW. O DISALLOW_FILE_EDIT pisze, że “nie powstrzyma atakującego przed wgraniem złośliwych plików na stronę, ale może zatrzymać część ataków” (WordPress.org, Hardening WordPress, tłumaczenie własne). Użytkownikowi bazy danych do normalnej pracy wystarczą uprawnienia odczytu i zapisu, ale przewodnik odradza odbieranie uprawnień strukturalnych, takich jak ALTER, bo część aktualizacji i wtyczek zmienia schemat. W kwestii monitoringu zaleca uruchamianie kontroli plików jako root, żeby atakujący nie mógł łatwo jej wyłączyć, obserwowanie tylko plików wykonywalnych, takich jak .php, dla ograniczenia szumu, oraz regularne kopie, dzięki którym masz wersje sprzed i po włamaniu.

#Jak sprawdzić, że malware z WordPressa zostało usunięte

#Lista kontrolna po usunięciu malware

• Rdzeń WordPressa zweryfikowany za pomocą checksums
• Wszystkie wtyczki zainstalowane ponownie z czystych źródeł
• Pliki PHP usunięte z uploads
• Fałszywe konta administratorów usunięte
• Hasła zmienione dla wszystkich użytkowników
• Salt Keys zregenerowane
• Uprawnienia plików poprawione
• DISALLOW_FILE_EDIT włączone
• XML-RPC wyłączone jeśli nie jest potrzebne
• Wtyczka bezpieczeństwa zainstalowana (Wordfence, Sucuri)
• Automatyczne backupy skonfigurowane

#Jak Google zgłasza zhakowaną stronę i ile trwa weryfikacja

Ustalenia Google pojawiają się w Search Console, w raporcie problemów dotyczących bezpieczeństwa (Pomoc Search Console). Strony, których to dotyczy, mogą dostać etykietę ostrzegawczą w wynikach wyszukiwania albo pełnoekranowe ostrzeżenie w przeglądarce. Raport używa czterech kategorii włamań:

Ta sama strona pomocy ustala trzy zasady. Napraw problem w całej witrynie, bo poprawienie tylko części stron nie przywraca strony do wyników nawet częściowo. Kliknij Request Review dopiero wtedy, gdy wszystkie problemy z raportu są naprawione na wszystkich stronach. Nie wysyłaj prośby ponownie, dopóki poprzednia czeka na decyzję. Dobra prośba wyjaśnia dokładny problem, opisuje kroki naprawcze i dokumentuje ich efekt. Jeśli w zespole nie ma nikogo, kto przeprowadzi czyszczenie do końca, opisz objawy na stronie naprawy i wsparcia technicznego WordPress.

Przewodnik Google Request a review dodaje warunki wstępne: potwierdzone prawo własności w Search Console, wyczyszczona strona, usunięta podatność i strona z powrotem w sieci, żeby Googlebot mógł ją zaindeksować. Najpierw sprawdź cURL-em lub Wgetem stronę główną i adres zmieniony przez atakującego. Prośba wysłana, gdy problem nadal istnieje, wydłuża czas, przez jaki strona pozostaje oznaczona.

Jeśli Google uzna stronę za czystą, ostrzeżenia w przeglądarce i wyszukiwarce znikają w ciągu 72 godzin. Jeśli nie, raport może pokazać więcej przykładowych adresów, a ostrzeżenia zostają. Google to nie jedyna lista: FAQ WordPress.org zaleca zarejestrowanie strony także w Bing Webmaster Tools, Yandex Webmaster i Norton Safe Web, bo odwiedzający mogą korzystać z dowolnej z nich.

Google ogłosił 20 października 2026, że Chrome dzieli ostrzeżenia Safe Browsing o stronach na dwa poziomy, ale tylko u użytkowników z włączoną rozszerzoną ochroną: strony podejrzane (werdykt o niższej pewności, możliwe ryzyko szkody) i strony niebezpieczne (werdykt o wysokiej pewności, wysokie ryzyko szkody) (Google, 20 października 2026). Strony niebezpieczne nadal dostają czerwone ostrzeżenie na cały ekran. Ostrzeżenie o stronie podejrzanej ma inny układ, ikonę, kolor i tekst, a Google wyświetla je, gdy strona zdradza zwodnicze wzorce typowe dla znanych złośliwych witryn.

#Jak chronić WordPressa przed kolejnym hackiem

Najlepsza obrona to zapobieganie:

• Zawsze aktualizuj: Rdzeń, wtyczki i motywy, automatycznie jeśli to możliwe
• Używaj silnych haseł: Minimum 16 znaków, unikalnych dla każdego konta
• Wdrażaj 2FA: Uwierzytelnianie dwuskładnikowe dla wszystkich kont admin
• Bezpieczny hosting: VPS z firewallem, nie hosting współdzielony
• Codzienne backupy: Zautomatyzowane i przechowywane poza serwerem
• Ciągłe monitorowanie: Alerty o zmianach plików i podejrzanej aktywności

#Jak wygląda 90-dniowy plan zabezpieczenia WordPressa

• Dni 1-30 (natychmiastowa selekcja): pełny audyt integralności plików przez WP-CLI, żeby wykryć zmienione pliki rdzenia. Zmień hasła do bazy danych, dane root bazy danych i klucze dostępu SSH/SFTP. Zmień klucze salt w wp-config.php, żeby zamknąć aktywne sesje, i wyłącz bezpośrednią edycję motywów i wtyczek przez DISALLOW_FILE_EDIT.
• Dni 31-60 (analiza i zapory): przejrzyj aktywne zadania cron WordPressa, żeby potwierdzić, że nie zostały żadne złośliwe funkcje. Przeanalizuj logi serwera WWW pod kątem nietypowych zachowań, skoków POST do XML-RPC i wzorców LFI. Wdroż zaporę aplikacji webowych (WAF) na serwerze albo reverse proxy (na przykład Cloudflare), żeby blokować ładunki SQLi i XSS na brzegu sieci.
• Dni 61-90 (wzmacnianie i audyt): skonfiguruj automatyczne kopie poza serwerem w magazynie typu WORM (jednokrotny zapis, wielokrotny odczyt). Przeprowadź statyczną analizę kodu i testy penetracyjne własnych motywów i wtyczek. Zaplanuj kwartalne skanowanie bezpieczeństwa i spisz procedurę reagowania na incydenty dla zespołu.

Poznaj moje usługi audytu bezpieczeństwa WordPress i opiekę techniczną WordPress aby profesjonalnie chronić swoją stronę.