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

Rolle	System
Opfer-Host	Ubuntu 24.04.4 LTS, Kernel 6.17.0-35-generic, Docker Engine 29.5.3
Zielanwendung	Joomla 5.4.7, PHP 8.3.32, Apache HTTP Server, Image joomla:5-php8.3-apache
Komponente	JoomShaper SP Page Builder
Container	joomla5-builders
Angreifer-Workstation	Microsoft Windows 11 Home 10.0.26200
Joomla-Dienst	http://172.20.10.3:8080
Windows-Testadresse	172.20.10.2
Container-Adresse	172.21.0.3
Testdatum	9. Juli 2026

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: