SP Page Builder: Kritische RCE-Lücke (CVE-2026-48908) aktiv ausgenutzt

Veröffentlicht am 05.08.2026

Ein einziger unauthentifizierter HTTP-Request genügt, um die vollständige Kontrolle über einen Joomla-Server zu erlangen. Genau das ermöglicht die Schwachstelle CVE-2026-48908 im weit verbreiteten JoomShaper SP Page Builder – und Angreifer nutzen sie gerade jetzt aktiv aus. Am 2. August 2026 wurden erneut Angriffe beobachtet, obwohl bereits seit Wochen ein Sicherheitsupdate zur Verfügung steht. Wer den SP Page Builder auf seiner Joomla-Website einsetzt und noch nicht aktualisiert hat, sollte diesen Artikel bis zum Ende lesen und danach unverzüglich handeln.

Was ist passiert?

Der SP Page Builder von JoomShaper ist eine der meistgenutzten Erweiterungen für das Content-Management-System Joomla – also die Software, mit der viele Websites erstellt und verwaltet werden. Mit über 13,6 Millionen Downloads durch mehr als 790.000 Nutzer weltweit gehört er zu den populärsten Baukasten-Werkzeugen für Joomla-Seiten. Laut Watchful.net ist der SP Page Builder auf rund 21 % aller professionell verwalteten Joomla-Websites installiert.

In dieser Erweiterung wurde eine Schwachstelle entdeckt, die als denkbar schwerwiegend eingestuft wird: Sie erhielt den maximal möglichen CVSS-4.0-Score von 10.0 (CVSS ist die international genutzte Skala zur Bewertung der Gefährlichkeit von Sicherheitslücken, von 0 bis 10). Der Fehler erlaubt es Angreifern, ohne jede Anmeldung beliebige Dateien – insbesondere ausführbaren PHP-Code – auf den Server hochzuladen und dort auszuführen. In der Fachsprache heißt das „unauthentifizierte Remote Code Execution" (RCE): Codeausführung aus der Ferne ohne Login.

Die US-amerikanische Cybersicherheitsbehörde CISA hat CVE-2026-48908 am 7. Juli 2026 in ihren Known Exploited Vulnerabilities Catalog (KEV) aufgenommen – eine Liste nachweislich aktiv ausgenutzter Schwachstellen. Die Frist für US-Bundesbehörden zum Einspielen des Patches lief bereits am 10. Juli 2026 ab. Der Eintrag ist inzwischen als „überfällig" (OVERDUE) markiert. Die CISA beschreibt die Lücke so:

„JoomShaper SP Page Builder contains an unrestricted upload of file with dangerous type vulnerability that allows unauthenticated users to upload arbitrary files, ultimately resulting in the upload and execution of PHP code. […] This type of vulnerability is a frequent attack vector for malicious cyber actors and poses significant risks." – CISA

Der technische Hintergrund – verständlich erklärt

Der Schwachpunkt liegt in einem bestimmten Endpunkt der Erweiterung, also einer Adresse, die der Server auf Anfrage verarbeitet: index.php?option=com_sppagebuilder&task=asset.uploadCustomIcon. Ursprünglich war dieser Endpunkt dafür gedacht, benutzerdefinierte Icon-Pakete (kleine Symbolgrafiken) als ZIP-Datei hochzuladen.

Das Problem: Der zuständige Programmteil führte vor der Verarbeitung des Uploads keinerlei Zugriffsprüfung durch und kontrollierte auch nicht, welcher Dateityp hochgeladen wird. Fachlich handelt es sich um einen sogenannten CWE-434-Fehler – das unbeschränkte Hochladen gefährlicher Dateitypen. Joomla stellt eigene Schutzfunktionen bereit, die Uploads gegen eine Liste erlaubter, sicherer Dateiendungen prüfen. Dieser Upload-Pfad nutzte sie schlicht nicht.

Der Angriff läuft in wenigen Schritten ab:

