Zhakowana strona na Joomla: co robić

Latem 2026 roku przez witryny oparte na Joomla przetoczyła się fala masowych, automatycznych włamań. Ataki nie są prowadzone ręcznie ani wymierzone w konkretne ofiary: boty przeczesują internet, znajdują podatne rozszerzenie i w kilka sekund wgrywają web shell. Jeśli Twoja strona nagle zaczęła przekierowywać odwiedzających na obce witryny, rozsyłać spam albo wyświetlać napis „Hacked by...”, poniżej wyjaśniam krok po kroku, co zrobić już teraz i jak odzyskać kontrolę.

Jak rozpoznać, że strona rzeczywiście została zhakowana

Czasem włamanie widać od razu: zamiast strony głównej pojawia się obcy napis. Częściej jednak działa po cichu przez całe tygodnie, a Ty dowiadujesz się o nim ostatni. Oto oznaki, po których infekcja się zdradza:

• Strona przekierowuje odwiedzających na obce witryny (kasyna, apteki, podejrzane pliki do pobrania), zwłaszcza przy wejściu z wyszukiwarki lub z telefonu.
• W wynikach wyszukiwania pod Twoją stroną pojawiły się obce podstrony albo krzaki, a Google pokazuje „Ta strona mogła zostać zhakowana”.
• W panelu administracyjnym pojawili się użytkownicy z uprawnieniami Super User, których nie tworzyłeś.
• Hosting przysłał powiadomienie o złośliwym kodzie lub nietypowym obciążeniu, czasem z zawieszeniem konta.
• Serwer rozsyła spam bez Twojej wiedzy, a IP poczty trafiło na czarne listy RBL.
• W folderach media, images, tmp pojawiły się nieznane pliki PHP, pliki z podwójnym rozszerzeniem (.xml.php) albo dziwną wielkością liter (.pHp).
• Ruch organiczny gwałtownie spadł: podstrony wypadły z indeksu albo zostały oznaczone jako niebezpieczne.

Nawet jeden punkt z tej listy to powód do pełnego sprawdzenia. Włamanie często działa wybiórczo: zwykłemu odwiedzającemu strona wydaje się normalna, a przekierowanie uruchamia się tylko dla tych, którzy weszli z Google, albo tylko raz z jednego urządzenia. Dlatego „u mnie wszystko się otwiera” jeszcze nie znaczy „wszystko jest czyste”.

Dlaczego latem 2026 masowo włamują się do stron Joomla

Przyczyna prawie nigdy nie leży w samym rdzeniu Joomla, który akurat jest całkiem nieźle zabezpieczony, lecz w popularnych rozszerzeniach firm trzecich. W krótkim czasie ujawniono naraz kilka krytycznych podatności (CVSS do 10.0), które umożliwiają nieuwierzytelnione wgranie i wykonanie kodu PHP. Czyli pełne przejęcie strony bez żadnego hasła:

• JCE (Joomla Content Editor): CVE-2026-48907, załatane w wersji 2.9.99.5.
• SP Page Builder: CVE-2026-48908, załatane w 6.6.2.
• iCagenda: CVE-2026-48939, załatane w 4.0.8 oraz 3.9.15.
• Page Builder CK: CVE-2026-56290, załatane w 3.6.0.

Część z nich wykorzystywano jako 0-day, jeszcze przed wydaniem łatki, a wszystkie trafiły do katalogu aktywnie wykorzystywanych podatności CISA (KEV). Exploity są publiczne, a ataki prowadzą boty w całym internecie. Dlatego argument „mam małą stronę, komu ona potrzebna” nie działa: botom jest obojętny Twój ruch, uderzają według kryterium „zainstalowane podatne rozszerzenie”.

Skalę potwierdzają także narodowe centra cyberbezpieczeństwa. 9 lipca 2026 roku Australijskie Centrum Cyberbezpieczeństwa (ACSC) ostrzegło o dużej, trwającej globalnej kampanii: napastnicy masowo skanują strony oparte na CMS i instalują web shelle, a Joomla JCE zostało wprost wymienione na liście podatnego oprogramowania. ACSC zaznacza, że kampanię prawdopodobnie przyspiesza AI, skracając czas od ujawnienia podatności do ataku do zaledwie kilku godzin.

