Używasz SP Page Builder na swojej Joomla? Zmów paciorek 😅

Joomla 5, aktualny PHP, regularnie instalowane poprawki, legalne rozszerzenia. Brzmi jak zestaw, przy którym można spać spokojnie.

No właśnie nie zawsze.

W czerwcu 2026 roku miałem okazję zobaczyć bardzo ciekawy — i jednocześnie bardzo nieprzyjemny — przypadek związany z SP Page Builderem. W zasadzie były to dwa przypadki.

Dwie strony oparte na Joomla. Obie korzystały z SP Page Buildera. Obie zostały wystawione na ten sam rodzaj ataku. Obie pozostawiły po nim ślady.

A jednak finał był zupełnie inny.

Na jednej stronie znalazłem później obce pliki PHP porozrzucane po serwerze, w tym również w głównym katalogu domeny. Krótko mówiąc: ktoś nie tylko zapukał do drzwi, ale prawdopodobnie wszedł do środka.

Na drugiej stronie znalazłem coś jeszcze ciekawszego: całą serię podejrzanych katalogów związanych z iconfont, pliki fontów oraz charakterystyczny .htaccess przygotowujący serwer do uruchomienia pliku .PHP.

Tylko że... samego złośliwego PHP już tam nie było.

Jedna strona została zainfekowana. Druga wygląda tak, jakby exploit dotarł prawie do mety, ale czegoś zabrakło.

I właśnie dlatego warto tę historię opisać.

Na Joomla, obecnie na wersji 6 tworzymy strony WWW dla firm, strony bardziej złożone i zawsze sobie ceniłem poziom bezpieczeństwa jaki dostarcza Joomla. Tu też jest ciekawy wniosek i potwierdzenie naszej polityki zwłaszcza do sklepów internetowych.

Zawsze ale to zawsze dobieraj system tak by jak najwięcej pożądanych funkcji zapewnił ci natywnie, bez instalowania dodatkowych rozszerzeń. Im mniej rozszerzeń tym mniej potencjalnych zagrożeń. 

Zanim jeszcze przejdę do konkretów, pozostańmy na chwilę w śród ogólników bo muszę podzielić się z wami ważnymi obserwacjami. W ostatnim czasie wpada do nas na warsztat sporo zhakowanych stron opartych Joomla, Wordpress. Napisałem też kilka artykułów z tych zdarzeń jak: "Zhakowana Joomla 3.0.9 - proces odzyskania strony" czy "Krytyczne podatności WordPress CVE-2026-63030 i CVE-2026-60137 – co musisz wiedzieć i jak się zabezpieczyć". Obserwacje moje dotyczą częstości i powagi pojawiania się luk zabezpieczeniach jak CVE-2026-63030 i CVE-2026-60137 i to w samym gołym systemie Wordpress. Według raportów firm bezpieczeństwa, takich jak Patchstack, tylko w 2025 roku w samym ekosystemie WordPressa wykryto rekordowe 11 334 nowe luki bezpieczeństwa, co oznacza wzrost o 42% rok do roku. Z czego to wynika? Jestem w 100% przekonany ze za trendem siedzi po prostu AI. Tak jak my używamy AI do tworzenia, automatyzowania, tak hakerzy używają AI do analizowania kodu wtyczek. Jak to działa? Pobierasz wtyczkę, odpalasz agenta AI, zlecasz mu analizę kodu i odszukanie luk które umożliwią np wgranie na serwer pliku, gdy ten ją znajdzie zlecasz mu napisanie oprogramowania - bota, który będzie spacerował sobie po sieci wyłapywał strony z podatnością i je atakował. 

 

Joomla 5 też może zostać zhakowana

Na początek warto rozprawić się z jednym częstym sposobem myślenia:

„Przecież to Joomla 5, więc jak mogli się włamać?”

Mogli.

Nowoczesna wersja CMS-a zmniejsza ryzyko związane z lukami w samym rdzeniu Joomla, ale strona internetowa nie składa się wyłącznie z Joomla Core.