1. Der Angreifer sendet eine präparierte Datei (etwa eine PHP-Datei) an den Endpunkt – ohne Login, ohne Sicherheitstoken.
2. Die Datei landet in einem über das Web erreichbaren Verzeichnis.
3. Der Angreifer ruft die hochgeladene Datei einfach über den Browser auf – und der Server führt den enthaltenen Schadcode aus.
4. Der Schadcode liest die Konfigurationsdatei aus, legt versteckte Administrator-Konten an und platziert Hintertüren.

Besonders perfide: Die automatisierten Angriffe legen versteckte Joomla-Super-Administrator-Konten an – erkennbar an E-Mail-Adressen, die auf @secure.local enden. Zusätzlich werden PHP-Hintertüren (sogenannte Webshells, konkret ein „PHP File Manager v1.4") in mehreren Verzeichnissen gleichzeitig abgelegt, etwa unter /images/<zufälliger Ordner>/fonts/ und /media/com_admin/. Das Sicherheitsforschungsteam von mysites.guru erklärt den Grund für diese Mehrfach-Ablage:

„Der Angreifer erhält nicht nur eine einmalige Codeausführung […]. Zuerst erstellt er versteckte Super-Administrator-Konten. Zweitens hinterlässt er eine PHP-File-Manager-Hintertür. Der Sinn der verstreuten, identischen Kopien ist Beständigkeit: Wenn Sie eine finden und löschen, sind die anderen noch da – und sie alle lassen den Angreifer direkt wieder herein." – mysites.guru

Wichtiger Hinweis für alle, die sich auf eine Firewall verlassen: Eine Web Application Firewall (WAF), die nur bekannte andere Joomla-Exploits blockiert, schützt hier nicht automatisch. Zudem lässt sich der Punkt im Task-Namen (asset.uploadCustomIcon) URL-kodiert als asset%2euploadCustomIcon übermitteln – naive Filterregeln müssen beide Varianten berücksichtigen.

Wer ist betroffen?

Betroffen sind alle Versionen des SP Page Builder von 1.0.0 bis einschließlich 6.6.1. JoomShaper veröffentlichte am 20. Juni 2026 den Fix in Version 6.6.2. Am 27. Juli 2026 folgte Version 6.7.1, die vier weitere kritische Schwachstellen behebt (CVE-2026-65766, CVE-2026-65877, CVE-2026-65878, CVE-2026-65879) – darunter eine unauthentifizierte SQL-Injection mit einem CVSS-Wert von 9.2.

Für deutsche KMU ist die Lage besonders relevant: Deutschland führt laut TechnologyChecker.io die weltweite Joomla-Nutzung mit rund 17 % an (etwa 11.600 Unternehmen). Und 85 % der Joomla-Nutzer sind Kleinstunternehmen mit bis zu zehn Mitarbeitern – also genau jene Betriebe, die selten ein dediziertes IT-Sicherheitsteam haben.

Das Angriffsvolumen ist enorm. FortiGuard Labs (Fortinet) verzeichnete zum Zeitpunkt des Outbreak-Alerts am 17. Juli 2026:

„FortiGuard Labs beobachtet weiterhin die aktive Ausnutzung von CVE-2026-48908 […]. Zum Zeitpunkt der Veröffentlichung registrierte die FortiGuard-Telemetrie 1.210 blockierte Ausnutzungsversuche in den letzten 24 Stunden und 15.626 Versuche in den letzten 7 Tagen. Die höchsten Angriffsvolumina zielten auf Organisationen in Polen, der Türkei, Australien und den USA." – FortiGuard Labs

So prüfen Sie, ob Sie betroffen sind

1. Version prüfen: Im Joomla-Adminbereich unter Erweiterungen → Verwalten die installierte Version des SP Page Builder (com_sppagebuilder) ablesen. Version 6.6.1 oder älter bedeutet: dringender Handlungsbedarf.
2. Verdächtige Admin-Konten suchen: Unter Benutzer → Verwalten die Super-Administratoren aufrufen. Konten mit E-Mail-Adressen, die auf @secure.local enden, wurden mit hoher Wahrscheinlichkeit durch diesen Exploit angelegt und müssen sofort gelöscht werden.
3. Dateisystem durchsuchen: Auf dem Server nach PHP-Dateien in /images/, /media/ und /tmp/ suchen, die dort nicht hingehören. Besonders verdächtig: Dateien unter /media/com_sppagebuilder/assets/iconfont/, Dateien namens users.php in /media/com_admin/ oder /media/regularlabs/ sowie PHP-Dateien unter /images/<zufälliger Ordner>/fonts/. Enthält eine Datei den Text „PHP File manager", handelt es sich um eine Hintertür.
4. Server-Logs analysieren: In den Zugriffsprotokollen von Apache, Nginx oder LiteSpeed nach POST-Anfragen mit dem String task=asset.uploadCustomIcon suchen. Einträge von unbekannten IP-Adressen deuten auf Angriffsversuche hin.
5. Erweiterungen prüfen: Unter Erweiterungen → Verwalten → Installierte Erweiterungen auf unbekannte oder kürzlich installierte Templates und Plugins achten.
6. Datenbank kontrollieren: In den Tabellen #__users und #__user_usergroup_map nach Super-User-Einträgen suchen, die nicht vom legitimen Administrator stammen – insbesondere mit @secure.local-Adressen.

Das müssen Sie jetzt tun

Wichtig vorab: Das Update schließt nur die Einfallstür. Bereits kompromittierte Systeme müssen zusätzlich bereinigt werden – ein reines Update entfernt vorhandene Hintertüren und Rogue-Admins nicht.

1. Sofort aktualisieren: SP Page Builder auf Version 6.7.1 oder höher bringen (Erweiterungen → Verwalten → Aktualisieren oder manuell von joomshaper.com). Das schließt CVE-2026-48908 und die Folgeschwachstellen.
2. Kompromittierung prüfen: Auch nach dem Update alle oben genannten Prüfschritte durchführen.
3. Rogue-Admins löschen: Alle Super-Administrator-Konten mit @secure.local-Adressen und alle anderen unbekannten Admin-Konten sofort entfernen.
4. Webshells entfernen: Alle gefundenen fremden PHP-Dateien löschen. Da mehrere identische Kopien typisch sind, müssen wirklich alle gefunden werden.
5. Passwörter rotieren: Alle Joomla-Admin-Passwörter ändern, das Datenbankpasswort in configuration.php aktualisieren, FTP-/SSH-Zugänge und das Hosting-Panel-Passwort wechseln.
6. PHP-Ausführung sperren: In /images/ und /media/ die PHP-Ausführung deaktivieren (z. B. via .htaccess mit php_flag engine off oder entsprechenden Nginx-location-Blöcken). So werden hochgeladene Webshells unwirksam.
7. WAF-Regeln ergänzen: Falls ein sofortiges Update nicht möglich ist, Regeln für POST-Anfragen an asset.uploadCustomIcon (inklusive der kodierten Variante asset%2euploadCustomIcon) einrichten.
8. Alle Sessions beenden: In Joomla über Tools → Globaler Check-In oder eine Bereinigung der #__session-Tabelle alle aktiven Sitzungen invalidieren.
9. Vollständiges Audit: Bei Verdacht auf erfolgreiche Kompromittierung einen kompletten Malware-Scan (z. B. Imunify360) durchführen, ein sauberes Backup vor dem Angriffszeitraum einspielen oder die Site komplett neu aufsetzen.
10. Monitoring einrichten: Dateiintegritätsüberwachung für den Webroot aktivieren und Logs regelmäßig auf Angriffsmuster kontrollieren.

Das Sicherheitsforschungsteam von mysites.guru bringt die Dringlichkeit auf den Punkt:

„Dies wird gerade aktiv ausgenutzt. Der Fix existiert, und die technischen Details gehen an die Öffentlichkeit – was bedeutet, dass mehr Scanner genau wissen, wonach sie suchen müssen. Erwischt werden die Seiten, die dann noch auf einer alten Version laufen. Aktualisieren Sie zuerst […], dann prüfen Sie, ob Sie bereits getroffen wurden." – mysites.guru

DSGVO-Einordnung: Was Sie rechtlich beachten müssen

Ein erfolgreicher Angriff über diese Lücke ist in aller Regel eine meldepflichtige Datenpanne nach Art. 33 DSGVO. Denn der Angreifer erhält vollen Zugriff auf Server und Datenbank – einschließlich aller dort gespeicherten personenbezogenen Daten wie Kundendaten, Kontaktformular-Einträge, Benutzerkonten und Passwort-Hashes.

Sobald eine solche Verletzung bekannt wird, muss der Verantwortliche unverzüglich und möglichst binnen 72 Stunden die zuständige Datenschutzaufsichtsbehörde informieren (Art. 33 Abs. 1 DSGVO). Besteht ein hohes Risiko für die Betroffenen, sind diese zusätzlich zu benachrichtigen (Art. 34 DSGVO). Zuständig ist in Deutschland die jeweilige Landesdatenschutzbehörde, die Meldung erfolgt in der Regel über deren Online-Portal.

Die Haftungsrisiken sind erheblich: Verstöße gegen Art. 32 DSGVO (unzureichende technische Sicherheitsmaßnahmen, etwa unterlassenes Patchen bekannter Schwachstellen) können mit Bußgeldern bis zu 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes geahndet werden. Aufsichtsbehörden haben in vergleichbaren Fällen Bußgelder verhängt, wenn verfügbare Sicherheitsupdates nicht zeitnah eingespielt wurden. Das BSI empfiehlt als Mindestmaßnahme, bekannte Schwachstellen mit verfügbarem Patch innerhalb weniger Tage zu beheben. Unabhängig von der Meldepflicht besteht zudem eine Dokumentationspflicht (Art. 33 Abs. 5 DSGVO).

Was der Fall über die Kosten verrät

Wie teuer ein solcher Vorfall werden kann, zeigt die Schilderung der betroffenen Agentur AGON PARTNERS INNOVATION AG im JoomShaper-Forum:

„Aber allein bei den aktuellen Kunden lagen unsere internen Kosten zur Behebung bei über 20.000. […] Aber wenn der Schaden angerichtet ist, dauert die Bereinigung länger. Alle Passwörter aller Dienste ändern, eine neue OWASP-Regel einrichten, mehr Proxyserver aufsetzen." – AGON PARTNERS INNOVATION AG

ChronoEngine, ein weiterer Joomla-Erweiterungsentwickler, ordnet die Tragweite so ein:

„Anders als einfache Startseiten-Verunstaltungen gewährt dieser Exploit unauthentifizierten Angreifern die totale Kontrolle über Ihr Server-Backend – sie können Daten stehlen, dauerhafte Hintertüren einpflanzen und Schadskripte ausführen." – ChronoEngine

Fazit

CVE-2026-48908 ist keine theoretische Gefahr, sondern eine seit Wochen aktiv ausgenutzte Schwachstelle mit dem maximal möglichen Gefährdungswert von 10.0. Die Einstiegshürde für Angreifer ist minimal – kein Login, keine Spezialkenntnisse, öffentlich verfügbare Angriffswerkzeuge. Automatisierte Botnets scannen das Internet permanent nach verwundbaren Joomla-Seiten ab, und noch am 2. August 2026 wurden weitere Angriffe beobachtet.

Wenn Sie den SP Page Builder einsetzen, gibt es nur eine sinnvolle Reihenfolge: Erst aktualisieren, dann prüfen, ob Sie bereits kompromittiert wurden. Bringen Sie die Erweiterung auf mindestens Version 6.7.1, arbeiten Sie anschließend die Prüf- und Bereinigungsschritte konsequent ab – und dokumentieren Sie alles. Denn ein reines Update genügt nicht: Wer zwischen dem Bekanntwerden der Lücke und dem Patch exponiert war, könnte bereits eine Hintertür auf dem Server haben, die geduldig auf ihre nächste Nutzung wartet. Handeln Sie jetzt.