Wenn das CMS Backend-Passwörter im Klartext schreibt: TYPO3 14.2 und CVE-2026-6553

TL;DR — die 90-Sekunden-Zusammenfassung

CVE-2026-6553

Backend-User-Settings-Modul in TYPO3 14.2.0 serialisiert sensible Felder gemeinsam mit UI-Präferenzen — Passwörter landen im Klartext in be_users.uc und user_settings

Betroffene Version

ausschließlich TYPO3 14.2.0 — 14.1.x und früher sind nicht betroffen, 14.3.0 ist der Fix

Datenbank-Eingriff

Update auf 14.3.0 reicht nicht — die Spalten müssen bereinigt und alle Backend-Passwörter zwangs-rotiert werden

Folgeproblem

Backups aus dem 14.2.0-Zeitfenster enthalten Klartext-Passwörter — das verändert ihre Klassifizierung

Vier Leitplanken

Karenzzeit für LTS-Minors, Composer-Lockfile, sensitive Backup-Klassifizierung, strukturierte Bereinigung statt bloss patchen

NIS-2-Hebel

Authentifizierungsdaten-Schutz ist Pflicht — ohne Inventar und Audit-Log ist der Vorfall nachträglich nicht rekonstruierbar

 

Was ist das Problem?

Am 24. April 2026 veröffentlichte das TYPO3-Security-Team das Advisory zu CVE-2026-6553. Betroffen ist ausschließlich Version 14.2.0 (LTS): Im neuen Backend-User-Settings-Modul wurden sensible Felder wie Passwörter mit den üblichen UI-Einstellungen gemeinsam serialisiert und landeten im Klartext in den Spalten uc und user_settings der Tabelle be_users. Die offizielle Fix-Version ist 14.3.0.

Es handelt sich um einen klassischen Trennungsfehler im Datenmodell. Backend-Settings (UI-Präferenzen) und Identitätsattribute (Passwort, E-Mail) liegen in TYPO3 historisch in zwei getrennten Pfaden, weil der eine Pfad anders behandelt werden muss als der andere — mit Hashing, mit Audit-Logging, mit klarer Quelle der Wahrheit. In 14.2.0 wurde diese Trennung im neuen Modul aufgehoben. Das Resultat ist eine Datenbank, die einen Teil ihrer eigenen Schutzschicht verloren hat, ohne dass es im laufenden Betrieb sichtbar wird.

Für uns als Agentur, die TYPO3 in Kunden-Setups produktiv betreibt, war das ein kurzer Sonntagabend mit Zeilenzählen. Niemand auf unseren betreuten Plattformen hat in den letzten Wochen das Backend-User-Settings-Modul von 14.2.0 auf eine Weise genutzt, die das Problem ausgelöst hätte. Das ist kein Zufall, sondern eine Folge davon, dass wir Major- und Minor-Updates auf TYPO3-LTS-Linien grundsätzlich nicht am Tag des Releases einziehen.

Auswirkungen: Klartext-Passwörter sind kein Backup-Problem allein

Der Code läuft, das Backend antwortet, der Login funktioniert. Das einzige, was kaputt ist, ist eine unsichtbare Annahme — nämlich die, dass der Tabelleninhalt unter be_users ein hashedes Passwortfeld und ansonsten harmlose UI-Daten enthält. Wer auf dieser Annahme aufbaut (etwa weil er Backups als nicht-sensitiv klassifiziert oder Datenbank-Read-Zugriffe nicht protokolliert), trägt das Risiko nun in seinen Routinen mit, ohne es zu merken.

Backups sind rückwirkend sensitiver

Wer in dem Zeitfenster, in dem 14.2.0 produktiv lief, ein Backup gezogen hat — sei es das Hosting, sei es ein interner Job, sei es ein Dienstleister —, hat potenziell Klartext-Passwörter in seinem Backup-Pool. Das macht jedes solche Backup zu einem sensitiven Datenträger und verändert die Anforderungen an Aufbewahrung, Zugriff und Vernichtung.

Passwort-Wiederverwendung wird zum Cross-System-Risiko

Backend-Nutzer im TYPO3 sind häufig nicht nur Redakteure, sondern Externe, Agenturen, Test-Accounts. Die Annahme, dass diese Personen für jedes System ein eigenes, starkes Passwort vergeben, hält einer nüchternen Prüfung selten stand. Ein in be_users.uc gespeichertes Klartext-Passwort kann deshalb zur Öffnung anderer Systeme werden, in denen TYPO3 selbst gar nicht im Spiel ist.

