CVE-2026-48908 – SP Page Builder (Joomla) Nicht authentifizierte RCE

Proof-of-concept-Exploit für CVE-2026-48908, eine kritische (CVSS 4.0 = 10.0) nicht authentifizierte Remote-Code-Ausführungsschwachstelle in der SP Page Builder-Komponente (com_sppagebuilder) für Joomla, von JoomShaper.

Beschreibung

SP Page Builder stellt die Controller-Aufgabe asset.uploadCustomIcon zum Hochladen eines benutzerdefinierten Icon‑Font‑Pakets bereit:

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

In betroffenen Versionen ist diese Aufgabe ohne Authentifizierung und ohne gültiges Anti‑CSRF‑Token erreichbar. Sie akzeptiert ein ZIP‑Archiv (Multipart‑Feld custom_icon) und extrahiert dessen Inhalt in ein öffentlich über das Web zugängliches Verzeichnis unter dem Dokumentenroot:

/media/com_sppagebuilder/assets/iconfont/<name>/   (einschließlich fonts/‑Unterordner)

Da der Upload vor der Authentifizierung erreichbar ist und die extrahierten Dateien im Web‑Root landen, kann ein Angreifer vom Angreifer kontrollierte Dateien an einen durchsuchbaren Ort schreiben und über HTTP darauf zugreifen.

Codeausführung trotz des Erweiterungsfilters erreichen

Einige Builds fügen einen serverseitigen Dateinamen‑Filter für die Archiveinträge hinzu. Dieser PoC umgeht eine gängige Implementierung mit einer dreistufigen Kette:

1. Groß‑/Kleinschreibung‑sensitive Blocklist. Der Filter lehnt Kleinbuchstaben .php, .phtml, .phar, .php3–.php8, .pht, .inc, … ab, normalisiert jedoch nicht die Groß‑/Kleinschreibung, sodass .PHP (und andere gemischte Schreibweisen) sowie .htaccess durchgelassen werden.
2. Groß‑/Kleinschreibung‑sensitive Webserver‑Handler. Ein standardmäßiger Apache‑PHP‑Handler (<FilesMatch "\.php$">) führt nur Kleinbuchstaben .php aus, sodass ein hochgeladenes .PHP zunächst als Quelltext, nicht als ausführbarer Code, ausgeliefert wird.
3. .htaccess‑Override. Eine (die die Blockliste ebenfalls übersieht), die enthält, wird neben der Nutzlast abgelegt. Wo dies erlaubt, registriert dies als PHP und die hochgeladene Shell .

Der PoC verpackt immer eine gültige Icon‑Font‑Struktur (selection.json, style.css, fonts/<name>.ttf), damit der Upload akzeptiert wird, und fügt dann die Shell hinzu.

Adaptiv – er durchläuft eine Liste von PHP‑ausführbaren Erweiterungen (geringste Größe zuerst), dann einen .htaccess‑Fallback, und stoppt bei der ersten, die tatsächlich Code ausführt:

1. Direkte Einzeldatei‑Uploads — fonts/<shell>.<ext> für jede der Erweiterungen php, php3, php4, php5, php7, pht, phtml, phar, PHP, pHp, Php. Keine .htaccess. Unterschiedliche SP Page Builder‑Filter blockieren unterschiedliche Mengen, und unterschiedliche Apache‑Konfigurationen führen unterschiedliche Erweiterungen aus – daher findet dies jede Kombination, die das Ziel zulässt und ausführt.
2. fonts/.htaccess + fonts/<shell>.PHP (Fallback) — nur wenn jeder direkte Versuch fehlschlägt. Die abgelegte .htaccess (AddType … .PHP) erzwingt die Ausführung eines großgeschriebenen .PHP, wo AllowOverride dies erlaubt (das ist, was 5.4.6‑ähnliche Hosts benötigen).

Es stoppt bei der ersten Methode, die ausgeführt wird, und gibt aus, welche erfolgreich war. Jeder akzeptierte Upload wird nachverfolgt, sodass --cleanup alle entfernt (mehrere Versuche können schreibgeschützte Verzeichnisse hinterlassen).

Je nach Version und Serverhärtung variiert das Ergebnis, und der PoC gibt es explizit an (siehe Ergebnisse unten): vollständige RCE, nur Dateischreiben (PHP deaktiviert / AllowOverride None), gepatcht (nur Admin), oder nicht verwundbar.

Voraussetzungen

pip install -r requirements.txt   # requests

Verwendung

# Schwachstelle bestätigen und Codeausführung nachweisen (führt `id` aus)
python3 sppb_rce.py https://ziel.example

# Einen bestimmten Befehl ausführen
python3 sppb_rce.py --url ziel.example -c "uname -a"

# Interaktive Pseudo‑Shell
python3 sppb_rce.py https://ziel.example --shell

# Nur überprüfen; keinen Befehl ausführen
python3 sppb_rce.py https://ziel.example --check

# Das hochgeladene Nutzlastverzeichnis danach entfernen
python3 sppb_rce.py https://ziel.example --cleanup

Das Ziel kann als Positionsargument oder über --url angegeben werden, mit oder ohne Schema.

Beispiel (bereinigt)

[*] target   : https://ziel.example
[*] endpoint : index.php?option=com_sppagebuilder&task=asset.uploadCustomIcon
[*] try .php            -> rejected by filter
[*] try .php3           -> rejected by filter
...
[*] try .PHP            -> uploaded, not executed
[*] try .htaccess+.PHP  -> EXECUTED
[+] CODE EXECUTION CONFIRMED via '.htaccess+.PHP' (echo 7*6 -> 42)
[*] running: id
------------------------------------------------------------
uid=33(www-data) gid=33(www-data) groups=33(www-data)
------------------------------------------------------------
[*] cleanup: done (4 dirs)

Ergebnisse (und Exit‑Codes)

Der PoC teilt immer das Urteil über das Ziel mit:

Sicherheitsfunktionen

• Die abgelegte Web‑Shell ist durch ein zufälliges, pro Durchlauf erzeugtes Token geschützt und gibt 404 zurück, wenn jemand ohne dieses Token zugreift – es ist keine vollständig offene Hintertür.
• --cleanup löscht das erstellte Nutzlastverzeichnis.
• Standardaktionen sind harmlos (id, ein arithmetischer Marker).

Behebung

1. SP Page Builder auf 6.6.2 oder neuer aktualisieren (fügt Authentifizierungs‑, Autorisierungs‑ und CSRF‑Prüfungen zur Upload‑Aufgabe hinzu). Dies ist die primäre Behebung.
2. Defense‑in‑Depth auf dem Webserver:
   • PHP‑Ausführung in Upload‑Verzeichnissen deaktivieren (/media/, /images/, /tmp) über den FPM‑Pool oder php_admin_flag engine off.
   • Setzen Sie AllowOverride None auf diesen Verzeichnissen, sodass eine abgelegte .htaccess keine Handler wieder aktivieren kann.
   • Verwenden Sie eine groß‑/kleinschreibungsunabhängige Erlaubnisliste für Upload‑Erweiterungen, niemals eine Blocklist.
3. Angriffsannahme‑Überprüfung: Suchen Sie nach unerwarteten .php/.PHP unter media/.../iconfont/, neuen Super‑User‑Konten und platzierten Dateimanagern.

Referenzen

• NVD — CVE-2026-48908
• CVE.org record — CVE-2026-48908
• Technischer Bericht — SP Page Builder uploadCustomIcon RCE (mySites.guru)
• Hersteller — JoomShaper SP Page Builder (Sicherheitsfix in 6.6.2)
• SP Page Builder — Joomla Erweiterungsverzeichnis

Schlüsselwörter

Joomla SP Page Builder Exploit · com_sppagebuilder unauthenticated RCE · CVE-2026-48908 PoC · asset.uploadCustomIcon willkürlicher Dateiupload · Joomla Remote‑Code‑Ausführung · Pentest‑Exploit‑Skript

HAFTUNGSAUSSCHLUSS

Diese Software wird nur zu Bildungszwecken und für autorisierte Sicherheitstests veröffentlicht – z. B. Penetrationstests, für die Sie schriftliche Genehmigung haben, Bug‑Bounty‑Programme, die das Ziel in ihrem Geltungsbereich enthalten, CTF‑Wettbewerbe und eigene Laborsysteme.

Der Zugriff, die Änderung oder Störung von Computersystemen ohne Autorisierung ist in den meisten Jurisdiktionen illegal. Sie sind allein und vollständig für Ihre eigenen Handlungen verantwortlich. Durch die Nutzung, das Herunterladen oder die Verbreitung dieses Codes stimmen Sie zu, dass:

• Sie ihn nur gegen Systeme einsetzen werden, die Sie besitzen oder für die Sie ausdrückliche, dokumentierte Genehmigung zum Testen haben;
• die Autoren und Mitwirkenden keine Haftung für Schäden, Datenverlust, Dienstunterbrechungen oder rechtliche Konsequenzen übernehmen, die aus der Nutzung oder dem Missbrauch dieses Codes entstehen;
• dieses Material "WIE BESEHEN", ohne jegliche Gewährleistung, ausdrücklich oder stillschweigend, bereitgestellt wird.

Wenn Sie diesen Bedingungen nicht zustimmen, verwenden Sie diese Software nicht. Wie bei jedem öffentlich verfügbaren Exploit/PoC wird er in gutem Glauben geteilt, um Verteidigern zu helfen, die Schwachstelle zu erkennen, zu verstehen und zu beheben; was Sie damit tun, liegt in Ihrer Verantwortung.

Lizenz

MIT – siehe LICENSE.