Kiedy podejrzewać infekcję WordPressa

Infekcja WordPressa nie zawsze daje od razu oczywiste objawy, ale są sygnały, których nie warto ignorować. Jeśli strona zaczęła przekierowywać użytkowników na obce domeny, pojawia się spam w treści lub komentarzach, a w panelu administracyjnym widzisz nieznane konta, to sytuacja wymaga szybkiej weryfikacji.

Niepokojące są także zmiany w działaniu serwisu, które trudno wyjaśnić aktualizacją lub ruchem użytkowników. Do typowych symptomów należą:

• spadek wydajności i nagłe obciążenie serwera,
• ostrzeżenia przeglądarki, Google lub antywirusa o złośliwej zawartości,
• problemy z wysyłką maili z WordPressa,
• zmiany w plikach, których nikt świadomie nie edytował,
• podejrzane wpisy w logach serwera lub logach bezpieczeństwa.

Warto zwrócić uwagę również na sytuacje, w których strona zachowuje się inaczej tylko w określonych godzinach, dla nowych użytkowników albo na urządzeniach mobilnych. Malware często bywa ukryty i aktywuje się warunkowo, żeby utrudnić wykrycie.

Brak objawów nie wyklucza infekcji. Złośliwy kod może działać cicho, służyć jako backdoor, zbierać dane lub przygotowywać serwis do późniejszego ataku. Dlatego podejrzenie infekcji powinno wynikać nie tylko z widocznych problemów, ale też z nietypowych zmian w plikach, bazie danych i logach.

Jeśli masz choć jeden z tych sygnałów, potraktuj stronę jak potencjalnie naruszoną i przejdź do dalszej diagnostyki zamiast czekać, aż problem sam zniknie.

Przygotowanie do skanowania: kopia, dostęp i bezpieczeństwo

Zanim zaczniesz jakąkolwiek diagnostykę, wykonaj pełną kopię zapasową plików i bazy danych. To ważne nawet wtedy, gdy strona już wygląda na zainfekowaną, bo podczas skanowania możesz natrafić na pliki, które wymagają podmiany, oraz wpisy w bazie, które łatwo uszkodzić przez przypadek. Backup powinien obejmować cały katalog WordPressa, bazę danych oraz najlepiej wszystkie pliki konfiguracyjne i logi, do których masz dostęp.

Jeśli to możliwe, pracuj nie na produkcji, lecz na kopii środowiska albo przywróconym klonie strony. Dzięki temu ograniczysz ryzyko dalszego rozprzestrzeniania infekcji i unikniesz sytuacji, w której ręczna analiza spowoduje kolejne szkody lub widoczne przerwy w działaniu serwisu. Gdy nie masz kopii testowej, przynajmniej ogranicz dostęp do panelu administracyjnego i nie wykonuj zmian bez planu.

Do sensownej weryfikacji przydadzą się różne poziomy dostępu, bo malware bywa ukryte zarówno w plikach, jak i w bazie czy logach serwera. Najczęściej potrzebujesz:

• FTP/SFTP do przeglądania i pobierania plików,
• panelu hostingu do szybkiego podglądu plików, kopii zapasowych i logów,
• panelu WordPressa do sprawdzenia kont, wtyczek i motywu,
• phpMyAdmin lub innego narzędzia do podglądu bazy danych,
• SSH, jeśli chcesz uruchamiać skanery lub porównywać pliki z poziomu serwera,
• dostępu do logów serwera, które często pokazują ślady włamań, nietypowe żądania lub wywołania podejrzanych skryptów.

Przed skanowaniem warto też ograniczyć dalsze szkody. Zmień hasła do hostingu, FTP/SFTP i panelu WordPressa, jeśli podejrzewasz aktywną infekcję, a w razie potrzeby tymczasowo wyłącz formularze, integracje poczty lub funkcje publikujące treści automatycznie. Jeśli masz możliwość, włącz tryb konserwacji i poinformuj zespół, żeby nie instalował nowych wtyczek ani nie edytował plików do czasu zakończenia analizy.

