CVE-2026-48908 — Joomla SP Page Builder Validierung und Erkennung

Laborvalidierung von CVE-2026-48908 in der Joomla SP Page Builder Komponente, mit Fokus auf technische Beweise, Ereignisrekonstruktion und defensive Erkennungsmöglichkeiten.

Das Repository dokumentiert einen kontrollierten Test, bei dem der asset.uploadCustomIcon-Endpunkt des SP Page Builders hochgeladene Icon-Archive akzeptierte, die zur Erstellung von PHP-Artefakten unter dem Joomla-Medienverzeichnis führten. Das Aufrufen der hochgeladenen PHP-Datei über HTTP führte zur Befehlsausführung als Prozessbenutzer des Webservers. Die daraus resultierenden HTTP-, Datei-, Prozess-, Authentifizierungs- und Netzwerkaktivitäten wurden mit Apache-Container-Logs, Linux auditd, tcpdump, Docker-Telemetrie, Dateiänderungsabfragen und Screenshots vom Windows-Host erfasst.

[!IMPORTANT] Dieses Repository enthält ausschließlich Berichte und Screenshots. Angriffs-Exploit-Code, Payload-Quellen, rohe PCAP-Dateien und rohe Host-Beweispakete sind absichtlich nicht enthalten. Das Material ist für Schwachstellenvalidierung, SOC-Engineering, Erkennungsentwicklung, Incident-Response-Vorbereitung und autorisierte Forschung bestimmt.

Berichte

• Englischer Validierungsbericht
• Polnischer Validierungsbericht

Beide Berichte enthalten die vollständige Testmethodik, Beweisauszüge, Ereigniszeitlinie, Dateiänderungsnachweise, Netzwerkindikatoren, Hinweise zur Gegenmaßnahme, Prüfempfehlungen und Beispiel-SIEM-Logik.

Repository-Struktur

.
├── README.md
├── SHA256SUMS.txt
├── reports/
│   ├── CVE-2026-48908_SP_Page_Builder_detection_EN.pdf
│   └── CVE-2026-48908_SP_Page_Builder_detection_PL.pdf
└── screenshots/
    ├── 01_poc_upload_and_code_execution.png
    ├── 02_http_whoami_www_data.png
    ├── 03_tcp_callback_ncat.png
    ├── 04_reverse_shell_session.png
    └── 05_root_access_and_su_failure_redacted.png

Es sind keine Exploit-Quellen, Payload-Quellen, rohen PCAP-Dateien, rohen Docker-Beweispakete oder DOCX-Quelldateien enthalten.

Testumgebung

Das Joomla-Webroot /var/www/html wurde durch das Docker-Volume joomla5-builders_joomla_data bereitgestellt. Dies ist für die Erkennung wichtig: docker diff bot keine detaillierte Sicht auf Dateiänderungen innerhalb des Volumes, daher musste die Dateiüberwachung auf volumenbewusste Dateilistings und hostseitige Überwachungshinweise zurückgreifen.

Was validiert wurde

Der Test wurde in einer isolierten und autorisierten Laborumgebung durchgeführt. Die Validierung umfasste folgende Abfolge:

1. Joomla 5 wurde in Docker mit installiertem SP Page Builder bereitgestellt.
2. Ein öffentliches Projekt aus den Referenzen wurde als erste Validierungsreferenz verwendet.
3. Der asset.uploadCustomIcon-Endpunkt des SP Page Builders akzeptierte hochgeladene Icon-Archive in der Laborumgebung.
4. Neue Verzeichnisse und Dateien wurden unter /media/com_sppagebuilder/assets/iconfont/ erstellt.
5. Der hochgeladene Inhalt enthielt PHP-Erweiterungen in gemischter Groß-/Kleinschreibung und eine .htaccess-Datei, die die PHP-Behandlung für die .PHP-Erweiterung änderte.
6. Das hochgeladene PHP-Artefakt wurde über HTTP aufgerufen und führte kontrollierte Befehle aus.
7. Ein einmaliger TCP-Rückruf zum Windows-Host bestätigte die ausgehende Konnektivität.
8. Ein kontrollierter Reverse-Shell-Test bestätigte die interaktive Befehlsausführung als Webserver-Benutzer.
9. Versuche, auf /root zuzugreifen und mit su - den Benutzer zu wechseln, schlugen fehl.
10. Beweise aus der Telemetrie des Opfers und Windows-Screenshots wurden in einer einzigen UTC-Zeitlinie korreliert.

