Joomla Helix3-Lücke: Botnetz defacet ungepatchte Websites

Veröffentlicht am 09.07.2026

Ende Juni 2026 wurde eine kritische Sicherheitslücke in einem der meistgenutzten Joomla-Frameworks bekannt – und seit dem 5. Juli greift ein automatisiertes Botnetz weltweit ungepatchte Websites an. Betroffene Seiten zeigen plötzlich eine schwarze Vollbild-Seite mit Totenkopf und dem Schriftzug „Hacked by AntonKill" oder „Hacked by trenggalek6etar". Doch der sichtbare Vandalismus ist nur die harmlose Variante. Die zugrundeliegende Lücke erlaubt weit mehr: das Löschen und Überschreiben von Dateien, die Anlage versteckter Administratorkonten – und in bestimmten Konfigurationen die vollständige Übernahme des Servers. Wer eine Joomla-Website mit dem Helix3-Framework von JoomShaper betreibt, sollte diesen Artikel jetzt lesen und noch heute handeln.

Was ist passiert?

Betroffen ist das Helix3-Framework des Anbieters JoomShaper – eine sogenannte Template-Grundlage, also das technische Gerüst, auf dem das Design und die Struktur unzähliger Joomla-Websites aufbauen. Die Schwachstelle trägt die Kennung CVE-2026-49049 und wird mit einem CVSS-Wert von 7.5 (Stufe „High") bewertet. Entdeckt und im Rahmen eines verantwortungsvollen Meldeprozesses (Responsible Disclosure) an den Hersteller gemeldet wurde sie vom Sicherheitsforscher Phil Taylor (mySites.guru).

JoomShaper reagierte schnell und veröffentlichte am 29. Juni 2026 die abgesicherte Version Helix3 3.1.1, gefolgt von Version 3.1.2 am 1. Juli 2026. Das Problem: Der Changelog nannte lediglich zwei Worte – „Security Update". Weder war ersichtlich, was genau behoben wurde, noch wie schwerwiegend die Lücke ist. Phil Taylor kritisierte das deutlich:

„JoomShaper hat die Nutzer informiert, dass ein Update verfügbar ist. Sie schrieben eine E-Mail und einen Changelog-Eintrag. Das Problem ist nur, was diese beiden Ankündigungen tatsächlich aussagten: ‚Security Update.' Zwei Worte. Keines davon sagt Ihnen, was behoben wurde, wie schwerwiegend es ist oder ob es bereits ausgenutzt wird. […] Sie können die einzig wichtige Frage nicht beantworten: Patche ich heute Nacht, oder kann das bis zum monatlichen Wartungsfenster warten?" – Phil Taylor, mySites.guru

Diese Informationslücke rächte sich. Rund sechs Tage nach Veröffentlichung des Patches – am 5. Juli 2026 – begann ein automatisiertes Botnetz, gezielt Websites anzugreifen, die das Update noch nicht eingespielt hatten. Das österreichische CERT.at nahm den Vorfall am 7. Juli in seinen Tagesbericht auf:

„Eine Schwachstelle im Helix3-Framework von JoomShaper wird durch ein Botnetz ausgenutzt, um Joomla-Instanzen zu infizieren. Dort taucht dann die Meldung ‚Hacked by AntonKill' oder auch ‚Hacked by trenggalek6etar' auf." – CERT.at

Der technische Hintergrund – verständlich erklärt

Die Schwachstelle steckt im sogenannten AJAX-Plugin des Helix3-Frameworks (technisch: plg_ajax_helix3). AJAX ist eine Technik, mit der eine Website im Hintergrund Daten mit dem Server austauscht, ohne die ganze Seite neu zu laden. Joomla besitzt einen zentralen Verteiler namens com_ajax, der solche Anfragen entgegennimmt – und zwar auch von völlig anonymen Besuchern. Die Prüfung, ob jemand überhaupt berechtigt ist, eine Aktion auszuführen, muss das jeweilige Plugin selbst vornehmen. Genau das versäumte Helix3 in den Versionen vor 3.1.1.

Drei Aktionen waren dadurch ohne jede Anmeldung erreichbar:

• „save": schreibt beliebigen, vom Angreifer kontrollierten Inhalt in eine Datei innerhalb des aktiven Templates. Zwar wurde der Dateiname auf die Endung .json beschränkt, der Pfad war jedoch nicht bereinigt – über sogenanntes Path-Traversal (das gezielte Ausnutzen von „../"-Pfadangaben zum Verlassen des erlaubten Ordners) ließen sich Dateien auch an anderen Stellen ablegen.
• „remove": löscht beliebige Dateien, auf die der Webserver Zugriff hat – etwa die zentrale configuration.php oder die .htaccess-Datei.
• „import": überschreibt die gespeicherten Einstellungen eines Template-Stils direkt in der Datenbank. Genau diese Aktion nutzt die aktuelle Defacement-Welle.