Dobrym nawykiem jest zapisanie punktu odniesienia: spisu zainstalowanych wtyczek, aktywnego motywu, dat ostatnich aktualizacji i listy użytkowników z uprawnieniami administratora. Taki zestaw ułatwi później odróżnienie normalnych zmian od śladów infekcji i pomoże szybciej ocenić, czy coś pojawiło się nagle.

Im lepiej przygotujesz środowisko, tym łatwiej odróżnisz rzeczywisty problem od przypadkowych zmian. W praktyce bezpieczne skanowanie WordPressa zaczyna się nie od narzędzia, ale od kopii, dostępu i kontroli ryzyka.

Skanowanie plików WordPressa pod kątem malware

Skanowanie plików warto zacząć od dwóch perspektyw: manualnej i automatycznej. Sam skaner potrafi wychwycić wiele typowych infekcji, ale ręczna analiza pomaga zrozumieć, czy znaleziony problem to rzeczywisty malware, czy tylko nietypowy, lecz legalny fragment kodu.

Najpierw porównaj pliki rdzenia WordPressa z oryginałem. Jeżeli któreś pliki core zostały zmodyfikowane, a nie wykonywałeś aktualizacji, to jest to wyraźny sygnał ostrzegawczy. Szczególną uwagę zwróć na pliki, które zwykle nie powinny być zmieniane bez powodu, oraz na ostatnio modyfikowane pliki, bo to często najszybciej wskazuje miejsce infekcji.

W praktyce warto sprawdzić przede wszystkim te katalogi:

• wp-content/uploads — tam malware bywa ukrywany w plikach udających grafiki, archiwa lub skrypty,
• wp-content/mu-plugins — często pomijany, a daje duże możliwości uruchamiania kodu,
• wp-content/themes — zwłaszcza aktywny motyw i jego pliki funkcjonalne,
• wp-content/plugins — szczególnie wtyczki pobrane spoza oficjalnego źródła lub dawno nieaktualizowane.

Podczas przeglądu szukaj fragmentów kodu, które są typowe dla obfuskacji i ukrywania złośliwych działań. Do najczęstszych należą:

• base64 i jego dekodowanie w locie,
• gzinflate, str_rot13 i podobne funkcje maskujące,
• eval() oraz dynamiczne wykonywanie treści,
• ukryte include i require wskazujące na podejrzane ścieżki,
• bardzo długie, losowe ciągi znaków i nienaturalne nazwy plików.

Nie każdy dziwny fragment oznacza infekcję, ale połączenie kilku sygnałów zwykle jest już mocno podejrzane. Alarm powinny wzbudzać pliki z nieoczekiwanymi funkcjami, nadpisane nagłówki plików, treść wyglądająca na zaszyfrowaną lub skompresowaną oraz skrypty ukryte w miejscach, w których normalnie znajdują się wyłącznie obrazy czy statyczne zasoby.

Dobrym tropem są też pliki, których nikt nie powinien tam umieszczać: skrypty PHP w katalogu z uploadami, archiwa uruchamiane z poziomu strony, pliki z rozszerzeniami udającymi zwykłe zasoby albo elementy o nazwach podobnych do systemowych, lecz z jedną zmienioną literą. Malware często liczy na to, że ktoś przeoczy taki szczegół przy szybkim przeglądzie.

Do skanowania możesz użyć narzędzi po stronie serwera albo lokalnie, po pobraniu kopii plików. W praktyce dobrze sprawdzają się:

• skanery bezpieczeństwa dostępne w panelu hostingu lub wtyczkach ochronnych,
• narzędzia CLI uruchamiane przez SSH,
• lokalne porównanie plików z czystą kopią WordPressa, motywu lub wtyczki,
• proste przeszukiwanie treści pod kątem podejrzanych funkcji i charakterystycznych ciągów kodu.