NIS-2 macht das zum dokumentierten Vorfall

NIS-2 verlangt im Risikomanagement explizit Schutz von Authentifizierungsdaten und ein definiertes Patch-Management. Wer unter NIS-2 fällt, ist verpflichtet, einen Vorfall dieser Klasse strukturiert nachzuvollziehen — also: Welche Systeme waren betroffen, welche Backups, welche Personen, welche Folgemaßnahmen. Ohne sauberes Inventar und ohne Audit-Log ist das im Nachhinein nicht mehr leistbar.

Wer ist betroffen?

Im Kern: jede TYPO3-Installation, die zwischen dem 14.2.0-Release und dem 14.3.0-Patch die LTS-Minor aktiv ausgerollt hat. Drei Konstellationen sind besonders relevant.

• Multisite-Setups mit gemeinsamer be_users-Tabelle — ein einziger Backend-Login mit 14.2.0-Erfahrung kontaminiert die ganze Installation. Wer mehrere Sites auf einer DB fährt, hat den größten Cleanup-Aufwand.
• Hosting mit fremd-betriebenen Backups — Managed-Hosting-Anbieter und externe Backup-Dienstleister kennen jetzt potenziell Klartext-Passwörter Ihrer Redakteure. Klassifizierung und ggf. Löschauftrag sind Pflicht.
• Externe Accounts mit Backend-Zugang — Agenturen, Freelancer, QA-Tester. Genau diese Personengruppe nutzt Backend-Accounts häufig mit Passwörtern, die anderswo (Slack, Jira, eigener Mail-Account) ebenfalls in Umlauf sind.

Wer 14.2.0 nie produktiv hatte oder vor dem 24. April 2026 bereits auf 14.3.0 gewechselt ist, ist nicht direkt betroffen. Backups aus dem 14.2.0-Fenster bleiben dennoch sensitiver Datenträger.

Mitigation und Sofortmaßnahmen — vier Schritte, in dieser Reihenfolge

Quick-Start, in der Reihenfolge in der wir aktuell aufräumen. Jeder Schritt setzt den davor voraus.

# 1. Update einziehen (Composer-basiert)
composer require typo3/cms-core:^14.3.0 --update-with-dependencies
vendor/bin/typo3 upgrade:run

# 2. be_users-Tabelle prüfen und bereinigen
mysql -e "SELECT uid, username, LENGTH(uc) AS uc_len \
         FROM be_users WHERE uc IS NOT NULL"
mysql -e "UPDATE be_users SET uc = NULL, user_settings = NULL"

# 3. Erzwungener Passwort-Reset für alle Backend-Nutzer
mysql -e "UPDATE be_users SET password = '', \
         tx_extbase_type = 'reset_required'"

1. Karenzzeit für Minor-Releases auf LTS-Linien

Eine 14.2.0 wird in unserem Update-Pfad nicht am Erscheinungstag eingezogen, sondern erst, wenn sie eine definierte Reifezeit überstanden hat. Im konkreten Fall hätte die Karenzzeit genügt, um den Patch 14.3.0 abzuwarten und 14.2.0 schlicht zu überspringen. Ausnahme bleibt der bekannte, aktiv ausgenutzte CVE — dann gehen wir bewusst auf die neue Version mit kalkuliertem Risiko.

2. Composer-basierte Installation mit committetem Lockfile

Auch für TYPO3 gilt: keine „latest“-Versionen, kein composer update in CI, sondern composer install gegen ein versioniertes composer.lock. Das verhindert, dass eine spontan aktualisierte Dependency unbemerkt in einen Build rutscht. Dieselbe Disziplin wie im Composer-CVE-Beitrag.

3. Datenbank-Backups als sensitiv klassifiziert

Wer Backups standardmäßig als „intern, vertraulich“ führt, kann auf Vorfälle wie CVE-2026-6553 reagieren, ohne erst die eigene Klassifizierung neu erfinden zu müssen. Das spart Wochen. Aufbewahrungs- und Vernichtungsregel sind im Backup-Konzept definiert, nicht im Vorfall improvisiert.

4. Strukturierte Bereinigung statt blosses Update

Wenn eine Lücke produktive Daten kompromittiert, ist das Update Schritt eins von drei. Schritt zwei ist die Bereinigung der bereits gespeicherten Klartext-Daten in be_users.uc und user_settings. Schritt drei ist der erzwungene Passwort-Reset für alle Backend-Nutzer plus Aktivierung von MFA. Erst dann ist der Vorfall sauber abgeschlossen.

