Strona działa, formularz kontaktowy wysyła wiadomości, a panel administratora nadal pozwala edytować treści. Czy to oznacza, że wszystko jest bezpieczne?

Niestety nie zawsze. Starsza strona Joomla może przez długi czas wyglądać poprawnie, mimo że korzysta z niewspieranej wersji systemu, nieaktualnego frameworka szablonu albo komponentu zawierającego publicznie znaną lukę bezpieczeństwa.

W czerwcu i lipcu 2026 r. właściciele stron opartych na Joomla otrzymali kolejne poważne ostrzeżenie. Krytyczne podatności wykryto między innymi w popularnym SP Page Builderze oraz Helix Ultimate - rozwiązaniach używanych na wielu stronach firmowych.

W tym poradniku wyjaśniam, jakie zagrożenia pojawiły się w SP Page Builder i Helix Ultimate, jak sprawdzić używane wersje oraz dlaczego samo kliknięcie przycisku „Aktualizuj” nie zawsze rozwiązuje problem.

Pokazuję również, kiedy istniejącą stronę można bezpiecznie naprawić i przenieść do wspieranej wersji Joomla, a kiedy rozsądniejsze będzie wykonanie nowej witryny z zachowaniem wartościowych treści, adresów URL i elementów SEO.

Najważniejsze: aktualizacja zamyka lukę, ale nie usuwa automatycznie plików, kont administratorów ani backdoorów pozostawionych wcześniej przez atakującego.

Masz starszą Joomla albo nie wiesz, kiedy strona była aktualizowana? Zacznij od krótkiej diagnozy.

Stan informacji: 15 lipca 2026 r. Aktualną wersją Joomla jest 6.1.2. Wspierana jest również linia Joomla 5.4, której aktualne wydanie to 5.4.7. Wersje rozszerzeń i status podatności mogą się zmieniać, dlatego przed wdrożeniem należy ponownie sprawdzić dokumentację producentów.

Włamanie nie zawsze oznacza podmianę strony na ekran z komunikatem hakera. Współczesne ataki często mają pozostać niewidoczne możliwie długo. Zamiast usuwać witrynę, atakujący może pozostawić ukryty dostęp i wykorzystywać serwer do własnych celów.

Zainfekowana strona może między innymi:

• przekierowywać wybranych użytkowników na fałszywe sklepy lub reklamy,
• wyświetlać spam tylko osobom wchodzącym z Google albo z telefonu,
• tworzyć ukryte podstrony pozycjonujące podejrzane usługi,
• wysyłać wiadomości spamowe z serwera,
• odczytywać dane zapisane w pliku configuration.php,
• dodawać nieautoryzowane konta administratorów,
• infekować inne strony znajdujące się na tym samym koncie hostingowym.

Dlatego brak widocznych zmian na stronie nie jest potwierdzeniem jej bezpieczeństwa.

W 2026 r. szczególną uwagę zwróciły podatności w SP Page Builder i Helix Ultimate. Oba rozszerzenia są często instalowane razem, ponieważ służą do budowy układu strony i obsługi szablonu.

SP Page Builder jest popularnym wizualnym edytorem dla Joomla. Pozwala budować sekcje, kolumny, przyciski, galerie i formularze bez ręcznego tworzenia całego układu.

W czerwcu 2026 r. ujawniono podatność oznaczoną jako CVE-2026-48908. Problem dotyczył zadania odpowiedzialnego za przesyłanie własnych ikon. Punkt końcowy mógł przyjąć plik bez zalogowania użytkownika i bez poprawnej kontroli typu przesyłanego pliku.

W praktyce atakujący mógł próbować przesłać na serwer plik PHP i uruchomić go przez internet. Oznaczało to możliwość zdalnego wykonania kodu, czyli RCE - Remote Code Execution.

Podatność otrzymała maksymalną ocenę CVSS 10.0. Zagrożone były wersje SP Page Builder do 6.6.1 włącznie. Wersja 6.6.2 została opublikowana 15 czerwca 2026 r. i zabezpieczyła podatny mechanizm przesyłania plików.

7 lipca 2026 r. CISA dodała tę podatność do katalogu luk wykorzystywanych w rzeczywistych atakach. Nie był to więc wyłącznie problem teoretyczny.

