SP Page Builder Sicherheitslücke: Joomla jetzt auf 6.6.2 updaten

Für den weit verbreiteten Joomla-Seitenbaukasten SP Page Builder (von JoomShaper) gibt es ein Notfall-Update auf Version 6.6.2. Es schließt eine kritische Zero-Day-Lücke, über die ein nicht angemeldeter Angreifer eine Schad-Datei auf den Server laden und ausführen kann - also die volle Kontrolle über deine Seite übernimmt. Diese SP Page Builder Sicherheitslücke wird bereits aktiv ausgenutzt.

Das Tückische an diesem Angriff: Er hinterlässt versteckte Administrator-Konten und mehrere Hintertüren, die auch nach dem Update noch offen sind. Ein reines Aktualisieren reicht deshalb nicht - du musst zusätzlich prüfen, ob deine Seite bereits getroffen wurde. Und handeln solltest du jetzt: Die technischen Details werden in Kürze öffentlich, und sobald das passiert, scannen automatisierte Bots gezielt nach veralteten Installationen.

Was ist SP Page Builder - und wer ist betroffen?

SP Page Builder ist einer der meistgenutzten Page Builder für Joomla: eine Komponente (com_sppagebuilder), mit der sich Seiten per Drag-and-drop zusammenbauen lassen. Gerade weil sie auf so vielen Seiten läuft, ist diese Joomla Sicherheitslücke so brisant.

Betroffen ist die gesamte 6.x-Reihe bis einschließlich 6.6.1. Behoben ist das Problem erst in 6.6.2. Dabei reicht es aus, dass die Komponente installiert ist - es muss keine einzige damit gebaute Seite veröffentlicht sein. Auch die Komponente nur zu deaktivieren schützt nicht, weil der verwundbare Endpunkt trotzdem erreichbar bleibt.

So prüfst du deine installierte Version:

1. Im Joomla-Backend anmelden
2. Zu Erweiterungen - Verwalten gehen
3. Nach SP Page Builder filtern und die Versionsnummer kontrollieren

Steht dort eine 6.x-Version unter 6.6.2, besteht akuter Handlungsbedarf.

Die Lücke in einfachen Worten

SP Page Builder besitzt eine interne Funktion, die eigentlich nur eine kleine Verwaltungsaufgabe erledigen soll: das Hochladen eines eigenen Icons (der Task asset.uploadCustomIcon). Das Problem: Diese Funktion prüfte weder, ob der Aufrufer angemeldet ist, noch welcher Dateityp hochgeladen wird - und legte die Datei anschließend in einem über das Web erreichbaren Ordner ab.

Damit stand die Tür offen: Ein Angreifer ganz ohne Login konnte eine PHP-Datei hochladen, sie im Browser aufrufen - und der Server führte sie aus. In der Fachsprache ist das eine Remote Code Execution (RCE) auf Basis eines unauthentifizierten Datei-Uploads: die gefährlichste Klasse von Web-Lücken überhaupt, weil der Angreifer danach praktisch alles tun kann.

Version 6.6.2 schließt das, indem vor dieser Funktion nun eine echte Prüfung steht: angemeldeter Nutzer mit ausreichenden Rechten plus gültiges Sicherheits-Token (CSRF). Anonyme Anfragen werden abgewiesen. (Bestätigt im Vergleich des Quellcodes vor und nach dem Patch.)

Das eigentlich Perfide: was zurückbleibt

Bei dieser Lücke ist die Code-Ausführung nicht das Ende, sondern der Anfang. Der Schadcode nutzt den einmaligen Zugriff, um sich dauerhaft einzunisten:

• Er legt versteckte Super-User an - mit harmlos klingenden Namen wie "Web Editor" oder "Admin Backup". Das verräterische Merkmal: Die E-Mail-Adresse endet auf @secure.local. Diese Domain ist frei erfunden, kein echtes Joomla-Konto nutzt sie. Findest du auch nur einen Super-User mit dieser Adresse, ist die Seite kompromittiert.
• Er legt eine PHP-Hintertür (einen Dateimanager mit eingebauter PHP- und SQL-Konsole) gleich an mehreren Stellen ab - typischerweise eine .php-Datei unter images/.../fonts/ sowie Kopien namens users.php in Ordnern wie /media/com_admin/ oder /media/regularlabs/. Die mehrfache Ablage ist Absicht: Löschst du eine, bleiben die anderen.

Deshalb gilt: Das Update schließt die Eingangstür - den bereits eingerichteten Zugang räumt es nicht weg.

Wurde meine Seite schon angegriffen?

Weil die Lücke ohne Login ausnutzbar ist und deutliche Spuren hinterlässt, kannst du gezielt nachsehen:

• Benutzerliste: Super-User, die du nicht selbst angelegt hast - vor allem mit der Endung @secure.local. Oft tauchen gleich mehrere auf einmal auf.
• Dateien: fremde .php-Dateien unter images/.../fonts/ sowie users.php in /media/com_admin/ und /media/regularlabs/; im Inhalt steht "PHP File manager". Suche weiter, auch wenn du eine gefunden hast - es liegen meist mehrere identische Kopien herum.

Tipp fürs Log-Lesen: Joomla speichert den Anlagezeitpunkt eines Kontos in der Zeitzone der Seite (aus der configuration.php), deine Server-Logs laufen aber meist in UTC. Rechne die Zeiten um, bevor du im Log suchst - sonst durchforstest du das falsche Zeitfenster und hältst ein verseuchtes Log für sauber.

Findest du etwas, behandle die Seite als kompromittiert: alle Fremd-Admins löschen, jede Backdoor-Kopie entfernen, anschließend Joomla-Passwörter, Datenbank-Zugang und FTP/SSH-Schlüssel wechseln, alle Sessions beenden und die gesamte Seite prüfen - nicht nur SP Page Builder. Und ein unauffälliger Befund ist keine Entwarnung, sondern schließt nur genau dieses eine Angriffsmuster aus.

Unsicher, ob deine Joomla-Seite betroffen ist oder bereits einen Fremd-Admin trägt? Wir prüfen und bereinigen das für dich - die ganze Seite, nicht nur die eine Komponente. Sieh dir auch unsere Soforthilfe bei gehackten Joomla-Seiten an.

Fazit

Die SP Page Builder Sicherheitslücke ist kritisch und wird aktiv ausgenutzt - der Fix liegt mit 6.6.2 aber bereit. Die Reihenfolge ist klar: heute auf SP Page Builder 6.6.2 aktualisieren, danach Benutzerliste und Dateien auf die beschriebenen Spuren prüfen. Server-Härtung und Monitoring kommen danach und ersetzen das Update nicht.

Quelle: offizielle Patch-Veröffentlichung des Entwicklers JoomShaper auf joomshaper.com.

• Weiter