Am 13. September hat Regular Labs vierundzwanzig seiner Joomla-Erweiterungen aktualisiert. Zehn dieser Aktualisierungen schliessen Sicherheitslücken, zusammen neun CVE-Nummern.
Der Name sagt vielen Seitenbetreibern nichts. Das ist kein Vorwurf: Diese Erweiterungen stecken hinter Funktionen, die irgendwann jemand eingebaut hat — Inhalte, die nur bestimmten Besuchergruppen erscheinen, Artikel, die an einer zweiten Stelle noch einmal auftauchen, aufklappbare Abschnitte, Textbausteine. Wer die Seite bedient, sieht die Funktion. Den Anbieter dahinter sieht man erst, wenn etwas ist.
Die schwerste der neun
CVE-2026-85192, Conditional Content, Schweregrad 9.4 von 10, eingestuft als Codeeinschleusung.
Die Erweiterung kann Inhalte an Bedingungen knüpfen, und in der kostenpflichtigen Fassung dürfen diese Bedingungen PHP enthalten. Das ist kein Fehler, sondern eine gewollte Funktion für Leute, die wissen, was sie tun.
Der Fehler steckte eine Ebene tiefer. Der Datensatz beschreibt ihn so: Der PHP-Code wurde an die Auswertung weitergereicht, ohne zu prüfen, wer den Artikel verfasst hat. Joomlas gewöhnlicher Textfilter für Autoren lässt die Schreibweise unangetastet. Wird der Artikel veröffentlicht, läuft der Code — mit den Rechten des Webservers.
Betroffen sind alle Fassungen bis 7.1.0. Behoben in 8.0.0; aktuell ist seit dem 14. September 8.0.1.
Acht der neun haben dieselbe Gestalt
Beim Durchsehen der übrigen acht fällt auf, dass sie sich kaum unterscheiden — nicht technisch, aber im Bedrohungsmodell.
Bei Articles Anywhere liessen sich JavaScript-Ereignisse anhängen. Bei Modals wurden Adressen akzeptiert, die statt einer Seite Programmcode aufrufen. Bei Quick Index liess sich über eine Formatangabe JavaScript einschleusen, bei Tabs & Accordions über ein Attribut, das beim Klick ausgeführt wird. Bei Snippets liessen sich Variablen überschreiben, die eigentlich in den Einstellungen festgelegt sind.
Sechs davon tragen 7.5, einer 6.9, einer 5.3.
Und in jedem einzelnen Fall ist der Auslöser derselbe: jemand, der Inhalte erfassen darf. Kein Angreifer, der von aussen eine Tür aufbricht. Ein Konto, das Sie selbst vergeben haben.
Warum das ein anderes Problem ist als sonst
Die meisten Meldungen, über die wir hier schreiben, handeln von aussen: eine Lücke im Server, ein Plugin, das ohne Anmeldung erreichbar ist, ein Filter, der zu viel durchlässt.
Hier ist es umgekehrt. Die Voraussetzung ist ein Redaktionszugang — und den hat in fast jedem Betrieb mehr als eine Person. Die Agentur, die den Auftritt gebaut hat. Die Praktikantin, die im Sommer die Produkttexte erfasst hat. Der Marketingmensch, der seit zwei Jahren nicht mehr da ist, dessen Konto aber nie jemand gelöscht hat.
«Darf Artikel schreiben» klingt nach der harmlosesten Rechtestufe, die es gibt. Bei diesen Fassungen hiess sie: darf JavaScript an Ihre Seite hängen. In einem Fall: darf PHP auf Ihrem Server ausführen.
Und eine Folgerung, die in keiner der Quellen steht, sondern sich aus der Sache ergibt: Wer auf seiner Joomla-Seite die Registrierung offen hat und neu angelegten Konten Schreibrechte gibt — für ein Vereinsportal, für einen Blog mit Gastautoren —, der hat die Voraussetzung dieses Angriffs selbst eingerichtet. Dann braucht es kein gestohlenes Passwort mehr, sondern nur ein Anmeldeformular.
Eine Unstimmigkeit, die wir nicht auflösen können
Der CVE-Datensatz zur schwersten Lücke enthält zwei Angaben, die sich widersprechen.
Die technische Bewertung vergibt für «benötigte Rechte» die Stufe hoch. Die Beschreibung im selben Datensatz spricht dagegen vom Verfasser eines Artikels — und das ist in Joomla die unterste Stufe, auf der man überhaupt etwas schreiben kann.
Für einen Betrieb macht das einen erheblichen Unterschied: «Ein Administrator kann Schaden anrichten» ist eine andere Nachricht als «jeder, der einen Artikel einreichen darf, kann es».
Wir wissen nicht, wie es gemeint war, und behaupten es deshalb auch nicht. Wir halten uns an die Beschreibung, weil sie die genauere der beiden Angaben ist — und weil die Folge daraus, den Kreis der Schreibberechtigten einmal durchzusehen, ohnehin richtig ist.
Kostenlos oder bezahlt — hier zählt der Unterschied
Die schwerste der neun, die mit dem PHP, betrifft ausdrücklich die kostenpflichtige Fassung von Conditional Content. Wer die freie Version einsetzt, ist von dieser einen nicht betroffen.
Das ist eine der wenigen Gelegenheiten, bei denen die kostenlose Variante besser dasteht — und zwar nicht aus Zufall, sondern weil ihr genau die Funktion fehlt, über die der Angriff läuft.
Die übrigen acht sind davon unberührt.
Wie Sie überhaupt davon erfahren
Hier liegt der unangenehme Teil, und er ist uns aus einem anderen Zusammenhang vertraut.
Eine Joomla-Seite liest die Änderungsmeldungen des Herstellers nicht. Sie fragt eine Datei auf dem Server des Anbieters ab, und erst wenn dort die neue Versionsnummer steht, erscheint im Backend ein Hinweis. Am Tag der Freigabe gab es dabei Verzögerungen — Seiten, die am 13. September nachsahen, bekamen teilweise noch den alten Stand.
Wer also einmal geschaut und nichts gesehen hat, sollte noch einmal schauen.
Wir haben dasselbe Muster im August beschrieben, als eine Elementor-Lücke nachträglich zur Angriffswelle wurde: Dort meldete die Seite das Update gar nicht erst. Der Mechanismus unterscheidet sich, das Ergebnis ist dasselbe — die Seite sagt Ihnen nicht zuverlässig, dass sie ein Problem hat.
Und noch eine Stelle, an der man vergeblich nachsieht: Joomlas eigene Liste verwundbarer Erweiterungen führt diese neun nicht. Wer sie als Anlaufstelle kennt, findet dort zu diesem Fall nichts.
Was zu tun ist
Sehen Sie im Backend unter Erweiterungen nach, ob etwas von Regular Labs installiert ist. Die Namen sind unverkennbar: Articles Anywhere, Modals, Snippets, Tabs, Conditional Content, Quick Index, Users Anywhere, Advanced Module Manager.
Wenn ja: aktualisieren. Alle, nicht nur die mit der hohen Zahl. Vier der neun betreffen Erweiterungen, die man leicht übersieht, weil sie nie Ärger gemacht haben.
Und dann der Teil, der länger wirkt als dieses eine Update: Gehen Sie die Benutzerliste durch. Wer hat Schreibrechte, und braucht das noch jemand? Ein Konto, das seit einem Jahr niemand benutzt, ist kein ruhender Posten — es ist eine Voraussetzung, die jemand erfüllt, ohne dass Sie es merken.
Ob sich automatische Aktualisierungen für Erweiterungen lohnen, haben wir an anderer Stelle abgewogen. Die Antwort fällt nicht für jeden gleich aus, aber sie ist eine Überlegung wert, wenn ein Anbieter an einem Tag neun Lücken schliesst.
Dass alte Joomla-Erweiterungen jahrelang ungepatcht stehen bleiben, haben wir Ende August an zwei Beispielen gezeigt. Der Unterschied hier: Diese Korrektur ist eine Woche alt und steht bereit.
Wenn Sie nicht sicher sind, was auf Ihrer Seite läuft
Wir schauen nach. Eine Bestandsaufnahme der Erweiterungen samt Versionsständen und offenen Konten ist eine überschaubare Sache, und sie beantwortet gleich mehrere Fragen auf einmal — nicht nur die von heute.