• komponenty,
• pluginy,
• moduły,
• szablony,
• page buildery,
• biblioteki JavaScript,
• system cache,
• integracje z formularzami,
• galerie,
• systemy płatności,
• narzędzia SEO.

Wystarczy jedna poważna podatność w jednym z takich elementów.

W tym przypadku bardzo mocny ślad prowadził do SP Page Buildera.

 

Co wydarzyło się w SP Page Builderze?

Problem został oznaczony jako CVE-2026-48908.

Podatność dotyczyła SP Page Buildera do wersji 6.6.1 włącznie i pozwalała nieuwierzytelnionemu użytkownikowi wykorzystać endpoint:

index.php?option=com_sppagebuilder&task=asset.uploadCustomIcon

Problem polegał na tym, że mechanizm służący do wgrywania własnych zestawów ikon nie wykonywał odpowiednich kontroli dostępu i weryfikacji przesyłanych plików.

W praktyce możliwe było przesłanie przygotowanej paczki zawierającej kod, który następnie mógł zostać zapisany w publicznie dostępnym katalogu strony.

To nie był więc błąd klasy „administrator zobaczy zły komunikat” czy „można odczytać nazwę użytkownika”. Mówimy o klasie podatności, która mogła prowadzić do Remote Code Execution, czyli zdalnego wykonania kodu na serwerze bez wcześniejszego logowania.

Producent wydał SP Page Builder 6.6.2 15 czerwca 2026 roku, a w changelogu znalazła się poprawka bezpieczeństwa endpointów uploadu.

 

Dlaczego ta luka była tak groźna?

Internet
   ↓
podatny SP Page Builder
   ↓
asset.uploadCustomIcon
   ↓
przesłanie spreparowanej paczki
   ↓
rozpakowanie jej do katalogu iconfont
   ↓
zapis pliku wykonywalnego
   ↓
uruchomienie PHP
   ↓
webshell
   ↓
pełny dostęp w ramach uprawnień procesu PHP

Jeżeli atakujący uzyska możliwość wykonywania własnego PHP, może próbować odczytać configuration.php, pozyskać dane dostępowe do bazy, tworzyć kolejne pliki, modyfikować istniejące pliki, dodawać użytkowników, instalować backdoory i utrwalać dostęp.

 

Aktualizacja zamyka drzwi. Nie wyrzuca włamywacza z domu

Jeżeli webshell został wrzucony przed aktualizacją, aktualizacja SP Page Buildera zamknie lukę, ale nie usunie już istniejącego backdoora. Dlatego po tak poważnej podatności pytanie „Czy mam najnowszą wersję?” jest dopiero pierwszym pytaniem. Drugie brzmi: „Czy ktoś nie zdążył wejść zanim ją zaktualizowałem?”

 

Przypadek pierwszy: Joomla 5 i realna infekcja

Pierwsza analizowana przeze mnie strona działała na Joomla 5. Nie podaję domeny ani danych właściciela. Strona była hostowana w Cyber_Folks.

Podczas analizy znalazłem na serwerze pliki PHP, które nie należały ani do Joomla, ani do zainstalowanych rozszerzeń. Część z nich znajdowała się bezpośrednio w głównym katalogu strony.

Wszystkie podejrzane pliki miały daty prowadzące do czerwca 2026 roku, czyli okresu bardzo dobrze pokrywającego się z aktywnym wykorzystywaniem podatności SP Page Buildera.

 

Dlaczego złośliwe PHP znalazło się w głównym katalogu, skoro luka była w SP Page Builderze?

Pierwszy plik służy tylko do zdobycia możliwości wykonania kodu. Jeżeli atakujący uzyska RCE, kolejne pliki może próbować utworzyć praktycznie wszędzie tam, gdzie użytkownik procesu PHP ma prawo zapisu.

/media/com_sppagebuilder/assets/iconfont/...

może więc prowadzić później do:

/public_html/random.php
/images/xyz.php
/templates/system/helper.php

Dlatego miejsce znalezienia finalnego malware nie musi być miejscem wejścia.

 

Przypadek drugi: ten sam SP Page Builder, ale zupełnie inny finał

Druga strona również działała na Joomla i korzystała z SP Page Buildera. Tym razem hostingiem był Zenbox.

