Ende Juni 2026 kam ein weiteres schwerwiegendes Sicherheitsproblem im Joomla-Ökosystem ans Licht – diesmal nicht im JCE-Editor, sondern im JoomShaper **Helix3-Template-Framework. Die Geschichte ist auch insofern aufschlussreich, wie die Schwachstelle ans Licht kam: Bei der Untersuchung einer gehackten Kundenwebsite stießen die Forscher auf den eigentlichen Angriffspunkt und meldeten diesen anschließend auf privatem Wege dem Hersteller. Der Patch wurde am 29. Juni 2026 in der Version **Helix3 3.1.1 veröffentlicht – doch im eigenen Änderungsprotokoll des Herstellers stand lediglich: „Security Update“, mehr nicht.

Es ist wichtig zu klären: Helix3 ist ein älteres, aber nach wie vor weit verbreitetes JoomShaper-Template-Framework und nicht mit dem neueren, in diesem Fall nicht betroffenen Helix Ultimate zu verwechseln.

Die Ursache des Fehlers

Das Problem tritt über die Joomla-Komponente com_ajax auf, die aufgrund ihrer Konzeption Anfragen an den eigenen Ajax-Handler des jeweiligen Plugins – in diesem Fall an die Funktion onAjaxHelix3 von Helix3 – weiterleitet, und zwar auch für Besucher, die keinerlei Authentifizierung durchlaufen haben. Der Joomla-Kern führt hier keine Berechtigungsprüfung durch; diese Aufgabe obliegt dem Plugin. In Helix3 wurden jedoch mehrere Aktionen ohne Überprüfung ausgeführt.

Was ein Angreifer ohne Authentifizierung tun konnte (vor Version 3.1.1)

• save – Es war möglich, beliebige Inhalte in eine Datei unter der aktiven Vorlage zu schreiben. Der Code erzwang die Dateiendung .json, bereinigte jedoch den Pfad nicht, sodass die Datei mithilfe eines Verzeichnisdurchlaufs auch außerhalb des vorgesehenen Ordners abgelegt werden konnte.
• remove – das Löschen von Dateien ohne Einschränkungen hinsichtlich der Dateiendung und ohne Pfadprüfung, was praktisch das Löschen beliebiger Dateien ermöglichte, auf die der Benutzer des Webservers Zugriff hatte.
• import – Überschreiben der in einer Datenbank gespeicherten Parameter eines Template-Stils.
• Mehrere weitere, ebenfalls ungeschützte Funktionen (load, resetLayout, updateFonts, fontVariants) waren ebenfalls ohne Anmeldung zugänglich.

Echte Codeausführung?

An sich nicht automatisch – der Schreibvorgang war auf die Dateiendung ..json beschränkt. Dennoch kann es aufgrund zweier Szenarien dennoch zur Ausführung von Code kommen:

1. Auf falsch konfigurierten Apache-Servern, bei denen der PHP-Interpreter einen Dateinamen im Format nev.php.json zur Ausführung übergibt.
2. Im Falle einer Kettenausnutzung, bei der das willkürliche Löschen von Dateien dazu genutzt wird, Schutzdateien (z. B. .htaccess) zu entfernen, die andernfalls die Ausführung einer zuvor platzierten Datei verhindern würden.

Weitere, vom Hersteller nicht dokumentierte Korrekturen in Version 3.1.1

• Ein authentifizierter Bild-Upload-Pfad, der die Dateiendung direkt aus dem Namen der hochgeladenen Datei übernahm, ohne Whitelist – dies ermöglichte es einem Konto mit geringen Berechtigungen (Autor/Redakteur), eine .php-Datei hochzuladen und auszuführen.
• Ein zweiter Path-Traversal-Fehler beim Löschen von Bildern.
• Stored-XSS aufgrund einer nicht ordnungsgemäß maskierten Ausgabe.
• Ein fest programmierter, durchgesickerter Google Fonts-API-Schlüssel.
• Ein Endpunkt für die uneingeschränkte Abstimmung über Artikel.

Betroffene Personen

Das Manifest der korrigierten Version erklärt die Kompatibilität mit Joomla-Versionen von 4.0 bis 6.5, wobei der korrigierte Code separate Zweige für Joomla 5 und 6 enthält – das Problem betrifft also auch die derzeit aktiv genutzten Joomla-Versionen.

CVE-Status

Die Zuweisung einer formellen CVE-Kennung für diese Sicherheitslücke ist noch im Gange; die Anerkennung wurde dem Forscher, der den Fehler gemeldet hat, zugesprochen. Bis dahin gilt die korrigierte Version 3.1.1 als maßgeblicher Bezugspunkt.

Das Problem mit dem Änderungsprotokoll