Jeśli narzędzie wskazuje wiele plików naraz, nie zakładaj automatycznie, że cała strona jest zainfekowana. Czasem jedno zmienione źródło rozprzestrzenia alerty na powiązane pliki albo skaner oznacza legalny kod jako ryzykowny. Najlepiej wtedy przejść od ogólnego raportu do konkretnych plików i sprawdzić, czy zmiana ma sens z punktu widzenia działania motywu lub wtyczki.

Ważne jest także sprawdzenie plików pod kątem nietypowego czasu modyfikacji. Jeżeli plik zmienił się w godzinach, gdy nikt nie pracował na stronie, albo pojawił się po podejrzanym logowaniu, to taki ślad ma dużą wartość diagnostyczną. Porównanie dat, rozmiarów i zawartości pomaga często szybciej znaleźć źródło problemu niż samo skanowanie sygnaturami.

Jeżeli masz dostęp tylko do podstawowych narzędzi, zacznij od prostego przeglądu katalogów, sortowania plików po dacie i wyszukiwania fraz związanych z obfuskacją. Jeśli podejrzanych elementów jest więcej lub nie potrafisz ocenić ich znaczenia, potraktuj wynik jako powód do dalszej, ręcznej weryfikacji, a nie jako ostateczny wyrok.

Jak sprawdzić motyw i wtyczki

Gdy podstawowe skanowanie plików niczego nie rozstrzyga, kolejnym krokiem powinna być dokładna analiza aktywnego motywu oraz zainstalowanych wtyczek. To właśnie tam bardzo często trafia złośliwy kod, który potrafi działać tylko w określonych warunkach i przez długi czas pozostawać niewidoczny dla właściciela strony.

Najpierw sprawdź pliki, które w normalnej instalacji WordPressa mają duże znaczenie funkcjonalne, ale też często bywają modyfikowane przez atakujących. Szczególną uwagę zwróć na:

• functions.php w aktywnym motywie,
• header.php i footer.php,
• pliki odpowiedzialne za AJAX i własne endpointy,
• niestandardowe widgety, shortcody i klasy obsługujące integracje,
• pliki wtyczek, które dodają własne bramki, formularze, przekierowania lub zewnętrzne skrypty.

W tych miejscach nie każda zmiana oznacza infekcję. Normalne są modyfikacje związane z wyglądem, integracją z usługami zewnętrznymi, śledzeniem konwersji czy obsługą dodatkowych funkcji sklepu. Podejrzenia powinny jednak wzbudzać fragmenty kodu, które nie pasują do celu motywu lub wtyczki, pojawiają się bez dokumentacji zmian albo wyglądają jak wklejone „na szybko” i ukryte między legalnym kodem.

Alarmujące są zwłaszcza sytuacje, w których w plikach motywu lub wtyczek pojawiają się elementy typowe dla ukrywania działań, na przykład zewnętrzne odwołania do nieznanych domen, zaszyte przekierowania, wywołania funkcji uruchamianych warunkowo albo kod wstawiony w miejscach, gdzie normalnie powinien znajdować się prosty szablon HTML. Jeśli dodatkowo plik został zmieniony niedawno, bez udziału zespołu, ryzyko jest wyraźnie większe.

Bardzo ważne jest rozróżnienie między legalną personalizacją a kompromitacją. Dodanie własnego pola w panelu, hooka, skryptu analitycznego czy integracji z API może być całkowicie poprawne. Inaczej wygląda sytuacja, gdy w pliku nagle pojawia się trudny do odczytania, obfuskowany blok kodu, odwołanie do obcej domeny, treść ładowana dynamicznie z nieznanego źródła albo funkcje wykonujące kod z danych wejściowych użytkownika.

Szczególną ostrożność zachowaj przy motywach i wtyczkach pochodzących z niepewnego źródła. Piracki lub „nulled” motyw bardzo często bywa nośnikiem backdoora, ukrytego rekordu administratora, zewnętrznego skryptu albo mechanizmu komunikacji z serwerem atakującego. Taki kod potrafi wyglądać jak zwykła funkcjonalność premium, a w praktyce otwiera drogę do ponownej infekcji nawet po usunięciu widocznych objawów.