W katalogu:

/media/com_sppagebuilder/assets/iconfont/

znalazłem kilka katalogów o nazwach przypominających:

icofsnptm
icopeigmh
icouesusd
icoulzcsl
icourpzsi

Wewnątrz znajdowały się pliki fontów .ttf oraz .htaccess z wpisem:

AddType application/x-httpd-php .PHP

 

Najbardziej podejrzanym plikiem wcale nie był PHP

Ta linia miała sprawić, aby pliki z rozszerzeniem .PHP były traktowane jako wykonywalny PHP. To charakterystyczny element próby obejścia filtrów uploadu i przygotowania serwera do wykonania payloadu.

 

Tyle że pliku .PHP nie było

Na stronie hostowanej w Zenbox znalazłem katalogi ico..., pliki .ttf i podejrzany .htaccess, ale nie znalazłem *.PHP, *.php, *.phtml ani *.phar, które wyglądałyby jak payload.

Przeskanowałem też pozostałe katalogi strony pod kątem nowych lub podejrzanych PHP. Nie znalazłem niczego, co wyglądałoby jak dalsza infekcja.

Atak ewidentnie dotarł bardzo daleko, ale nie mam dowodu, że zakończył się skutecznym wykonaniem kodu.

 

Ten sam exploit, dwa różne rezultaty

Etap	Przypadek Cyber_Folks	Przypadek Zenbox
Joomla + SP Page Builder	tak	tak
Ślady aktywności w okresie luki	tak	tak
Podejrzane katalogi / struktura exploita	ślady infekcji	tak
.htaccess przygotowujący .PHP	możliwe	tak, znaleziony
Obce PHP na serwerze	tak	nie znaleziono
PHP w głównym katalogu strony	tak	nie
Dalsza infekcja	potwierdzona podejrzanymi plikami	brak potwierdzenia
Pełne RCE	bardzo prawdopodobne	brak dowodu

 

Czy hosting mógł zrobić różnicę?

Tak, ale bez logów WAF nie można tego stwierdzić ze stuprocentową pewnością.

Różnica mogła wynikać z innych reguł WAF, innej konfiguracji domeny, stosu Apache/LiteSpeed, ustawień AllowOverride, sposobu obsługi .htaccess, konfiguracji PHP, praw zapisu, blokady wykonywania PHP w katalogu /media albo mechanizmów antymalware.

 

Na jednym hostingu WAF potrafi blokować mi nawet zapis artykułu o hakowaniu

Na serwerze, na którym nie znalazłem skutecznej infekcji, zdarzało mi się wcześniej, że Joomla nie pozwalała zapisać artykułu zawierającego frazy związane z exploitami, SQL injection czy webshellami. To typowe zachowanie WAF lub mod_security: filtr widzi request POST przypominający próbę ataku i blokuje go.

 

Jak mogło wyglądać zatrzymanie ataku?

bot wysyła spreparowaną paczkę
↓
SP Page Builder przyjmuje upload
↓
powstaje katalog ico...
↓
zapisany zostaje .ttf
↓
zapisany zostaje .htaccess
↓
atakujący próbuje zapisać lub uruchomić shell.PHP
↓
WAF / konfiguracja Apache / blokada PHP zatrzymuje operację
↓
brak wykonania kodu

 

WAF nie naprawia podatności

WAF może rozpoznać wzorzec ataku, zablokować podejrzany request albo uniemożliwić wykonanie części exploita, ale podatny komponent nadal pozostaje podatny.

aktualny CMS
+
aktualne rozszerzenia
+
ograniczone prawa
+
WAF
+
monitoring
+
backup

a nie:

stary komponent
+
modlitwa do WAF

 

Skąd w ogóle te katalogi iconfont?

SP Page Builder umożliwia wgrywanie własnych zestawów ikon. Prawidłowa paczka może mieć strukturę:

selection.json
style.css
fonts/
    nazwa.ttf

Dlatego samo znalezienie .ttf nie oznacza infekcji. Ale losowy katalog ico... plus .ttf plus .htaccess zawierający AddType ... .PHP to już mocny wskaźnik próby wykorzystania podatności.

 