Der Artikel hebt insbesondere hervor, dass der Hersteller in seinem eigenen Changelog-Eintrag lediglich folgende Angabe machte: „Security Update“ – er gab weder Auskunft über die betroffene Komponente noch über den Schweregrad der Sicherheitslücke, noch darüber, ob die Schwachstelle möglicherweise aktiv ausgenutzt wurde. Diese Art der vagen Kommunikation erschwert es den Website-Betreibern, die Dringlichkeit der Behebung einzuschätzen und die entsprechende Priorität festzulegen.

Empfohlene Sofortmaßnahmen

1. Aktualisieren Sie Helix3 unverzüglich auf Version 3.1.1 oder höher.
2. Ersetzen Sie den Google Fonts-API-Schlüssel in den Helix3-Einstellungen – der alte Schlüssel war undicht, was sich durch keine Serverkonfiguration allein beheben lässt.
3. Überprüfen Sie die beschreibbaren Ordner der Vorlage (z. B. css/, layouts/, images/) auf unerwartete .json-, .php- oder Dateien mit doppelter Dateiendung (.php.json).
4. Überprüfen Sie die Serverprotokolle auf Anfragen mit den Parametern com_ajax und plugin=helix3, insbesondere solche von unbekannten IP-Adressen.
5. Richten Sie bis zur Installation des Patches vorübergehende serverseitige Schutzmaßnahmen ein – siehe unten.

Vorübergehender .htaccess-Schutz

Die folgende Zusammenstellung von Regeln ersetzt kein Update, sondern bietet lediglich vorübergehenden, ergänzenden Schutz, bis Sie auf die Version 3.1.1 (oder höher) von Helix3 aktualisieren. Vor der Installation in einer Produktionsumgebung empfiehlt es sich, die Regeln zunächst auf einer Test- oder Staging-Seite auszuprobieren, da die strengeren Regeln die Bearbeitung von Vorlagen, Stilen und Schriftarten durch angemeldete Administratoren beeinträchtigen können.

<IfModule mod_rewrite.c>
    RewriteEngine On

    # --------------------------------------------------------------------
    # 1) Block unauthenticated requests to the vulnerable Helix3 ajax
    #    handler (com_ajax -> plugin=helix3 -> onAjaxHelix3). The exploit
    #    chain hits index.php?option=com_ajax&plugin=helix3&... with
    #    actions like save / remove / import / load / resetLayout /
    #    updateFonts / fontVariants, none of which checked auth pre-3.1.1.
    # --------------------------------------------------------------------
    RewriteCond %{QUERY_STRING} option=com_ajax [NC]
    RewriteCond %{QUERY_STRING} plugin=helix ?3? [NC]
    RewriteCond %{HTTP_COOKIE} !joomla_user_state=logged_in [NC]
    RewriteRule ^ - [F,L]

    # --------------------------------------------------------------------
    # 2) Block POST requests to com_ajax targeting helix3 with no referer
    #    from your own admin area - stops most off-site/scripted abuse.
    # --------------------------------------------------------------------
    RewriteCond %{REQUEST_METHOD} POST
    RewriteCond %{QUERY_STRING} option=com_ajax.*plugin=helix3 [NC]
    RewriteCond %{HTTP_REFERER} !^https?://(www\.)?DOMAINNEVED.HU/administrator [NC]
    RewriteRule ^ - [F,L]
</IfModule>

Wichtig: Ersetzen Sie den Platzhalter DOMAINNEVED.HU durch Ihre eigene Domain und überprüfen Sie nach der Installation, ob die auf Helix3 basierende Vorlagenbearbeitung (Stile, Layouts, Schriftarten) für angemeldete Administratoren weiterhin ordnungsgemäß funktioniert.

Zusammenfassung

Der Helix3-Vorfall verdeutlicht sehr gut, wie sehr flexible Joomla-Komponenten wie com_ajax den einzelnen Plugins eine große Verantwortung im Bereich der Berechtigungsprüfung auferlegen – schon eine einzige fehlende Überprüfung reicht aus, damit ein völlig unauthentifizierter Besucher Dateien auf dem Server schreiben oder löschen kann. Darüber hinaus verdeutlicht diese Geschichte, wie wichtig eine transparente Sicherheitskommunikation ist: Ein vager Beitrag mit dem Titel „Security Update“ liefert für sich genommen nicht genügend Informationen, damit ein Webseitenbetreiber die Dringlichkeit des Updates richtig einschätzen kann.

Wenn Sie das Helix3-Template verwenden, ist die Vorgehensweise eindeutig: Führen Sie unverzüglich ein Update auf Version 3.1.1 durch, ersetzen Sie den betroffenen API-Schlüssel und wenden Sie in der Zwischenzeit die oben genannten .htaccess-Regeln als zusätzlichen Schutz an.

• Cybersicherheit
• Website-Sicherheit
• Release
• Neuigkeiten