Am 29. September sind Joomla 5.4.9 und 6.1.4 erschienen. Sie schliessen sechzehn Sicherheitslücken im Kern: zwei als hoch eingestuft, dreizehn als moderat, eine als niedrig. Darunter sieben Cross-Site-Scripting-Fehler und sechs bei der Zugriffskontrolle.
Vorweg, weil es sonst untergeht: Das Projekt meldet keine aktive Ausnutzung. Niemand muss heute Nacht aufstehen. Es ist ein gewöhnliches Sicherheitsrelease, und genau so sollte man es behandeln — nämlich einspielen.
Interessant sind zwei Einträge aus der Mitte der Liste.
«Registrierung: Nein» hat nicht gereicht
`CVE-2026-90907` trägt den Titel «Unauthorized user account creation via profile.save controller». Die Begründung im Advisory ist ein einziger Satz: Der Controller prüfte den Anmeldezustand nicht.
Im Ergebnis konnte ein Besucher ein Benutzerkonto anlegen — mit einem Passwort seiner Wahl, und ohne angemeldet zu sein. Das Konto landet in der Gastgruppe.
Entscheidend ist, was dabei nicht half: die abgeschaltete Registrierung. «Benutzerregistrierung: Nein» ist bei vielen Vereins-, Firmen- und Gemeindeseiten der eine Haken, auf den man sich verlässt, weil die Seite ja gar keine Konten anbieten soll. Dieser Weg ging an ihm vorbei.
Die Lücke ist als moderat eingestuft, nicht als hoch. Das ist auch richtig so: Ein Gastkonto kann wenig. Bemerkenswert ist nicht der Schaden, sondern dass eine bewusst getroffene Einstellung ins Leere lief.
Das Advisory nennt als betroffene Spanne 1.5.0 bis 5.4.8 sowie 6.0.0 bis 6.1.3. Ob das heisst, dass der Fehler tatsächlich so alt ist, oder schlicht «alle Versionen bis hierher», geht daraus nicht hervor — wir deuten es deshalb nicht.
Der zweite Faktor, umgangen über «Angemeldet bleiben»
Der zweite Eintrag ist `CVE-2026-92227`, ebenfalls moderat: eine Umgehung der Zwei-Faktor-Anmeldung über Remember-Me-Cookies.
Der Grund ist so einfach wie unangenehm. Das Cookie «Angemeldet bleiben» wurde zu früh im Anmeldevorgang ausgestellt — bevor der zweite Faktor geprüft war.
Wer Zwei-Faktor einschaltet, tut das in der Annahme, dass ein gestohlenes Passwort allein nicht mehr genügt. Hier gab es einen Weg, bei dem genau das nicht galt. Betroffen sind die Versionen 4.0.0 bis 5.4.8 und 6.0.0 bis 6.1.3.
Auch hier: keine Meldung über Ausnutzung. Und auch hier ist das Lehrreiche nicht die Schwere, sondern die Richtung. Beide Lücken sitzen in Schutzmassnahmen, nicht in Komfortfunktionen.
Die beiden hoch eingestuften
Der Vollständigkeit halber, denn sie sind die schwereren:
`CVE-2026-90915` erlaubt es, über die Cache-Bereinigung beliebige Verzeichnisse zu löschen — der Name der Cache-Gruppe wurde nicht sauber geprüft, und über eine Pfaddurchquerung liess sich jeder Ordner treffen, in den der Webserver schreiben darf. Das braucht administrative Rechte, richtet damit aber grossen Schaden an.
`CVE-2026-92222` ist eine SSRF in mehreren Kern-Erweiterungen: Adressen für serverseitige Anfragen wurden unzureichend geprüft, sodass sich der Server dazu bringen lässt, Adressen abzurufen, die er nicht abrufen sollte — etwa im internen Netz.
Was Sie wissen sollten, bevor Sie aktualisieren
Hier wird es unbequem, und deshalb steht es nicht am Ende.
Version 5.4.9 hat eine bekannte Regression. Wer die Web-Services von Joomla benutzt, bekommt bei PATCH-Anfragen — also beim Ändern von Datensätzen wie Benutzern oder Bannern — einen fatalen Fehler. Ursache ist ein vergessener Import im Quelltext. Ein Workaround ist dokumentiert, die dauerhafte Behebung ist für 5.4.10 vorgesehen.
Für die allermeisten Seiten spielt das keine Rolle, weil sie die Web-Services gar nicht nutzen. Wer sie aber nutzt, sollte es vorher wissen und nicht danach.
Das ist kein Argument gegen das Update. Es ist ein Argument dafür, nach dem Update kurz nachzusehen, ob noch alles läuft — was ohnehin gelten sollte.
Und warum das Update nicht von selbst kommt
Joomla kann sich seit einiger Zeit selbst aktualisieren. Wir haben Anfang September beschrieben, wo diese Automatik greift und wo nicht: Sie deckt den Kern ab, und sie muss eingeschaltet sein.
Dazu kommt die Falle, die wir am eigenen Server vorgeführt bekommen haben: Eingespielt ist nicht in Betrieb. Sehen Sie im Backend unter «System» nach, welche Version tatsächlich läuft — nicht, welche heruntergeladen wurde.
Und falls Sie beim Nachsehen feststellen, dass Sie gar nicht wissen, wer sich um diese Seite kümmert: Das ist der häufigere Fall, als man denkt, und er ist der eigentliche Befund.