Dlatego warto weryfikować pochodzenie plików. Sprawdź, czy motyw lub wtyczka pochodzą z oficjalnego repozytorium, od zaufanego dostawcy albo z własnego, udokumentowanego wdrożenia. Jeśli masz dostęp do oryginalnych paczek, porównaj je z plikami na serwerze. Pomocne są także sumy kontrolne i porównanie wersji, bo pozwalają szybko wykryć nieautoryzowane zmiany w plikach, które oficjalnie nie powinny się różnić od wersji źródłowej.

W praktyce analizę najlepiej prowadzić etapami: najpierw sprawdź aktywny motyw, później najważniejsze wtyczki, a na końcu elementy mniej krytyczne. Jeżeli jakaś wtyczka nie jest używana, ale nadal znajduje się na serwerze, też nie ignoruj jej zawartości — nieaktywne pliki mogą służyć jako ukryte miejsce przechowywania złośliwego kodu. Im bliżej źródła funkcjonalności znajduje się podejrzany fragment, tym łatwiej ustalić, czy to błąd, eksperyment deweloperski, czy rzeczywista infekcja.

Jeśli widzisz zmiany w plikach motywu lub wtyczek, ale nie masz pewności co do ich znaczenia, porównaj je z kopią z backupu albo czystą wersją z zaufanego źródła. Taka weryfikacja zwykle szybko pokazuje, czy różnice są uzasadnione, czy też wskazują na kompromitację motywu lub wtyczki.

Skanowanie bazy danych i treści strony

Jeśli skan plików nie daje pełnego obrazu, kolejnym krokiem powinna być analiza bazy danych. To właśnie tam malware często ukrywa spamowe linki, ukryte iframe’y, przekierowania, złośliwe skrypty oraz zmiany, które nie są widoczne w samych plikach WordPressa. Warto sprawdzić nie tylko treść wpisów, ale też opcje motywu, dane użytkowników i pola niestandardowe.

Najważniejsze tabele do weryfikacji to zwykle:

• wp_posts — wpisy, strony, załączniki i treści generowane przez wtyczki,
• wp_options — ustawienia witryny, motywu i wtyczek, często z wpisami typu autoload,
• wp_users — konta użytkowników, zwłaszcza administratorów,
• wp_usermeta i metadane treści — dodatkowe uprawnienia, ukryte ustawienia oraz dane powiązane z wpisami.

Podczas przeszukiwania bazy zwracaj uwagę na treści, które wyglądają nienaturalnie lub nie pasują do charakteru strony. Podejrzane są między innymi:

• ukryte iframe’y i elementy osadzające z obcych domen,
• spamowe linki w treści wpisów i stron,
• fragmenty JavaScriptu wstawione do opisów, widgetów lub opcji motywu,
• dziwne wpisy w autoload, które ładują się przy każdym żądaniu strony,
• nieznane rekordy administratorów lub zmienione role użytkowników,
• podmienione adresy URL witryny i przekierowania zapisane w opcjach.

Szczególnie ważna jest analiza tabeli wp_options, bo tam często trafiają ustawienia używane przez motyw lub wtyczki. Jeśli pojawił się tam długi, zaszyfrowany albo obfuskowany ciąg znaków, może to oznaczać próbę ukrycia kodu lub konfiguracji zewnętrznego skryptu. Warto też sprawdzić wpisy odpowiadające za treści ładowane automatycznie, integracje z usługami zewnętrznymi i ustawienia przekierowań.

W tabeli wp_posts zaglądaj nie tylko do publikowanych artykułów, ale również do szkiców, załączników i treści tworzonych przez page buildery. Malware często wstrzykuje kod w miejsca, których użytkownik nie sprawdza na co dzień, na przykład w treść widżetów, bloki HTML lub dodatkowe sekcje edytora. Jeśli w treści widzisz obce domeny, ukryte skrypty albo dziwne znaczniki, porównaj te rekordy z wersją sprzed infekcji, jeśli masz backup.

