Obca reklama i przekierowania
Strona otwiera się z obcymi banerami albo przerzuca odwiedzających do kasyna, apteki czy podejrzanych stron, zwłaszcza z telefonów i z wyszukiwarki.
Joomla · Pomoc awaryjna · Bezpieczeństwo
Przywracanie strony po włamaniu: wyczyszczę backdoory i zamknę lukę, przez którą weszli
Jestem Artem, specjalizuję się w Joomla. Jeśli strona przekierowuje odwiedzających do kasyna, w wynikach wyszukiwania pojawiły się obce strony, a hosting przysłał wiadomość o złośliwym kodzie, znajdę i usunę web shelle, wyczyszczę wstrzyknięcia z plików i bazy, usunę fałszywych administratorów i zamknę punkt wejścia, żeby włamanie nie wróciło po dniu. Zawsze zaczynam od diagnostyki.
Strona leży albo jest zainfekowana właśnie teraz? Pilne przypadki biorę do pracy w pierwszej kolejności.
Napisz terazZnajoma sytuacja?
Tak wygląda włamanie z perspektywy właściciela strony. Jeśli rozpoznajesz choćby jeden punkt, strona najprawdopodobniej jest zainfekowana i trzeba działać szybko, zanim urosną straty ruchu i reputacji.
Spam w wynikach wyszukiwania
W Google i Yandex zamiast Twoich stron pojawiły się obce: hieroglify, towary, tabletki. To klasyczny spam wyszukiwarkowy wstrzyknięty przez włamanie.
Oznaczenie „strona zhakowana”
Wyszukiwarka lub przeglądarka pokazuje ostrzeżenie „Ta strona mogła zostać zhakowana” albo blokuje przejście. Odwiedzający odchodzą, nie otwierając strony.
Blokada przez hosting
Hosting zawiesił konto za rozsyłanie spamu albo znaleziony złośliwy kod. Strona i poczta nie działają, dopóki infekcja nie zostanie usunięta.
Obcy administratorzy
W panelu pojawili się nieznani super użytkownicy, włączyła się rejestracja, hasła przestały pasować.
Podmiana strony głównej (defacement)
Zamiast strony: strona włamywacza albo obce banery. Latem 2026 masowo krąży defacement z podpisem „Hacked by AntonKill”.
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).
Dlaczego teraz masowo łamią Joomla
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.
Podatności rozszerzeń: główna przyczyna 2026
Krytyczne luki (CVSS do 10.0) z nieuwierzytelnionym przesłaniem PHP w JCE, SP Page Builder, iCagenda i Page Builder CK. Exploity publiczne, ataki prowadzą boty.
Przestarzały rdzeń i komponenty
Według oceny Sucuri większość włamań na CMS przypada na nieaktualizowane dodatki zewnętrzne. Do tego wciąż skanowana stara luka rdzenia Joomla 4.x CVE-2023-23752.
Słabe i wyciekłe dostępy
Proste albo wielokrotnie używane hasła, brak 2FA, wyciekłe dostępy do hostingu, FTP i bazy. Klasyczny wektor, któremu nie jest potrzebny żaden 0-day.
Pirackie szablony i rozszerzenia
Nulled wersje premiumowych szablonów i komponentów z niezweryfikowanych źródeł często mają już wbudowany backdoor, który uaktywnia się od razu po instalacji.
Automatyzacja i masowość
ACSC 9 lipca 2026 ostrzegło o globalnej kampanii masowego skanowania CMS i instalacji web shelli, być może z przyspieszeniem dzięki SI. Cel wybierany jest metodą przeglądu, a nie ręcznie.
Poprawka to nie czyszczenie
Aktualizacja zamyka wejście, ale nie usuwa już pozostawionych web shelli, fałszywych administratorów, zmian w .htaccess i cron. Bez zamknięcia utrwalenia dostępu stronę szybko infekują ponownie.
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 przywracanie
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ę.
Diagnostyka i zabezpieczenie
Sprawdzam stronę zdalnymi skanerami i na serwerze, oglądam Google Search Console, Safe Browsing i czarne listy, ustalam typ infekcji. Robię kopię aktualnego stanu i logów jako dowód. Logi kopiuję jako pierwsze.
Szukanie punktu wejścia po logach
Analizuję dzienniki dostępu: szukam żądań POST do podatnych zadań rozszerzeń, nietypowych przesłań i czasu pierwszego naruszenia. Tak rozumiem, przez co dokładnie weszli.
Porównanie z czystym rdzeniem
Pobieram oficjalny czysty pakiet Joomla w Twojej wersji i porównuję z działającą stroną, osobno szukam niedawno zmienionych plików. To ujawnia wstrzyknięcia w rdzeń, szablon i index.php.
Czyszczenie plików i bazy
Usuwam wstrzyknięty kod z plików i tabel bazy: szukam eval, base64_decode, gzinflate, exec, wstrzyknięć w index.php i parametry szablonu. W miarę możliwości zastępuję zainfekowane pliki oryginałami, zamiast poprawiać ręcznie.
Znalezienie i zamknięcie wszystkich backdoorów
Kluczowy etap. Przeczesuję media, images, tmp i niestandardowe foldery pod kątem web shelli, sprawdzam .htaccess we wszystkich katalogach i zadania harmonogramu pod kątem samoodtwarzających się zadań. Jeden pominięty backdoor to szybkie ponowne włamanie.
Czysta reinstalacja i aktualizacje
Reinstaluję rdzeń Joomla z czystego pakietu, aktualizuję rozszerzenia i szablony z oficjalnych źródeł, usuwam podatne, nieużywane i nieznane komponenty według listy podatnych rozszerzeń Joomla (VEL).
Zmiana dostępów i usunięcie obcych administratorów
Dopiero po oczyszczeniu usuwam fałszywych super administratorów, zmieniam wszystkie hasła, dostępy do bazy, FTP/SSH i hostingu, rotuję sekret configuration.php oraz klucze API. Kolejność jest ważna: dopóki trzymają się backdoory, zmiana haseł jest bezużyteczna.
Sprawdzenie i zdjęcie ostrzeżeń
Przeskanuję stronę ponownie, upewniam się, że nie ma złośliwego kodu ani obcych żądań wychodzących. Proszę o ponowne rozpatrzenie w Google Search Console i Yandex.Webmaster oraz proszę hosting o zdjęcie blokady.
Co otrzymujesz
Rezultat to nie zwykłe „strona się otworzyła”, lecz czysta, zaktualizowana i zabezpieczona strona plus zrozumienie, co się wydarzyło.
Czysta działająca strona
Bez web shelli, przekierowań, spamowych stron i defacementu, sprawdzona skanerem zdalnym i serwerowym.
Zamknięty punkt wejścia
Zaktualizowany rdzeń i rozszerzenia, usunięta podatność, przez którą weszli, żeby włamanie nie powtórzyło się tą samą drogą.
Kopia zapasowa sprzed czyszczenia
Pełny zrzut zhakowanego stanu i logów, zachowany osobno na wypadek postępowania albo spornych kwestii.
Raport o infekcji
Zrozumiały opis: co znalazłem (pliki, backdoory, obcy administratorzy), gdzie była luka, co usunięto i co zmieniono.
Zaktualizowane dostępy
Zmiana haseł administratorów, bazy, FTP/SSH i hostingu, rotacja sekretów configuration.php i kluczy API.
Zgłoszenia o ponowne rozpatrzenie
Wnioski o zdjęcie ostrzeżeń w Google Search Console i Yandex.Webmaster, w razie potrzeby kontakt z hostingiem o zdjęcie blokady.
Podstawowe wzmocnienie ochrony
Włączone 2FA dla administratorów, ograniczenie dostępu do panelu, zakaz wykonywania PHP w folderach przesyłania i inne działania po czyszczeniu.
Rekomendacje na przyszłość
Krótka lista kontrolna dotycząca aktualizacji, kopii zapasowych i monitoringu, by zmniejszyć ryzyko ponownej infekcji.
Formaty prac i terminy
Dobieram format do sytuacji: od pilnego przywrócenia strony do działania po pełne odtworzenie z ochroną i monitoringiem.
| Format | Kiedy pasuje | Co wchodzi | Termin |
|---|---|---|---|
| Leczenie awaryjne pilnie przywrócić stronę |
Strona jest zainfekowana albo przekierowuje, trzeba szybko przywrócić ją do działania. | Znalezienie i usunięcie złośliwego kodu, zdjęcie przekierowań i spamu, podstawowe zamknięcie wejścia. | od kilku godzin |
| Pełne odtworzenie i ochrona leczenie plus profilaktyka |
Usunąć infekcję i nie dopuścić do powtórki. | Wszystko z awaryjnego plus czysty rdzeń, aktualizacje, zmiana dostępów, zdjęcie ostrzeżeń, ochrona i kopie zapasowe. | 1-5 dni |
| Odtworzenie z kopii lub przebudowa trudne przypadki |
Strona jest mocno uszkodzona, a kopia zapasowa nie istnieje albo też jest zainfekowana. | Wdrożenie czystej kopii albo przebudowa na czystym rdzeniu z przeniesieniem treści. | zależnie od zakresu |
| Monitoring i ochrona abonament |
Trzymać stronę pod nadzorem po leczeniu. | Monitoring, aktualizacje, kopie zapasowe, szybka reakcja na incydenty. | co miesiąc |
* Dokładną cenę podaję po bezpłatnej diagnostyce: zależy od typu infekcji, rozmiaru strony i stanu kopii zapasowych. Prace zaczynam dopiero po uzgodnieniu wyceny.
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ą.
Częste pytania
Nie ma Twojego pytania? Napisz na Telegramie, odpowiem konkretnie w sprawie Twojego przypadku.
Ile kosztuje przywrócenie strony po włamaniu?
Zależy od zakresu infekcji: czym innym jest wyczyszczenie jednego wstrzyknięcia w index.php, a czym innym rozłożenie strony z kilkunastoma backdoorami i fałszywymi administratorami. Dlatego zaczynam od diagnostyki: oceniam skalę i podaję jasną cenę przed rozpoczęciem prac, bez niespodzianek w trakcie.
Ile czasu zajmie przywrócenie?
Proste przypadki (jedno przekierowanie albo wstrzyknięcie) często zamykam w kilka godzin albo w jeden dzień. Ciężkie infekcje z wielokrotnym utrwaleniem dostępu i zdejmowaniem ostrzeżeń Google mogą zająć kilka dni. Po diagnostyce podam realną ocenę dla Twojej strony.
Czy mogę stracić dane?
Najpierw robię pełną kopię zapasową obecnego stanu i pracuję na niej, a nie na ślepo na żywej stronie. Treść i ustawienia staram się zachować w całości. Ryzyko istnieje tylko tam, gdzie złośliwy kod fizycznie nadpisał pliki, i o tym uprzedzam z wyprzedzeniem.
Dacie gwarancję, że włamanie nie wróci?
Szczerze: nikt nie może dać 100% gwarancji w sieci. Ale zamykam nie tylko objawy, lecz sam punkt wejścia i całe utrwalenie (backdoory, .htaccess, cron), bo to właśnie przez pominiętą lukę część stron infekuje się ponownie już w ciągu doby. Do tego wzmacniam ochronę, żeby dawna droga przestała działać.
Czy potrzebne Wam dostępy do strony?
Tak, do pełnego czyszczenia potrzebne są dostępy do hostingu albo FTP/SSH i do panelu Joomla, czasem do bazy. Zdalny skaner widzi tylko frontend i pomija serwerowe backdoory, dlatego bez dostępu do plików włamania nie da się porządnie usunąć. Wszystkie dostępy po pracy zmieniasz.
Czy wystarczy po prostu zaktualizować Joomla i rozszerzenia?
Nie. Aktualizacja zamyka wejście, ale nie usuwa tego, co napastnik już zostawił: web shelle, obcy administratorzy, zmiany w .htaccess i zadania cron działają dalej także po poprawce. Dlatego aktualizacja to krok obowiązkowy, ale nie jedyny.
A jeśli po prostu wrócić do kopii zapasowej?
Ostrożnie: oficjalna dokumentacja Joomla wprost ostrzega, że przywrócenie kopii często po prostu przywraca włamanie, bo infekcja mogła trafić do kopii zapasowej razem ze stroną. Wracać warto tylko do kopii z pewnością wykonanej przed włamaniem i sprawdzonej pod kątem czystości. W pozostałych przypadkach pewniejsza jest czysta reinstalacja.
Czy pracujesz z WordPress i innymi CMS?
Moja główna specjalizacja to Joomla, tu znam niuanse szablonów, komponentów i typowych miejsc utrwalenia dostępu. Ogólne zasady czyszczenia (szukanie backdoorów, zamknięcie luki, zdjęcie ostrzeżeń) dotyczą też WordPress, tu mogę pomóc w podstawowych przypadkach, ale najgłębiej pracuję właśnie z Joomla.
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.
Zhakowano stronę? Zacznijmy od bezpłatnej diagnostyki
Opisz sytuację: co dzieje się ze stroną, na jakim jest CMS i czy są dostępy. Sprawdzę, ustalę typ infekcji i punkt wejścia oraz powiem, co i w jakich terminach trzeba zrobić. Bez zobowiązania do dalszego zlecenia.