Usuwanie wirusów WordPress: malware, przekierowania i naprawa po włamaniu

Objawy wirusa w WordPress

Wirus WordPress nie zawsze wyłącza stronę. Często pokazuje się tylko klientom z telefonu, po wejściu z Google albo generuje spamowe adresy poza normalną nawigacją.

Oznaki, że strona została zhakowana

Szybka lista kontrolna. Sprawdź sam: im więcej trafień, tym większe prawdopodobieństwo infekcji.

• Strona przekierowuje odwiedzających na obce strony (kasyno, zakłady, farmacja, treści dla dorosłych), często tylko z urządzeń mobilnych albo tylko przy przejściu z wyszukiwarki.
• W wynikach pod Twoją domeną pojawiły się obce strony ze spamowymi frazami (podróbki marek, leki), nierzadko z hieroglifami (japoński keyword hack) w folderach o losowych nazwach.
• Google oznacza stronę jako „This site may be hacked”, a w przeglądarce pojawia się czerwone ostrzeżenie „Deceptive site ahead” albo o złośliwym kodzie.
• W Google Search Console przyszło powiadomienie, że stronę potwierdził jako właściciel nieznany człowiek, albo w raporcie „Problemy związane z bezpieczeństwem” pojawiły się zhakowane strony.
• Strona główna została podmieniona komunikatem włamywacza albo obcymi banerami (defacement, na przykład „Hacked by AntonKill”).
• Na liście użytkowników Joomla pojawili się super administratorzy, których nie tworzyłeś (wiarygodne nazwy, adresy na nieistniejącej domenie).
• Gwałtownie spadł ruch organiczny z powodu deindeksacji albo blokady, odwiedzalność runęła bez widocznej przyczyny.
• Serwer wysyła spam bez Twojej wiedzy: wychodzące wiadomości wracają, a IP poczty trafia na czarne listy RBL/DNSBL.
• Hosting przysłał wiadomość o złośliwym kodzie albo nadmiernym obciążeniu, czasem z zawieszeniem konta.
• W folderach media, images, tmp pojawiły się nieznane pliki PHP, pliki z podwójnym rozszerzeniem (.xml.php) albo dziwną wielkością liter (.pHp).

Skąd biorą się wirusy w WordPress i Joomla

W WordPress najczęstszą drogą wejścia jest podatna lub porzucona wtyczka, stary motyw, skradzione hasło administratora albo zainfekowany komputer. Problem może wracać z katalogu uploads, zadania cron, obcego konta, bazy danych albo drugiej witryny na tym samym hostingu. Dlatego samo zastąpienie rdzenia WordPress nie jest pełnym czyszczeniem.

Lato 2026 roku stało się dla Joomla czasem masowych zautomatyzowanych ataków, a przyczyna leży głównie nie w rdzeniu, lecz w popularnych rozszerzeniach. Jedna po drugiej ujawniano krytyczne podatności (CVSS do 10.0), które pozwalają na nieuwierzytelnione przesłanie i wykonanie kodu PHP, czyli pełne przejęcie strony bez hasła: JCE / Joomla Content Editor (CVE-2026-48907, poprawka w 2.9.99.5), SP Page Builder (CVE-2026-48908, poprawka w 6.6.2), iCagenda (CVE-2026-48939, poprawka w 4.0.8 i 3.9.15) oraz Page Builder CK (CVE-2026-56290, poprawka w 3.6.0). Część była wykorzystywana jako 0-day, jeszcze przed wydaniem poprawki, i wszystkie zostały wpisane przez CISA do katalogu aktywnie wykorzystywanych podatności (KEV). Exploity są publiczne, ataki prowadzą boty w całym internecie, dlatego zamknięta rejestracja i niewielki ruch nie chronią przed infekcją.

Skala widoczna jest też na poziomie narodowych zespołów CERT. 9 lipca 2026 roku Australijskie Centrum Cyberbezpieczeństwa (ACSC) ostrzegło o dużej, trwającej globalnej kampanii: napastnicy masowo skanują strony na CMS i instalują web shelle, a na liście podatnego oprogramowania wprost wymieniono Joomla JCE. ACSC dopuszcza, że kampania przyspiesza dzięki SI, która skraca czas od ujawnienia podatności do ataku. Równolegle trwa fala defacementów strony głównej z podpisem „Hacked by AntonKill”: branżowe źródła dotyczące Joomla wiążą ją przede wszystkim z osobną podatnością frameworka szablonów Helix3 od JoomShaper (CVE-2026-49049), przez którą złośliwy kod jest wstrzykiwany wprost do parametrów szablonu w bazie. Szacunki liczby zainfekowanych stron są na razie przybliżone: na przykład serwis mySites.guru obserwował setki witryn, ale to ocena jednego źródła, a nie zweryfikowany wynik.