W tabelach użytkowników szukaj kont, których nikt nie zakładał, oraz zmian w rolach i uprawnieniach. Nawet jedno nieznane konto administratora może oznaczać, że atakujący nadal ma dostęp do panelu. Sprawdź też, czy nazwy użytkowników, adresy e-mail i daty utworzenia mają sens w kontekście historii serwisu.

Przeszukiwanie bazy warto prowadzić pod kątem charakterystycznych fraz i wzorców kodu. Pomocne są zapytania lub wyszukiwania po ciągach takich jak: base64, eval, iframe, script, gzinflate, document.write, a także po nazwach obcych domen, które widzisz w raportach skanera lub w logach. Szukaj nie tylko gotowych funkcji, ale też fragmentów wyglądających na zaszyfrowane, skompresowane albo wklejone masowo w wiele rekordów.

Jeśli baza danych zawiera dużo treści, nie zakładaj od razu, że każdy nietypowy wpis oznacza infekcję. Czasem część danych pochodzi z legalnych wtyczek, które zapisują własne skrypty, znaczniki śledzące lub konfigurację. Kluczowe jest więc porównanie podejrzanego wpisu z tym, co rzeczywiście powinno się znajdować w danej tabeli i w danym polu.

Dobrym podejściem jest połączenie przeszukiwania SQL z analizą panelu WordPressa. Jeśli baza pokazuje dziwne rekordy, a w panelu pojawiają się nieznane treści, przekierowania lub nowe konta, masz już mocny sygnał, że infekcja nie ogranicza się do jednego miejsca. W takiej sytuacji warto traktować wyniki jako realne zagrożenie, a nie tylko podejrzany trop.

Interpretacja wyników skanera i fałszywe alarmy

Raport skanera bezpieczeństwa to wskazówka, a nie zawsze ostateczny wyrok. Narzędzia automatyczne często łączą wykrywanie sygnatur, analizę heurystyczną i porównanie plików z bazą wzorców, dlatego ten sam alert może oznaczać zarówno realne malware, jak i legalny kod, który po prostu wygląda podejrzanie.

Najpierw sprawdź, co dokładnie zostało oznaczone. Inaczej należy traktować komunikat o zmodyfikowanych plikach core WordPressa, inaczej alert o backdoorze, a jeszcze inaczej ostrzeżenie dotyczące katalogu uploads czy podejrzanej funkcji PHP. Zmiana w pliku rdzenia bez planowanej aktualizacji jest zwykle bardziej alarmująca niż pojedyncze ostrzeżenie heurystyczne wtyczki, która nie rozumie kontekstu wdrożenia.

W praktyce warto rozróżnić kilka typowych kategorii wyników:

• zmodyfikowane pliki — wymagają porównania z czystą wersją i sprawdzenia, czy zmiana była oczekiwana,
• backdoor — zwykle bardzo poważny sygnał, bo oznacza potencjalny stały dostęp dla atakującego,
• phishing — może wskazywać na podmienione treści, formularze lub przekierowania do obcych domen,
• malware w uploads — często oznacza skrypty ukryte w miejscu przeznaczonym na media,
• podejrzane funkcje PHP — wymagają sprawdzenia, czy są użyte legalnie, czy służą do obfuskacji i uruchamiania złośliwego kodu.

Dużo zależy od tego, czy alert wynika z reguł heurystycznych, czy z jednoznacznego dopasowania do znanego wzorca infekcji. Heurystyka potrafi uznać za groźne coś, co tylko przypomina malware, na przykład fragment z base64, dynamicznym include albo kodem analitycznym wtyczki. Z kolei dopasowanie sygnatury do znanego backdoora jest zwykle znacznie bardziej wiarygodne i wymaga natychmiastowej reakcji.