Osobną wyraźną falą są defacementy strony głównej z podpisem „Hacked by AntonKill”. Branżowe źródła poświęcone Joomla wiążą ją przede wszystkim z podatnością frameworka szablonów Helix3 od JoomShaper (CVE-2026-49049): złośliwy kod jest wstrzykiwany bezpośrednio w parametry szablonu w bazie danych, dlatego samo czyszczenie plików bywa niewystarczające.

Pierwsza godzina: co zrobić od razu

Zadaniem pierwszej godziny nie jest „wyleczyć”, lecz zatrzymać szkody i zachować możliwość spokojnego zajęcia się sprawą. Po kolei:

1. Zmień hasła. Administrator Joomla, dostępy do hostingu i panelu, FTP/SFTP oraz baza danych. Jeśli jedno hasło było używane w kilku miejscach, zmień je wszędzie.
2. Odetnij stronę od odwiedzających. Przełącz ją w tryb konserwacji (offline w Joomla) albo tymczasowo wyświetlaj stronę zastępczą. To ochroni odwiedzających przed przekierowaniami i szkodliwym kodem oraz zatrzyma rozsyłanie spamu.
3. Zachowaj ślady. Pobierz najświeższe logi serwera (access i error) i zrób pełne archiwum strony oraz zrzut bazy „tak jak jest”, przed czyszczeniem. Po logach ustala się zarówno czas, jak i sposób włamania.
4. Sprawdź administratorów. Zablokuj lub usuń konta z uprawnieniami Super User, których nie tworzyłeś. Przy okazji zobacz, czy nie podmieniono adresu e-mail przy Twoim własnym koncie.
5. Uprzedź hosting. Wielu hostingodawców pomaga we wstępnej diagnostyce, udostępnia własne skanery i, co ważne, nie blokuje konta, jeśli widzi, że już zajmujesz się problemem.
6. Znajdź ostatnią czystą kopię zapasową. Sprawdź, czy istnieje kopia z okresu sprzed infekcji. Od tego zależy, którą drogą pójdzie przywracanie.

Jak poprawnie wyczyścić stronę

Główny błąd brzmi tak: „znalazłem jeden dziwny plik, usunąłem, uspokoiłem się”. Web shell prawie nigdy nie jest sam: obok leżą kopie zapasowe furtki, a w bazie i w legalnych plikach siedzą wstawki, które odtwarzają dostęp. Czyszczenie to cały proces, a nie pojedyncza czynność.

1. Znaleźć i usunąć web shelle

Szukaj świeżych i podejrzanych plików PHP tam, gdzie ich być nie powinno: w images, media, tmp, cache. Oznaki: podwójne rozszerzenie (.xml.php), nietypowa wielkość liter (.pHp), niedawna data modyfikacji, a także PHP z funkcjami eval, base64_decode, gzinflate, assert oraz preg_replace z modyfikatorem /e. Takie wstawki są prawie zawsze złośliwe.

2. Porównać pliki z czystą kopią

Najpewniej jest porównać pliki strony ze wzorcem: pobierz czystą Joomla w swojej wersji oraz te same rozszerzenia z oficjalnych źródeł i porównaj. Wszystko, co różni się w rdzeniu i w plikach rozszerzeń, jest kandydatem do wymiany. Własne zmiany (szablon, konfigurację) trzymaj przy tym osobno.

3. Wyczyścić bazę danych

Sprawdź bazę pod kątem wstrzyknięć: w parametrach szablonów (zwłaszcza Helix3), w artykułach, w modułach i w pluginach systemowych. Szukaj tagów script i iframe, wstawek z document.write oraz odwołań do zewnętrznych domen. Przy okazji sprawdź tabelę użytkowników i tabelę rozszerzeń: to tam ukrywa się zarówno ukrytych administratorów, jak i złośliwe pluginy, które na nowo tworzą shelle.

4. Sprawdzić punkty zaczepienia

Zajrzyj do .htaccess (reguły przekierowań i dołączanie PHP), do zaplanowanych zadań (cron) oraz do pluginów systemowych Joomla, które uruchamiają się przy każdym wczytaniu. To właśnie tutaj najczęściej zostawia się „drugi klucz”, żeby wrócić po czyszczeniu.