Po uzyskaniu możliwości uruchamiania kodu na serwerze napastnik mógł potencjalnie:

• odczytać plik configuration.php i dane dostępowe do bazy,
• zmodyfikować pliki Joomla, szablonu lub innych rozszerzeń,
• dodać ukryty webshell lub backdoor,
• utworzyć fałszywe konto administratora,
• dodać przekierowania albo kod wyświetlający spam,
• wykorzystać serwer do dalszych ataków,
• próbować przejąć inne strony na tym samym koncie hostingowym.

Nie oznacza to, że każda strona ze starszym SP Page Builderem została zainfekowana. Oznacza jednak, że podatna instalacja mogła zostać zaatakowana automatycznie, bez znajomości loginu i hasła administratora.

Helix Ultimate jest frameworkiem szablonów rozwijanym przez JoomShaper. Odpowiada między innymi za układ strony, menu, nagłówek, moduły, ustawienia responsywności i część mechanizmów edycji.

W wersjach do 2.2.6 brakowało prawidłowej kontroli uprawnień i ochrony części żądań AJAX. Osoba niezalogowana mogła próbować zapisać szkodliwą zawartość w parametrach pozycji menu. Kod mógł następnie uruchomić się w przeglądarce zalogowanego administratora jako zapisany XSS.

Podatność została zarejestrowana jako CVE-2026-57829 i otrzymała ocenę CVSS 8.7. Została naprawiona w Helix Ultimate 2.2.7. Na dzień publikacji aktualną wersją jest 2.2.8.

Ważne rozróżnienie: na 15 lipca 2026 r. nie ma oficjalnego potwierdzenia wykorzystania tej luki w rzeczywistych atakach. Dostępny jest jednak publiczny opis techniczny, dlatego aktualizacji nie warto odkładać.

Zapisany XSS oznacza, że szkodliwy kod może zostać umieszczony w bazie danych strony i uruchomić się później, kiedy administrator otworzy określony widok lub menu.

W zależności od przygotowanego ładunku może to prowadzić do wykonywania działań w kontekście zalogowanego administratora, zmiany ustawień, wyświetlenia fałszywego formularza logowania, kradzieży informacji dostępnych w panelu albo próby rozszerzenia dostępu do całej witryny.

Po aktualizacji Helix Ultimate należy skontrolować nie tylko pliki, ale również parametry pozycji menu i listę kont z uprawnieniami Super User.

To jeden z najważniejszych elementów całej procedury. Aktualizacja rozszerzenia zamyka konkretną lukę, ale nie usuwa automatycznie zmian wykonanych wcześniej przez atakującego.

Można to porównać do wymiany uszkodzonego zamka. Nowy zamek utrudnia ponowne wejście tą samą metodą, ale nie sprawdza, czy ktoś wcześniej nie pozostawił wewnątrz dodatkowego klucza.

Po podejrzeniu wykorzystania luki potrzebne są co najmniej:

1. kopia aktualnego stanu strony do celów analizy,
2. sprawdzenie logów serwera i Joomla,
3. skanowanie całego konta hostingowego,
4. porównanie plików systemowych z oryginalnymi pakietami,
5. kontrola użytkowników i uprawnień,
6. kontrola bazy danych oraz zadań CRON,
7. zmiana danych dostępowych po zakończeniu czyszczenia,
8. ponowny skan i monitoring zmian.

Nie każdy błąd oznacza włamanie, ale poniższe symptomy wymagają szybkiej diagnostyki:

• nieznane konto administratora albo nagła zmiana uprawnień użytkownika,
• przekierowania na obce strony, szczególnie tylko na telefonie lub po wejściu z wyszukiwarki,
• nowe pliki PHP w katalogach obrazów, fontów, cache lub plików tymczasowych,
• zmiany w pliku .htaccess albo głównych plikach index.php,
• obce treści w Google związane z lekami, kasynami, pożyczkami lub kryptowalutami,
• ostrzeżenie z hostingu lub Google dotyczące złośliwego kodu albo wysyłania spamu,
• powracająca infekcja po usunięciu jednego lub kilku wykrytych plików,
• nietypowe obciążenie serwera, duża liczba wysyłanych wiadomości lub błędów PHP.