Jeśli skaner pokazuje jeden podejrzany plik, nie zakładaj od razu, że to dowód infekcji. Najlepiej porównać go z czystą kopią, sprawdzić datę modyfikacji, lokalizację, kontekst użycia i to, czy plik rzeczywiście należy do danej wtyczki lub motywu. Wiele fałszywych alarmów bierze się z tego, że narzędzie nie wie, iż dana funkcja została dodana celowo przez dewelopera lub pochodzi z niestandardowej integracji.

Ostrożność jest szczególnie ważna, gdy skaner zgłasza wiele alertów naraz. Czasem jedna zmiana powoduje lawinę ostrzeżeń w powiązanych plikach, a czasem jedno legalne rozwiązanie generuje komunikaty o ryzyku, bo korzysta z mechanizmów podobnych do tych, których używa malware. W takiej sytuacji warto przejść od ogólnego raportu do konkretów: który plik, która linia, jaka funkcja, jaki powód oznaczenia.

Na etapie interpretacji pomocne są pytania kontrolne:

• Czy ten plik powinien istnieć w tym miejscu?
• Czy modyfikacja pasuje do historii zmian strony?
• Czy kod odwołuje się do znanej, zaufanej funkcjonalności?
• Czy w treści lub w nagłówkach widać obce domeny, przekierowania albo ukryte skrypty?
• Czy wynik pojawił się tylko w jednym skanerze, czy w kilku niezależnych narzędziach?

Jeżeli odpowiedzi są niejednoznaczne, wykonaj ręczną weryfikację. Porównaj plik z backupem, sprawdź bazę danych, przejrzyj logi i zobacz, czy podobne wzorce pojawiają się w innych miejscach. Ręczna analiza jest szczególnie potrzebna wtedy, gdy alert dotyczy pliku aktywnego motywu, nietypowego wpisu w bazie albo elementu, który mógł zostać dodany przez legalną wtyczkę.

Jeśli jednak skaner zgłasza znany backdoor, obfuskowany kod, złośliwe przekierowanie albo infekcję w miejscu, gdzie nie powinno być żadnego PHP, traktuj to jako wiarygodny sygnał do działania. W takim przypadku nie ma sensu czekać na kolejne potwierdzenia, tylko od razu ograniczyć ryzyko i przejść do procedury czyszczenia.

Dobra zasada brzmi: im bardziej alert jest konkretny, powtarzalny i zgodny z innymi śladami, tym mniej czasu powinno się poświęcać na dyskusję, a więcej na zabezpieczenie strony. Im bardziej ogólny i heurystyczny, tym większa szansa, że trzeba go sprawdzić ręcznie, zanim uznasz go za prawdziwe zagrożenie.

Co zrobić po wykryciu złośliwego kodu

Gdy skan potwierdzi obecność malware lub silnie podejrzanego kodu, najważniejsze jest szybkie ograniczenie zasięgu szkód. Jeśli to możliwe, odizoluj stronę: włącz tryb konserwacji, zablokuj publiczny dostęp do panelu administracyjnego na czas prac i wstrzymaj instalowanie nowych wtyczek oraz edycję plików. Im krócej zainfekowana witryna działa bez kontroli, tym mniejsze ryzyko dalszego rozprzestrzeniania infekcji i wycieku danych.

Następnie zmień wszystkie kluczowe hasła i tokeny dostępu. Dotyczy to panelu hostingu, FTP/SFTP, kont administratorów WordPressa, bazy danych oraz ewentualnych integracji API. Warto też odświeżyć klucze bezpieczeństwa WordPress, aby unieważnić aktywne sesje i utrudnić atakującemu dalszy dostęp, nawet jeśli wcześniej zdobył cookies lub inne dane uwierzytelniające.

Kolejny krok to przywrócenie czystych plików z zaufanego źródła. Najbezpieczniej podmienić rdzeń WordPressa na świeżą, oficjalną wersję, a następnie odtworzyć motyw i wtyczki z backupu albo z oryginalnych paczek pobranych z pewnego źródła. Jeśli backup powstał przed infekcją, sprawdź go pod kątem integralności, zanim użyjesz go do odtworzenia strony. Nie zakładaj automatycznie, że każda kopia jest czysta — jeśli była wykonana po włamaniu, mogła zawierać już złośliwy kod.

W praktyce warto postępować w takiej kolejności:

• usunąć lub odizolować wskazane pliki z malware,
• podmienić rdzeń WordPressa na czystą wersję,
• zaktualizować wszystkie wtyczki i motyw,
• usunąć nieznane konta administratorów i podejrzane wpisy w bazie,
• wymusić wylogowanie wszystkich sesji,
• uruchomić ponowny skan plików, bazy i motywu.

Nie zapomnij o użytkownikach i rolach w panelu. Usunięcie zainfekowanych kont, cofnięcie nieautoryzowanych uprawnień i sprawdzenie ostatnich logowań jest równie ważne jak czyszczenie plików. Często to właśnie przejęte konto administratora było punktem wejścia albo pozwalało atakującemu wracać po każdej próbie naprawy.

Po wykonaniu podstawowych działań koniecznie przeprowadź ponowne skanowanie. Sprawdź nie tylko te same pliki, które wcześniej wzbudziły alarm, ale też powiązane katalogi, bazę danych, wpisy autoload i logi serwera. Jeżeli raport nadal pokazuje podobne sygnały, infekcja mogła zostać usunięta tylko częściowo albo istnieje drugi wektor ataku, którego jeszcze nie wykryłeś.

Po naprawie przez kilka dni obserwuj stronę. Monitoruj logi, zmiany w plikach, nowe konta, alerty skanera i nietypowe zachowanie formularzy czy przekierowań. To pozwoli szybko zauważyć, czy problem wraca, a wtedy łatwiej będzie ustalić, czy przyczyną był pozostawiony backdoor, luka w dodatku, czy niezamknięty dostęp administracyjny.

Równie ważne jest ustalenie, jak doszło do infekcji. Sprawdź, czy winne były nieaktualne wtyczki, piracki motyw, słabe hasło, podatność na serwerze, brak ograniczeń dostępu czy niezabezpieczony formularz. Bez znalezienia źródła problemu możesz wyczyścić stronę tylko chwilowo, a atakujący wróci tą samą drogą.

Jeśli nie masz pewności, że samodzielnie usunąłeś wszystkie ślady, lepiej skorzystać z pomocy specjalisty. Przy większym naruszeniu bezpieczeństwa najważniejsze jest nie tylko usunięcie widocznego kodu, ale też przywrócenie zaufania do całego środowiska, łącznie z kopiami zapasowymi, kontami i konfiguracją serwera.

FAQ

Czy da się sprawdzić WordPressa bez wiedzy technicznej?

Tak, podstawowy skan można wykonać narzędziami w panelu wtyczki bezpieczeństwa lub hostingu, ale ręczna analiza plików i bazy danych zwykle wymaga większej wiedzy.

Czy sam skaner antywirusowy wystarczy, żeby wykryć malware?

Nie zawsze. Skaner może wykryć wiele zagrożeń, ale część infekcji jest ukryta lub wygląda jak legalny kod. Warto łączyć skan automatyczny z ręczną weryfikacją.

Gdzie w WordPressie najczęściej ukrywa się złośliwy kod?

Najczęściej w plikach motywu, wtyczek, katalogu uploads, plikach core po modyfikacji oraz w bazie danych, zwłaszcza w treści wpisów i opcjach.

Czy można usunąć malware bez przywracania kopii zapasowej?

Czasem tak, jeśli infekcja jest niewielka i dobrze zlokalizowana. Przy większym naruszeniu bezpieczniej jest odtworzyć czystą kopię i dopiero potem zaktualizować oraz przeskanować stronę.

Jeśli podejrzewasz infekcję, zacznij od kopii zapasowej i szybkiego skanu plików, a potem przejdź do bazy danych i motywu, żeby zlokalizować źródło problemu.