Przywracanie z kopii zapasowej: kiedy to działa

Kopia zapasowa to najszybsza droga, ale tylko przy dwóch warunkach: kopia została zrobiona na pewno przed infekcją i dokładnie wiesz, przez co się dostano. Jeśli przywrócisz stronę i nie zaktualizujesz podatnego rozszerzenia, ponowna infekcja to kwestia godzin.

Trudność polega na tym, że włamanie często zauważa się dopiero po tygodniach, a wszystkie świeże kopie zapasowe zawierają już shell. Wtedy czysta kopia istnieje, ale jest zbyt stara: od tamtej pory pojawiły się nowe artykuły, zamówienia, ustawienia. W takim przypadku najlepiej połączyć podejścia: wdrożyć starą czystą kopię jako podstawę, ostrożnie przenieść na nią świeżą treść z bazy (uprzednio ją sprawdzając) i koniecznie zaktualizować wszystko, przez co mogło dojść do włamania.

I osobno o przyszłości: kopia zapasowa jest przydatna dokładnie na tyle, na ile istnieje i jest sprawdzona. Kopie zapasowe powinny powstawać automatycznie, być przechowywane osobno od strony (żeby ransomware ani defacement ich nie dosięgły) i przynajmniej czasem być wdrażane na środowisku testowym, aby upewnić się, że są sprawne.

Jak załatać lukę, żeby się nie powtórzyło

Wyczyszczenie strony to połowa pracy. Jeśli nie usuniesz przyczyny, wszystko się powtórzy. Podstawowy zestaw zabezpieczeń:

• Aktualizuj Joomla i wszystkie rozszerzenia na bieżąco. Większość włamań z 2026 roku to nie „wyrafinowany atak”, lecz wejście przez rozszerzenie, dla którego łatka już wyszła. Usuń to, czego nie używasz: każde zbędne rozszerzenie to kolejne drzwi.
• Włącz uwierzytelnianie dwuskładnikowe dla kont administracyjnych i usuń oczywiste loginy w rodzaju admin.
• Ustaw poprawnie uprawnienia do plików i folderów (zwykle 644 dla plików, 755 dla folderów) i zablokuj wykonywanie PHP w folderach na przesyłane pliki (media, images), gdzie nie powinno go być.
• Postaw stronę za Cloudflare lub innym WAF: odcina on część automatycznych ataków i skanerów jeszcze zanim dotrą do Joomla.
• Rób automatyczne kopie zapasowe przechowywane osobno od strony i sprawdzaj je.
• Usuń z serwera ślady prac deweloperskich: stare kopie, testowe skrypty, zapomniane phpMyAdmin i archiwa. To właśnie one często stają się wejściem.

Kiedy warto wezwać specjalistę

Wiele z wymienionych rzeczy da się realnie zrobić samodzielnie, zwłaszcza jeśli włamanie zauważono wcześnie i istnieje świeża czysta kopia zapasowa. Są jednak sytuacje, w których zwłoka i półśrodki kosztują więcej niż pomoc:

• Szkodliwy kod wraca po każdym czyszczeniu: to znaczy, że przeoczono furtkę albo nie załatano pierwotnej luki.
• Nie ma czystej kopii zapasowej, a na stronie jest żywa treść i zamówienia, których nie można stracić.
• Hosting zablokował konto albo strona została oznaczona w Google jako „niebezpieczna” i trzeba szybko przejść ponowną weryfikację.
• Defacement siedzi w bazie (ten sam Helix3 i „AntonKill”), gdzie czyszczenie plików nie wystarcza.
• Strona jest komercyjna, a każdy dzień przestoju to utracone zgłoszenia i pozycje.

Jeśli to Twój przypadek, przywracam strony na Joomla po włamaniu kompleksowo: znajduję i usuwam shelle oraz przekierowania, czyszczę bazę, łatam podatność, przywracam widoczność w wyszukiwarce i konfiguruję zabezpieczenia, żeby się nie powtórzyło. Więcej o usłudze i cenach na stronie przywracanie strony po włamaniu. Diagnostykę robię bezpłatnie, jeszcze przed rozpoczęciem prac.