Und hier liegt das Besonders Tückische: Der Schadcode landet nicht in einer Datei, sondern direkt in der Joomla-Datenbank – in der Tabelle #__template_styles, in Feldern wie „Custom JavaScript", „Custom CSS" oder „Before </head>". Beim nächsten Seitenaufruf führt der Browser diesen Code aus und überblendet die komplette Seite mit der Hacker-Botschaft. Weil der Code nicht in Dateien steckt, schlagen klassische dateibasierte Malware-Scanner nicht an – die Kompromittierung bleibt für viele Standardwerkzeuge unsichtbar.

Weitere in Version 3.1.1 geschlossene Lücken: Der Bild-Upload akzeptierte beliebige Dateitypen, auch .php-Dateien – ein eingeloggter Nutzer mit niedrigen Rechten (etwa Autor oder Redakteur) konnte darüber Schadcode zur Ausführung bringen (Remote Code Execution). Hinzu kamen ein zweiter Path-Traversal beim Bildlöschen, fehlende Absicherung gegen Cross-Site-Scripting (XSS, das Einschleusen fremden JavaScripts) sowie ein im Quelltext hinterlegter Google-Fonts-API-Schlüssel.

Die gefährliche, stille Variante

Das sichtbare Defacement mit Totenkopf ist ärgerlich – aber immerhin warnt es. Sicherheitsforscher Phil Taylor weist auf eine deutlich heimtückischere Nutzung derselben Lücke hin:

„Der Totenkopf sagt Ihnen wenigstens, dass etwas nicht stimmt. Die gefährlichere Nutzung desselben Fehlers verunstaltet gar nichts. Statt einer Vollbild-Übernahme schreibt der Angreifer einen unauffälligen Loader in dieselben Custom-Code-Felder: ein kleines Skript, das Ihre Seite völlig normal aussehen lässt, während es zur Laufzeit die eigentliche Schadfracht nachlädt." – Phil Taylor, mySites.guru

Diese stillen Loader können zum Beispiel Fake-CAPTCHA-Seiten oder sogenannte Wallet-Drainer nachladen (Skripte, die Kryptowährungs-Guthaben von Besuchern abgreifen). Ein Kommentator auf borncity.com brachte ein weiteres Risiko auf den Punkt: „Wenn da JavaScript-Code eingefügt werden kann, sowas kann theoretisch auch Login-Daten bei der Eingabe abgreifen."

Wer ist betroffen?

Betroffen sind alle Helix3-Installationen vor Version 3.1.1 – kompatibel mit Joomla 4, 5 und 6, aber auch ältere Joomla-3-Installationen wurden angegriffen. Die Reichweite ist enorm: Helix3 verzeichnet laut JoomShaper über 1.403.899 Downloads, der Hersteller insgesamt mehr als 13,4 Millionen Downloads und rund 780.000 registrierte Nutzer weltweit.

Für den deutschen Mittelstand ist das besonders relevant: Deutschland ist laut technologychecker.io das Land mit der weltweit höchsten Joomla-Adoptionsrate – rund 17 % aller Unternehmen setzen es ein. Laut W3Techs (Stand 9. Juli 2026) läuft Joomla auf 1,2 % aller Websites weltweit, und ganze 54,3 % dieser Joomla-Websites nutzen noch Joomla 3.

Genau diese Joomla-3-Nutzer trifft es doppelt hart: Am 9. Juli 2026 kündigte JoomShaper an, für alle Joomla-3-Versionen seiner Produkte keine Sicherheitspatches mehr bereitzustellen – wörtlich: „No security patches, regardless of severity." Wer auf Joomla 3 bleibt, erhält also selbst bei kritischen Lücken keine Korrekturen mehr.

Zusätzlich veröffentlichte JoomShaper am 7. Juli 2026 ein separates Update für das verwandte Helix Ultimate Framework (Version 2.2.7), das eigene Lücken im com_ajax-Handler schließt (unter anderem unauthentifizierter Menü-Schreibzugriff mit XSS-Potenzial, Dateilöschung und Open Redirect).

So prüfen Sie, ob Sie betroffen sind

1. Melden Sie sich im Joomla-Backend an (die URL endet auf /administrator).
2. Navigieren Sie zu System › Verwalten › Plugins (bzw. Erweiterungen › Verwalten).
3. Suchen Sie nach „Helix3" und lesen Sie die Versionsnummern der Plugins „System - Helix3 Framework" und „Helix3 - Ajax" ab.
4. Liegt die Version unter 3.1.2, ist Ihre Installation verwundbar und muss sofort aktualisiert werden.
5. Prüfen Sie auf Kompromittierung: Erweiterungen › Templates › Stile, aktiven Helix3-Stil öffnen, Reiter „Custom Code" aufrufen.
6. Untersuchen Sie die Felder „Custom JavaScript", „Custom CSS" und „Before </head>" auf fremden Code. Verdächtige Indikatoren: document.body.innerHTML, document.title = "hacked by", position:fixed;inset:0, z-index:2147483647, AntonKill, trenggalek6etar.
7. Alternativ prüfen Sie direkt in der Datenbank per SQL-Abfrage:
   SELECT id, template, title FROM #__template_styles WHERE params LIKE '%innerHTML%' OR params LIKE '%AntonKill%' OR params LIKE '%trenggalek6etar%'; (Tabellenpräfix anpassen).
8. Prüfen Sie auch auf stille Kompromittierung: Untersuchen Sie die Felder auf eval(), atob(), data:-URIs oder externe Skript-Quellen – auch dann, wenn kein sichtbares Defacement vorliegt.

Das müssen Sie jetzt tun

1. Backup anlegen: Sichern Sie Dateien und Datenbank vollständig, bevor Sie weitere Maßnahmen ergreifen.
2. Helix3 auf 3.1.2 aktualisieren: Über System › Aktualisieren › Erweiterungen beide Plugins aktualisieren – „System - Helix3 Framework" UND „Helix3 - Ajax". Erscheint kein Update, laden Sie das Paket aus Ihrem JoomShaper-Konto herunter und spielen Sie es über Erweiterungen › Installieren ein.
3. Notfallmaßnahme für Joomla 3: Ist ein Update nicht möglich, deaktivieren Sie das AJAX-Plugin „Helix3 - Ajax" sofort (System › Plugins), bis eine Migration erfolgt.
4. Eingeschleusten Code entfernen: Unter Erweiterungen › Templates › Stile › (aktiver Helix3-Stil) › Custom Code alle Felder von fremdem Code befreien. Sicherer ist die Wiederherstellung des params-Werts aus einem Backup von vor dem Angriff.
5. Alle Passwörter ändern: Joomla-Administratorkonten, Datenbankpasswort, FTP- und SSH-Zugänge.
6. Benutzerkonten prüfen: Unter Benutzer › Verwalten kontrollieren, ob unbekannte Super-User-Konten angelegt wurden – diese sofort löschen.
7. Dateiintegrität prüfen: Template-Ordner auf unerwartete Dateien (insbesondere .php-Dateien oder unbekannte JSON-Dateien) untersuchen; prüfen, ob .htaccess-Dateien gelöscht wurden.
8. Helix Ultimate separat aktualisieren auf Version 2.2.7, falls installiert.
9. Caches leeren: Joomla-Cache (System › Cache löschen) und Browser-Cache.
10. DSGVO-Prüfung durchführen (siehe nächster Abschnitt).
11. Langfristig: Joomla-3-Installationen auf Joomla 5 oder 6 migrieren, automatische Update-Benachrichtigungen einrichten und Sicherheitsupdates als festen Wartungsprozess etablieren.