Przy tym większość realnych włamań na Joomla nadal następuje nie przez świeże 0-day, lecz z nudnych przyczyn: przestarzały rdzeń i rozszerzenia, słabe lub wielokrotnie używane hasła administratora (uwierzytelnianie dwuskładnikowe w Joomla istnieje, ale domyślnie jest wyłączone), pirackie (nulled) szablony i komponenty z już wszytym backdoorem, a także wyciekłe dostępy do hostingu, FTP i bazy. Według szacunków Sucuri większość włamań na CMS przypada właśnie na podatne rozszerzenia zewnętrzne, a nie na sam rdzeń. Osobno warto pamiętać o starej, ale wciąż aktywnie skanowanej luce rdzenia Joomla 4.x CVE-2023-23752: wyciek loginu i hasła bazy przez API, załatanej jeszcze w 4.2.8.

Kluczowy moment, który często się bagatelizuje: instalacja aktualizacji zamyka wejście, ale NIE usuwa tego, co napastnik już zostawił. Web shelle, fałszywi super administratorzy, złośliwe wpisy w .htaccess i zadania w cron działają dalej także po poprawce. Dlatego strona, która w czerwcu, lipcu 2026 choćby przez chwilę używała podatnej wersji rozszerzenia, wymaga nie zwykłej aktualizacji, lecz pełnego czyszczenia i sprawdzenia pod kątem utrwalenia dostępu: według obserwacji Google zauważalna część zhakowanych stron zostaje ponownie zainfekowana już w ciągu doby, jeśli nie zamknie się pierwotnej luki.

Rozszerzenia dotknięte w 2026 (sprawdź i zaktualizuj): JCE do 2.9.99.5+, SP Page Builder do 6.6.2+, iCagenda do 4.0.8 / 3.9.15+, Page Builder CK do 3.6.0+, Helix3 (JoomShaper) wg CVE-2026-49049. Dane wg NVD i katalogu CISA KEV. Aktualizacja jest obowiązkowa, ale sama nie wystarczy: stronę trzeba jeszcze sprawdzić pod kątem już zainstalowanych web shelli i backdoorów.

Jak przebiega usuwanie wirusów WordPress

Przejrzysty porządek prac. Nie po prostu „wyczyściłem i poszedłem”: ważne, by usunąć nie tylko objawy, lecz i przyczynę, inaczej stronę zainfekują ponownie przez tę samą lukę.

Co otrzymujesz

Rezultat to nie zwykłe „strona się otworzyła”, lecz czysta, zaktualizowana i zabezpieczona strona plus zrozumienie, co się wydarzyło.

Formaty prac i terminy

Dobieram format do sytuacji: od pilnego przywrócenia strony do działania po pełne odtworzenie z ochroną i monitoringiem.

Ochrona po leczeniu

Wyleczyć to za mało: ważne, by zamknąć wejście i zmniejszyć ryzyko powtórki. Oto co konfiguruję w ramach pełnego odtworzenia.

• Włączam uwierzytelnianie dwuskładnikowe (2FA) dla wszystkich super administratorów: w Joomla domyślnie jest wyłączone.
• Ograniczam dostęp do folderu /administrator po IP albo hasłem na poziomie serwera WWW.
• Wyłączam wykonywanie PHP w folderach przesyłania (media, images, tmp), żeby przesłany plik nie stał się działającym shellem.
• Ustawiam silne, unikalne hasła dla administratorów, bazy, FTP/SSH i hostingu, likwiduję wielokrotne używanie.
• Zamykam nieuwierzytelniony dostęp do endpointu API konfiguracji na poziomie serwera albo Cloudflare.
• Usuwam nieużywane i nieznane rozszerzenia oraz szablony, zostawiam tylko potrzebne i aktualizuję z oficjalnych kanałów.
• Rezygnuję z pirackich (nulled) szablonów i komponentów, instaluję tylko ze zweryfikowanych źródeł.
• Konfiguruję regularne kopie zapasowe poza serwerem z testem odtwarzania oraz, w razie potrzeby, WAF przed stroną.

Powiązane usługi

Włamanie to często skutek przestarzałej strony. Czasem taniej i pewniej nie łatać starego, lecz zbudować od nowa na czystej podstawie.