Detection und Prüfung

Fünf Kernfragen — in einer halben Stunde haben Sie Klarheit über Ihren Vorfall-Status.

• War 14.2.0 in Ihrer Plattform produktiv — und zwischen welchen Datums-Werten? Ein git log composer.lock auf die Zeile typo3/cms-core bringt das Fenster.
• Welche Backend-Nutzer haben sich in diesem Fenster eingeloggt? SELECT username, lastlogin FROM be_users WHERE lastlogin BETWEEN ...
• Enthalten be_users.uc oder be_users.user_settings aktuell noch serialisierte Daten? SELECT uid, username, LENGTH(uc) FROM be_users
• Welche Backups stammen aus dem 14.2.0-Fenster? Diese Backups sind ab jetzt als „sensitiv — enthält potenziell Klartext-Passwörter“ klassifiziert.
• Welche Personen mit Backend-Zugang nutzen das Passwort plausibel auch anderswo? Diese Personen brauchen einen Reset-Hinweis, der das erwähnt — nicht nur den TYPO3-Reset.

Quick-Check-SQL, das wir vor jedem Cleanup fahren:

-- Welche be_users haben überhaupt user_settings/uc?
SELECT uid, username,
       CASE WHEN uc IS NOT NULL THEN LENGTH(uc) ELSE 0 END AS uc_len,
       CASE WHEN user_settings IS NOT NULL THEN LENGTH(user_settings) ELSE 0 END AS us_len
FROM be_users
ORDER BY uc_len + us_len DESC;

-- Suche nach typischen Klartext-Indikatoren
SELECT uid, username
FROM be_users
WHERE uc LIKE '%password%' OR user_settings LIKE '%password%';

Betreiberempfehlung

Was für welches TYPO3-Setup jetzt operativ stehen sollte — abhängig davon, wo Sie heute stehen.

• Wenn Sie 14.2.0 produktiv betrieben haben und noch nicht auf 14.3.0 sind — dann ist das Update plus die SQL-Bereinigung plus erzwungener Passwort-Reset diese Woche der einzige sinnvolle Pfad. Vorher keine Inhalts-Releases.
• Wenn Sie auf 14.1.x oder 13.x sind — dann ist 14.3.0 die nächste sinnvolle LTS-Minor, nicht das parkierte 14.2.0. Karenzzeit-Disziplin hat den Job gerade gemacht, halten Sie sie durch.
• Wenn Backups aus dem 14.2.0-Fenster bei einem Managed-Hosting oder Backup-Dienstleister liegen — dann Klassifizierungs-Anpassung schriftlich an den Anbieter, ggf. Löschauftrag für die betroffenen Backup-Generationen.
• Wenn Sie unter NIS-2 fallen — dann ist die strukturierte Dokumentation des Vorfalls (Inventar betroffener Systeme, Personen, Backups, Folgemaßnahmen) Pflicht und sollte nicht improvisiert in einem Ticket sondern in einem definierten Incident-Record laufen.
• Wenn Sie MFA im Backend noch nicht aktiviert haben — dann ist genau jetzt der Anlass, das zu ändern. Der Passwort-Reset ohne MFA repariert nur die halbe Konsequenz.

Cross-Referenzen: der Composer-CVE-Beitrag für Update-Disziplin, der Managed-Hosting-Beitrag für Backup-Klassifizierung, und der Externe-IT-Abteilung-Beitrag für die strukturelle Einbindung in NIS-2-Disziplin.

Fazit

Die meisten Pipeline-Reviews, die wir in den letzten Monaten gemacht haben, zeigen das gleiche Muster: TYPO3 wird gepatcht, weil das Update kommt. Selten wird geprüft, ob der Datenbestand nach dem Update noch zur Annahme passt, gegen die das Update geschrieben wurde. Im Fall von CVE-2026-6553 ist genau das der Punkt, an dem die Mehrarbeit liegt.

Die Frage lautet nicht, ob 14.3.0 bei Ihnen ausgerollt ist. Sie lautet, ob die be_users-Tabelle in Ihrer produktiven Datenbank heute noch die Spuren von 14.2.0 trägt — und ob jemand das systematisch überprüft hat.

Eine längere Aufarbeitung mit konkreten SQL-Snippets für die Bereinigung von be_users.uc und user_settings und einer Einordnung, warum eine Karenzzeit auf LTS-Minor-Releases für TYPO3 strukturell sinnvoll ist, findet sich unter ole-hartwig.eu.