website-bereinigung.de bringt die Kernlehre auf den Punkt:

„Der eigentliche Fehler war nicht der Angriff, sondern das Zeitfenster: Zwischen dem öffentlichen Patch am 29. Juni und dem Einspielen des Updates blieb genug Zeit, dass die Botnetze zuschlagen konnten. Der wichtigste Schutz ist deshalb banal: sicherheitsrelevante Erweiterungen zeitnah aktualisieren, nicht erst zum nächsten Wartungsfenster."

DSGVO-Relevanz: Warum das mehr ist als kosmetischer Schaden

Auch wenn ein Defacement zunächst nur nach Vandalismus aussieht: Die zugrundeliegende Lücke ermöglicht das Löschen und Schreiben von Dateien sowie das Überschreiben von Einstellungen – und potenziell die vollständige Serverübernahme. Damit kann ein Angriff eine meldepflichtige Datenpanne nach Art. 33 DSGVO auslösen.

Die Meldepflicht greift, sobald personenbezogene Daten betroffen sind und ein Risiko für die Rechte und Freiheiten natürlicher Personen besteht. Auf einer typischen KMU-Website sind das etwa Kontaktformular-Einträge, Newsletter-Abonnenten, Bestell- oder Kundendaten und Login-Daten. Die Frist beträgt 72 Stunden ab Kenntnisnahme – auch an Wochenenden und Feiertagen. Zuständig ist die jeweilige Landesdatenschutzbehörde (etwa LDI NRW oder LfDI Baden-Württemberg). Bei hohem Risiko müssen zusätzlich die betroffenen Personen nach Art. 34 DSGVO informiert werden.

Wichtig für die Haftung: Nach Art. 32 DSGVO sind Website-Betreiber verpflichtet, geeignete technische und organisatorische Maßnahmen zum Schutz personenbezogener Daten zu treffen – dazu zählt das zeitnahe Einspielen von Sicherheitsupdates. Das Versäumnis, eine bekannte kritische Lücke zu schließen, kann als Verstoß gewertet werden und Bußgelder von bis zu 10 Mio. Euro oder 2 % des weltweiten Jahresumsatzes nach sich ziehen. Selbst wenn keine Daten gestohlen wurden, kann bereits die Verletzung von Integrität und Verfügbarkeit ausreichen. Alle Vorfälle sind nach Art. 33 Abs. 5 DSGVO zu dokumentieren – auch dann, wenn keine Meldung nötig ist.

Einordnung und Fazit

Der Fall folgt einem Muster, das Sicherheitsexperten immer wieder beobachten. Phil Taylor beschreibt es so: „Die Massenausnutzung begann etwa eine Woche später – das ist das Muster, das wir immer wieder sehen: Ein Patch erscheint, die meisten Seiten spielen ihn nicht ein, und das Fenster zwischen öffentlichem Patch und öffentlichem Botnetz wird in Tagen gemessen."

Der Angriff ist vollautomatisiert und nicht zielgerichtet – jede ungepatchte Joomla-Installation mit Helix3 ist potenziell betroffen, unabhängig von Größe oder Branche. Vergleichbare Vorfälle gab es zuletzt gehäuft: CVE-2026-21628 im Astroid-Framework (CVSS 10.0, März 2026) und CVE-2026-48908 im SP Page Builder (CVSS 10.0, Juni 2026), das zur Anlage versteckter Super-User-Konten missbraucht wurde.

Unsere klare Empfehlung: Prüfen Sie noch heute, ob Ihre Website Helix3 oder Helix Ultimate einsetzt, und aktualisieren Sie umgehend auf Helix3 3.1.2 beziehungsweise Helix Ultimate 2.2.7. Betreiben Sie noch Joomla 3, planen Sie dringend die Migration auf Joomla 5 oder 6 – denn Sicherheitspatches von JoomShaper wird es für Joomla 3 nicht mehr geben. Sicherheit ist kein einmaliges Projekt, sondern ein laufender Prozess. Das schmale Zeitfenster zwischen Patch und Angriff ist genau der Grund, warum „später" bei Sicherheitsupdates keine Option ist.