Dlaczego atakujący używali .PHP, a nie .php?

Prosty filtr może blokować shell.php, ale przepuścić shell.PHP, jeśli rozszerzenie nie jest normalizowane do małych liter. Do tego dochodzą warianty typu .pHp, .Php, .phtml, .pht czy .phar.

 

Zaktualizowałem SP Page Builder. Czy jestem bezpieczny?

Jeżeli aktualizacja została wykonana zanim ktoś wykorzystał podatność — prawdopodobnie tak, przynajmniej w kontekście tej konkretnej luki. Jeżeli jednak strona działała przez pewien czas na podatnej wersji, odpowiedź brzmi: nie wiadomo.

 

Co sprawdzić, jeżeli używasz lub używałeś SP Page Buildera?

1. Sprawdź aktualną wersję SP Page Buildera.
2. Zaktualizuj komponent do najnowszej wersji.
3. Sprawdź /media/com_sppagebuilder/assets/iconfont/.
4. Przejrzyj losowe katalogi ico....
5. Wyszukaj wszystkie .htaccess wewnątrz media.
6. Szukaj AddType application/x-httpd-php .PHP.
7. Wyszukaj wszystkie nietypowe PHP.
8. Sprawdź pliki utworzone lub zmodyfikowane w czerwcu 2026.
9. Skontroluj użytkowników Super User.
10. Przejrzyj logi serwera pod kątem asset.uploadCustomIcon.
11. Jeżeli znajdziesz potwierdzone malware, przeprowadź pełne czyszczenie.
12. Zmień hasła i dane dostępowe, które mogły zostać odczytane po przejęciu strony.

 

Nie szukaj jednak tylko w SP Page Builderze

/
administrator/
components/
plugins/
modules/
templates/
images/
media/
tmp/
cache/

Przydatne może być:

find . -type f \( -iname "*.php" -o -iname "*.phtml" -o -iname "*.pht" -o -iname "*.phar" \) -ls

oraz:

find . -type f \( -iname "*.php" -o -iname "*.phtml" -o -iname "*.phar" \) -newermt "2026-06-01" ! -newermt "2026-07-01" -ls

 

Sprawdź wszystkie .htaccess

find . -name ".htaccess" -print

grep -RIl "application/x-httpd-php" .

grep -RIl "AddType" .

 

Sprawdź konta administratorów

Przejrzyj wszystkie konta z wysokimi uprawnieniami i szukaj nieznanych nazw, dziwnych adresów e-mail, świeżych dat utworzenia oraz kont przypominających systemowe.

 

Sprawdź configuration.php

Po potwierdzonej kompromitacji zmień hasło do panelu hostingowego, FTP/SFTP, hasło bazy danych, hasła administratorów Joomla, klucze API i dane SMTP.

 

Aktualizacja Joomla Core nie wystarczy

Możesz mieć aktualną Joomla 5.x, PHP 8.4 i HTTPS, a mimo tego mieć problem przez jedno rozszerzenie. Bezpieczeństwo strony jest tak dobre, jak najsłabszy element całego stosu.

 

A co z licencją?

W jednym z analizowanych przypadków licencja SP Page Builder Pro wygasła 14 czerwca 2026, a wersja 6.6.2 z poprawką bezpieczeństwa została opublikowana 15 czerwca 2026. Co za ironia🥹!  To pokazuje, że aktywna licencja komercyjnego rozszerzenia może mieć bezpośredni wpływ na dostęp do aktualizacji bezpieczeństwa.

 

„Przecież na stronę wchodzę codziennie”

Zainfekowana strona wcale nie musi od razu przekierowywać na kasyno, wyświetlać reklam czy pokazywać komunikatu „HACKED”. Dobrze napisany backdoor ma być niewidoczny.

 

Czy w drugim przypadku strona była na pewno czysta?

Nie mogę powiedzieć tego ze stuprocentową pewnością. Mogę natomiast powiedzieć, że znalazłem wyraźne ślady próby wykorzystania podatności, ale nie znalazłem dowodów skutecznego wykonania payloadu ani dalszej infekcji PHP.

 