Przekierowania i spam często są wyświetlane selektywnie. Administrator oglądający stronę codziennie może ich nie zobaczyć.

Najgorszym rozwiązaniem jest chaotyczne kasowanie przypadkowych plików bez kopii i bez zapisania informacji potrzebnych do analizy.

1. Zabezpiecz kopię aktualnego stanu

Nawet zainfekowaną stronę warto skopiować przed rozpoczęciem prac. Kopia może pomóc ustalić daty modyfikacji, sposób wejścia i zakres zmian.

2. Ogranicz dostęp do witryny

W zależności od sytuacji można włączyć tryb serwisowy, ograniczyć dostęp do panelu, zastosować regułę WAF albo tymczasowo zablokować podatny punkt końcowy. Blokada nie zastępuje aktualizacji.

3. Sprawdź logi i użytkowników

Należy przeanalizować logi serwera WWW, błędy PHP, historię działań, daty plików i listę kont administratorów. Nieznane konto warto najpierw udokumentować, a następnie zablokować.

4. Skanuj całe konto hostingowe

Infekcja może znajdować się w innej domenie, starej kopii, katalogu testowym, zadaniu CRON albo poza głównym katalogiem publicznym.

5. Zmień dane dostępowe

Po oczyszczeniu należy zmienić hasła Joomla, hostingu, FTP lub SFTP, SSH, bazy danych i kont e-mail powiązanych z administracją.

W panelu administratora Joomla przejdź do:

System - Zarządzanie - Rozszerzenia

Następnie wyszukaj:

• SP Page Builder, com_sppagebuilder, SP Page Builder Pro lub Lite,
• Helix Ultimate, helixultimate albo shaper_helixultimate.

W przypadku Helix warto sprawdzić zarówno szablon, jak i powiązaną wtyczkę systemową.

Brak komunikatu o aktualizacji nie oznacza automatycznie, że używana wersja jest bezpieczna. Powodem może być wygasła licencja, brak klucza aktualizacji, uszkodzony serwer aktualizacji, bardzo stara wersja dodatku albo niezgodność z PHP.

Standardowe wsparcie Joomla 3 zakończyło się 17 sierpnia 2023 r. Dodatkowy program rozszerzonego wsparcia bezpieczeństwa eLTS działał do 17 lutego 2025 r.

Oznacza to, że Joomla 3 nie otrzymuje standardowych poprawek bezpieczeństwa projektu. Problemem jest również otoczenie starej instalacji:

• porzucone komponenty i wtyczki,
• szablony bez aktualizacji,
• rozszerzenia wymagające starego PHP,
• niewspierane biblioteki JavaScript,
• modyfikacje wykonane wiele lat temu bez dokumentacji,
• brak zgodności z nowoczesnym hostingiem.

Strona może nadal działać, ale każdy kolejny miesiąc zwiększa dług technologiczny, ryzyko awarii i koszt późniejszej migracji.

Nie każdą stronę da się przenieść jednym kliknięciem. W zależności od wersji i stanu technicznego proces może wymagać kilku etapów:

• uporządkowania Joomla 3.10 i przejścia do Joomla 4,
• aktualizacji Joomla 4.4 do Joomla 5,
• wymiany albo przebudowy niezgodnych rozszerzeń,
• aktualizacji szablonu i frameworka,
• zmiany wersji PHP,
• usunięcia modyfikacji wykonanych w plikach core,
• przebudowy wybranych modułów i podstron,
• przejścia z Joomla 5.4 do Joomla 6, gdy wszystkie elementy są zgodne.

Każdy etap powinien zostać poprzedzony kopią bezpieczeństwa, testem na stagingu i kontrolą logów. Aktualizowanie wieloletniej strony bez planu bezpośrednio na produkcji jest działaniem wysokiego ryzyka.

Nie każdą starszą witrynę trzeba od razu usuwać. W wielu przypadkach można zachować treści, strukturę i wygląd. Są jednak sytuacje, w których nowa instalacja jest bezpieczniejsza i ekonomicznie bardziej uzasadniona.