Die Berichte dokumentieren absichtlich Beweise und Erkennungslogik, ohne einen wiederverwendbaren Exploit oder eine Payload-Implementierung zu verteilen.

Bestätigtes Ergebnis

Der Labortest bestätigte:

• unbefugten Upload über den asset.uploadCustomIcon-Endpunkt des SP Page Builders;
• Erstellung von PHP- und .htaccess-Artefakten unter dem Joomla-Medienverzeichnis;
• serverseitige Ausführung des hochgeladenen PHP-Artefakts nach einer HTTP-Anfrage;
• Ausführung im Kontext des Apache/PHP-Prozessbenutzers;
• ausgehende TCP-Konnektivität vom Joomla-Container zum Windows-Host;
• eine interaktive Reverse-Shell-Sitzung als www-data;
• keine bestätigte Rechteausweitung auf root.

Innerhalb des Containers lautete die effektive Identität:

uid=33(www-data) gid=33(www-data) groups=33(www-data)

Der fehlgeschlagene Rechteausweitungsversuch war sichtbar als:

cd root
bash: cd: root: Permission denied
su -
Password:
su: Authentication failure

Wichtige Beweise

Öffentliche PoC-Validierung und Upload-Verhalten

Der öffentliche PoC testete mehrere Erweiterungsvarianten und bestätigte, dass eine Kombination aus einer PHP-Erweiterung in gemischter Groß-/Kleinschreibung und .htaccess im Laboraufbau zur Ausführung führen konnte.

Codeausführung als Webserver-Benutzer

Eine kontrollierte HTTP-Anfrage führte whoami aus, und der Browser zeigte den effektiven Prozessbenutzer an.

Einmaliger TCP-Rückruf

Vor dem interaktiven Test wurde ein sichererer Einmal-Nachrichten-Rückruf verwendet, um die ausgehende Konnektivität von der Zielumgebung zum Windows-Host auf TCP-Port 4444 zu bestätigen.

Reverse-Shell-Sitzung

Die interaktive Sitzung bestätigte die Ausführung als www-data, Linux als Betriebssystem und ein Arbeitsverzeichnis unter dem Joomla-SP-Page-Builder-Medienpfad.

Fehlgeschlagener Root-Zugriffsversuch

Versuche, auf /root zuzugreifen und sich mit su - zu authentifizieren, schlugen fehl. Der Screenshot ist geschwärzt, um das Testpasswort nicht zu veröffentlichen.

Rekonstruierte Zeitlinie

Die vollständige Zeitlinie ist in beiden PDF-Berichten verfügbar. Die wichtigsten Ereignisse waren:

Methodik der Beweissammlung

Linux und Docker

Der Opfer-Host sammelte:

• auditd-Ereignisse für execve;
• Paketerfassung mit tcpdump;
• Docker-Container-Metadaten, Logs, Ereignisse, Prozessauflistungen und Dateisystemunterschiede;
• periodische Dateiänderungsabfragen aus dem Container heraus;
• Dateilistings für das Joomla-Webroot, temporäre Verzeichnisse und relevante Medienpfade;
• ausgewählten Container-Zustand vor und nach dem Test.

Der Test identifizierte auch eine Überwachungseinschränkung: Da /var/www/html durch ein Docker-Volume bereitgestellt wurde, zeigte docker diff keine detaillierten Dateierstellungen unter /var/www/html/media/com_sppagebuilder/assets/iconfont/ an. Die Dateiintegritätsüberwachung sollte daher den tatsächlichen Host-Pfad abdecken, der das Volume bereitstellt.