Hosting nie zastąpi administratora, ale może kupić mu czas

Dwie strony mogą mieć ten sam CMS, to samo rozszerzenie i tę samą lukę, a rezultat może być zupełnie inny.

upload
→ PHP
→ wykonanie
→ webshell
→ infekcja

albo:

upload
→ .htaccess
→ próba PHP
→ blokada

 

Co zrobiłbym dziś na każdej stronie ze SP Page Builderem?

Zaktualizowałbym komponent, przejrzał iconfont, sprawdził wszystkie nietypowe .htaccess, wyszukał obce PHP, sprawdził użytkowników Super User oraz logi z okresu ataku.

 

Czego szukać w access logu?

/index.php?option=com_sppagebuilder&task=asset.uploadCustomIcon

Szczególnie ciekawy układ to:

POST /index.php?...asset.uploadCustomIcon
200

GET /media/com_sppagebuilder/assets/iconfont/ico.../fonts/...PHP
200

Jeżeli GET zwrócił 403, może to oznaczać, że infrastruktura zatrzymała etap wykonania.

 

Co zrobić ze stroną, która została już przejęta?

Jeżeli mam potwierdzony webshell, wolę odbudowę z czystego Joomla Core, czystych rozszerzeń, sprawdzonego szablonu, zweryfikowanych własnych plików i oczyszczonej bazy niż usuwanie kilku znalezionych wirusów ze starej instalacji.

 

Czy winny jest SP Page Builder?

Winna jest konkretna podatność w konkretnej wersji oprogramowania. Problemem nie jest samo używanie SP Page Buildera, tylko używanie podatnej wersji i brak wiedzy, czy ktoś wykorzystał lukę przed aktualizacją.

 

Najbardziej zaskakujący wniosek z całej historii

Najciekawszy był drugi serwer. Zostawił coś w rodzaju odcisków butów przy oknie: katalogi ico..., plik fontu, podejrzany .htaccess i linię:

AddType application/x-httpd-php .PHP

A jednak brak dalszych PHP.

Atak komputerowy nie jest zdarzeniem binarnym. Może być skan, próba exploita, częściowo skuteczny upload, próba wykonania, dopiero potem RCE i utrwalenie dostępu.

 

Używasz SP Page Builder? Zmów paciorek... ale potem sprawdź serwer

Jeżeli używałeś podatnej wersji SP Page Buildera w czerwcu 2026, nie ograniczałbym się do sprawdzenia numeru wersji dzisiaj.

Zaktualizuj, ale również poszukaj śladów.

Sprawdź iconfont, .htaccess, PHP, użytkowników i logi.

Jeżeli znajdziesz:

AddType application/x-httpd-php .PHP

w losowym katalogu wewnątrz media/com_sppagebuilder/assets/iconfont/, nie traktuj tego jak przypadkowego pliku pozostawionego przez rozszerzenie.

Bo czasami najbardziej interesującym śladem włamania wcale nie jest wirus.

Jest nim jedna niewinna linijka w .htaccess.

 

Podsumowanie

W pierwszym przypadku znalazłem obce PHP i ślady wskazujące, że napastnikowi udało się przejść do kolejnego etapu ataku.

W drugim znalazłem elementy charakterystyczne dla exploita SP Page Buildera, ale nie znalazłem finalnego payloadu ani dalszego malware.

Czy różnicę zrobiła konfiguracja hostingu? Bardzo możliwe. Czy mogę to udowodnić bez logów WAF z chwili ataku? Nie.

To jednak dobrze pokazuje, że bezpieczeństwo strony nie opiera się na jednym magicznym rozwiązaniu. Najlepszą ochronę daje kilka warstw działających jednocześnie.

A jeżeli któraś z nich zadziała w odpowiednim momencie, być może któregoś dnia wejdziesz do katalogu:

/media/com_sppagebuilder/assets/iconfont/

zobaczysz ślady po próbie włamania i będziesz mógł powiedzieć:

„Było blisko.”

Zamiast:

„No dobra, teraz trzeba odbudować całą stronę.” 😅