Nowa strona nie musi oznaczać utraty widoczności, jeżeli migracja zostanie prawidłowo zaplanowana. Należy zadbać o:

• zachowanie wartościowych adresów URL,
• przekierowania 301 dla zmienionych adresów,
• przeniesienie tytułów, meta opisów i treści,
• zachowanie logicznej struktury H1-H3,
• aktualizację mapy witryny,
• kontrolę indeksacji w Google Search Console,
• sprawdzenie danych strukturalnych, formularzy i analityki,
• optymalizację szybkości i wersji mobilnej.

Nieprzemyślana przebudowa może zaszkodzić SEO. Dobrze przygotowana migracja może poprawić szybkość, czytelność, bezpieczeństwo oraz skuteczność strony w pozyskiwaniu klientów.

Nie zaczynam od automatycznej instalacji wszystkich dostępnych aktualizacji na działającej stronie. Najpierw ustalam stan techniczny, możliwą ścieżkę migracji i zakres ryzyka.

W ramach wstępnego przeglądu sprawdzane są między innymi:

• wersja Joomla i PHP,
• aktywny szablon oraz framework,
• zainstalowane komponenty i wtyczki,
• dostępność aktualizacji i aktywność producentów dodatków,
• błędy panelu, strony, konsoli i logów PHP,
• podstawowe oznaki infekcji,
• stan certyfikatu SSL i kopii zapasowych,
• możliwość migracji bez utraty treści i SEO.

Po diagnozie można uczciwie określić, czy potrzebna jest aktualizacja, naprawa, czyszczenie, migracja etapowa czy wykonanie nowej strony.

Oba rozwiązania odpowiadają na inne potrzeby. Jednorazowa usługa usuwa konkretny problem. Stała opieka ogranicza ryzyko, że podobny problem pozostanie niezauważony przez wiele miesięcy.

Regularna konserwacja pozwala wykryć problem, zanim rozwinie się w poważny incydent. Koszt kontroli i aktualizacji jest zwykle niższy niż:

• wielogodzinne czyszczenie serwera,
• ręczna analiza setek lub tysięcy plików,
• odtwarzanie strony z niepewnej kopii,
• odzyskiwanie dostępu do panelu i hostingu,
• usuwanie spamu z wyników Google,
• naprawa reputacji domeny i poczty,
• przestój w pozyskiwaniu zapytań,
• pilna budowa nowej strony pod presją czasu.

Strona internetowa jest narzędziem biznesowym. Powinna być utrzymywana podobnie jak komputer firmowy, system księgowy albo sklep internetowy.

Do pierwszego kontaktu wystarczy przesłać:

• adres strony,
• krótki opis zauważonego problemu,
• informację, kiedy problem pojawił się po raz pierwszy,
• wersję Joomla, jeżeli jest znana,
• treść komunikatu z hostingu lub zrzut błędu,
• informację o ostatnich aktualizacjach,
• informację, czy dostępna jest kopia zapasowa.

Nie przesyłaj haseł w pierwszej wiadomości. Dostępy do panelu, hostingu lub serwera powinny zostać przekazane bezpiecznym kanałem dopiero po ustaleniu zakresu prac. Warto również zanonimizować logi zawierające dane klientów.

Poniżej znajdziesz odpowiedzi na pytania, które najczęściej pojawiają się przed aktualizacją albo przejęciem opieki nad starszą stroną.

Jeżeli strona działa na starszej Joomla, SP Page Builderze, Helix Ultimate albo od dawna nie była aktualizowana, warto zacząć od spokojnej diagnozy zamiast od przypadkowych zmian na produkcji.

Nie każda witryna wymaga budowy od zera. Najpierw sprawdzam, co można bezpiecznie naprawić, zachować i zaktualizować. Gdy migracja nie jest technicznie albo ekonomicznie uzasadniona, przedstawiam propozycję nowej strony z zachowaniem wartościowych treści i elementów SEO.

Informacje o wersjach i podatnościach zostały przygotowane na podstawie oficjalnych komunikatów projektu Joomla, rekordów CVE, katalogu CISA oraz dokumentacji JoomShaper. Przed rozpoczęciem prac należy ponownie sprawdzić aktualne wydania.