Windows

Die Windows-Host-Beweise wurden absichtlich auf berichtsrelevante Screenshots beschränkt:

• Ausgabe des öffentlichen PoC;
• Browserausgabe für whoami;
• Ncat-Ausgabe für den einmaligen Rückruf;
• Ncat-Ausgabe für die Reverse-Shell-Sitzung;
• fehlgeschlagener /root- und su --Versuch mit geschwärztem Passwort.

Wichtigste Erkennungsmöglichkeiten

1. Upload über SP Page Builder

Überwachen Sie HTTP-, Reverse-Proxy-, WAF- oder Netzwerktelemetrie auf folgende Kombination:

POST /index.php?option=com_sppagebuilder&task=asset.uploadCustomIcon
User-Agent enthält: sppb-rce-poc
Status: 200, 201 oder 204

Verlassen Sie sich in der Produktion nicht nur auf den User-Agent des öffentlichen PoC. Der Endpunkt und das unerwartete Upload-Muster sind stabilere Indikatoren als der User-Agent-Wert.

2. Ausführbare Datei oder .htaccess unter dem SP Page Builder Icon-Pfad

Überwachen Sie die Dateitelemetrie auf neue oder geänderte Dateien, die auf Folgendes passen:

/media/com_sppagebuilder/assets/iconfont/*/fonts/*.php
/media/com_sppagebuilder/assets/iconfont/*/fonts/*.PHP
/media/com_sppagebuilder/assets/iconfont/*/fonts/*.pHp
/media/com_sppagebuilder/assets/iconfont/*/fonts/*.Php
/media/com_sppagebuilder/assets/iconfont/*/fonts/.htaccess

Das Vorhandensein einer .htaccess-Datei, die AddType application/x-httpd-php .PHP in einem Medien-Upload-Verzeichnis enthält, ist ein hochwertiger Indikator.

3. GET-Anfrage an eine hochgeladene PHP-Datei mit Befehlsparametern

Korrelieren Sie Upload-Aktivitäten mit nachfolgenden HTTP-Anfragen an Pfade wie:

/media/com_sppagebuilder/assets/iconfont/*/fonts/*

Eine höhere Sicherheit wird erreicht, wenn die Anfrage auf eine PHP-ähnliche Erweiterung abzielt und Parameter wie t= und c= enthält.

4. Shell- oder Interpreter-Aktivität vom Webdienstkonto

Hochwertige Prozessindikatoren umfassen:

user: www-data, apache oder nginx
process: bash, sh, dash oder php
Befehlszeile enthält: /dev/tcp, bash -i, Umleitungsoperatoren oder ungewöhnliche Interpreter-Ausführung

5. Ausgehende Verbindung vom Web-Container

Alarmieren Sie, wenn eine Shell oder ein Interpreter, der vom Webserver-Prozess gestartet wurde, eine ausgehende Verbindung zu einer Workstation oder einem ungewöhnlichen Zielport initiiert. Das Laborereignis verwendete TCP-Port 4444, aber die Erkennung in der Produktion sollte sich nicht auf einen einzelnen Port verlassen.

6. Fehlgeschlagene Rechteausweitungsversuche nach Web-Ausführung

Der Test erzeugte einen fehlgeschlagenen su --Versuch. Überwachen Sie auf Authentifizierungshelfer wie unix_chkpwd, Schreibvorgänge in /var/log/btmp und interaktive Befehle nach einer Kompromittierung des Webdienstkontos.

SOC-Triage-Anleitung

Wenn der HTTP-Upload-Indikator erkannt wird, sollte das SOC sofort Folgendes korrelieren:

• die Quell-IP, den User-Agent und den HTTP-Status;
• ob die betroffene Joomla-Instanz SP Page Builder installiert hat und ob die Version anfällig ist;
• neue Verzeichnisse unter /media/com_sppagebuilder/assets/iconfont/;
• neue PHP-ähnliche Dateien oder .htaccess-Dateien unter Joomla-Medienverzeichnissen;
• HTTP-GET-Anfragen an die neu erstellten Dateien kurz nach dem Upload;
• befehlsähnliche Abfrageparameter wie t= und c=;
• Prozesserstellung durch den Webserver-Benutzer, insbesondere Shell- oder Interpreter-Prozesse;
• ausgehende Verbindungen vom Web-Container oder Webdienstkonto;
• Erkennungsbefehle wie whoami, id, uname, hostname, pwd, ip, ifconfig, netstat oder ;

Ein einzelnes Upload-Ereignis ist allein nicht immer ausreichend. Der stärkste Alarm kombiniert Upload, Dateierstellung, Dateizugriff, Prozessausführung und Netzwerktelemetrie innerhalb desselben kurzen Zeitfensters.

Empfohlene Gegenmaßnahmen

1. Aktualisieren Sie SP Page Builder auf Version 6.6.2 oder neuer.
2. Überprüfen Sie /media/com_sppagebuilder/assets/iconfont/ und das gesamte Joomla-Medienverzeichnis auf PHP-ähnliche Dateien und .htaccess-Artefakte.
3. Entfernen Sie alle unerwarteten PHP-, .htaccess-, .phtml-, .phar-, Archiv- oder ausführbaren Artefakte aus Upload-Verzeichnissen.
4. Deaktivieren Sie die PHP-Ausführung in Upload- und Medienverzeichnissen auf der Apache-, Nginx- und PHP-FPM-Ebene.
5. Beschränken Sie den Zugriff auf den asset.uploadCustomIcon-Endpunkt aus nicht vertrauenswürdigen Netzwerken oder lösen Sie einen Alarm aus.
6. Überwachen Sie die untergeordneten Prozesse des Webdienstes und ausgehende Verbindungen aus Web-Containern.
7. Setzen Sie FIM, eBPF, auditd oder EDR-Abdeckung für Docker-Volumes ein, die das Anwendungs-Webroot enthalten.
8. Verlassen Sie sich nicht allein auf docker diff für die Webroot-Überwachung, wenn Anwendungsdaten in Docker-Volumes oder Bind-Mounts gespeichert werden.

Umfang und Einschränkungen

• Die Validierung wurde gegen eine einzelne Joomla 5 Docker-Instanz mit installiertem SP Page Builder durchgeführt.
• Die beobachtete Auswirkung war die Codeausführung als Prozessbenutzer des Webservers www-data; eine Rechteausweitung auf root wurde nicht bestätigt.
• Das Ergebnis bestätigt den getesteten Pfad und die Konfiguration. Es beweist nicht, dass jede Bereitstellung, jeder Reverse-Proxy, jeder Webserver, jeder PHP-Handler oder jedes Betriebssystem identisch reagiert.
• Angriffs-Exploit-Code, Payload-Quellen, rohe PCAP-Dateien, rohe Docker-Beweispakete und DOCX-Quelldateien werden in diesem Repository nicht verteilt.
• Die Berichte enthalten ausgewählte Beweisauszüge und keine vollständigen Rohdatenlogs, um das Material lesbar und auf die Erkennung fokussiert zu halten.

Referenzen

• NVD - CVE-2026-48908
• CVE.org - CVE-2026-48908
• Katalog bekannter ausgenutzter Schwachstellen von CISA
• Öffentliches Projekt, das als erste Validierungsreferenz verwendet wurde
• JoomShaper SP Page Builder

Hinweis zur verantwortungsvollen Nutzung

Dieses Material wird für defensive Sicherheitsforschung, Schwachstellenmanagement, Erkennungsentwicklung, Incident-Response-Vorbereitung und autorisierte Tests bereitgestellt. Verwenden Sie es nicht gegen Systeme ohne ausdrückliche Genehmigung.