When the CMS writes backend passwords in plain text: TYPO3 14.2 and CVE-2026-6553

TL;DR — the 90-second summary

CVE-2026-6553

The backend user settings module in TYPO3 14.2.0 serialises sensitive fields together with UI preferences — passwords end up in plain text in be_users.uc and user_settings

Affected version

only TYPO3 14.2.0 — 14.1.x and earlier are not affected, 14.3.0 is the fix

Database touch

updating to 14.3.0 is not enough — the columns must be cleaned and all backend passwords force-rotated

Follow-on problem

backups from the 14.2.0 window contain plain-text passwords — their classification changes

Four guardrails

maturation window for LTS minors, Composer lockfile, sensitive backup classification, structured cleanup rather than only patching

NIS-2 lever

authentication-data protection is mandatory — without inventory and audit log the incident cannot be reconstructed after the fact

 

What is the problem?

On 24 April 2026 the TYPO3 security team published the advisory for CVE-2026-6553. Only version 14.2.0 (LTS) is affected: in the new backend user-settings module, sensitive fields such as passwords were serialised together with the usual UI settings and ended up in plain text in the columns uc and user_settings of the be_users table. The official fix version is 14.3.0.

It is a classic separation flaw in the data model. In TYPO3, backend settings (UI preferences) and identity attributes (password, email) have historically sat on two separate paths because the one path has to be handled differently from the other — with hashing, with audit logging, with a clear source of truth. In 14.2.0 that separation was dropped in the new module. The result is a database that has lost part of its own protection layer — without it being visible during normal operation.

For us as an agency operating TYPO3 in client setups, that was a short Sunday evening of counting rows. No-one on our managed platforms had used the 14.2.0 backend user-settings module in a way that would have triggered the issue. That is not coincidence — it is the consequence of our policy not to install TYPO3 LTS major and minor updates on the day of release.

Impact: plain-text passwords are not only a backup problem

The code runs, the backend responds, the login works. The only thing broken is an invisible assumption — namely that the contents of the be_users table consist of a hashed password field and otherwise harmless UI data. Anyone building on that assumption (because they classify backups as non-sensitive or do not audit database read access) now carries the risk in their routines without noticing.

Backups become retroactively more sensitive

Anyone who took a backup during the window in which 14.2.0 was in production — hosting, internal job, external service provider — potentially has plain-text passwords in their backup pool. That turns every such backup into a sensitive data carrier and changes the requirements for storage, access and disposal.

Password reuse becomes a cross-system risk

Backend users in TYPO3 are often not only editors but external partners, agencies, test accounts. The assumption that these people assign a unique strong password to every system rarely survives a sober check. A plain-text password stored in be_users.uc can therefore open other systems where TYPO3 itself is not in play at all.

NIS-2 makes it a documented incident

NIS-2 explicitly requires protection of authentication data in risk management as well as defined patch management. Anyone in NIS-2 scope is required to reconstruct an incident of this class in a structured way — namely: which systems were affected, which backups, which people, which follow-up measures. Without a clean inventory and an audit log, that cannot be delivered after the fact.

Who is affected?

At the core: every TYPO3 installation that actively rolled out the LTS minor between the 14.2.0 release and the 14.3.0 patch. Three constellations are particularly relevant.

• Multisite setups with a shared be_users table — a single backend login on 14.2.0 contaminates the whole installation. Anyone running multiple sites on one database has the biggest cleanup load.
• Hosting with externally-managed backups — managed-hosting providers and external backup vendors now potentially know plain-text passwords of your editors. Classification and, if necessary, a deletion request are required.
• External accounts with backend access — agencies, freelancers, QA testers. Exactly this group frequently uses backend accounts with passwords that also circulate elsewhere (Slack, Jira, their own email).

Anyone who never ran 14.2.0 in production, or who switched to 14.3.0 before 24 April 2026, is not directly affected. Backups from the 14.2.0 window remain sensitive data carriers regardless.

Mitigation and immediate actions — four steps, in this order

Quick start in the order in which we are currently cleaning up. Each step assumes the previous one.

# 1. Apply the update (Composer-based)
composer require typo3/cms-core:^14.3.0 --update-with-dependencies
vendor/bin/typo3 upgrade:run

# 2. Inspect and clean the be_users table
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. Forced password reset for all backend users
mysql -e "UPDATE be_users SET password = '', \
         tx_extbase_type = 'reset_required'"

1. Maturation window for minor releases on LTS lines

In our update path, a 14.2.0 is not installed on the day of release — but only after it has survived a defined maturation period. In this concrete case the window would have been enough to wait for 14.3.0 and simply skip 14.2.0. The exception remains a known actively-exploited CVE — then we deliberately move to the new version with calculated risk.

2. Composer-based installation with a committed lockfile

For TYPO3 the same rule applies: no "latest" versions, no composer update in CI — only composer install against a versioned composer.lock. That prevents a spontaneously updated dependency from slipping unnoticed into a build. Same discipline as in our Composer CVE post.

3. Database backups classified as sensitive by default

Anyone who runs backups as "internal, confidential" by default can react to incidents like CVE-2026-6553 without having to reinvent their own classification first. That saves weeks. Retention and disposal rules are defined in the backup concept, not improvised during the incident.

4. Structured cleanup, not just an update

When a flaw compromises productive data, the update is step one of three. Step two is the cleanup of the already-stored plain-text data in be_users.uc and user_settings. Step three is the forced password reset for all backend users plus MFA enablement. Only then is the incident cleanly closed.

Detection and verification

Five core questions — in half an hour you have clarity on your incident status.

• Was 14.2.0 in production in your platform — and between which dates? A git log composer.lock on the typo3/cms-core line surfaces the window.
• Which backend users signed in during that window? SELECT username, lastlogin FROM be_users WHERE lastlogin BETWEEN ...
• Do be_users.uc or be_users.user_settings currently still contain serialised data? SELECT uid, username, LENGTH(uc) FROM be_users
• Which backups stem from the 14.2.0 window? From now on these backups are classified as "sensitive — may contain plain-text passwords".
• Which people with backend access plausibly reuse the password elsewhere? They need a reset notice that mentions exactly that — not just the TYPO3 reset.

Quick-check SQL we run before every cleanup:

-- Which be_users actually have 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;

-- Look for typical plain-text indicators
SELECT uid, username
FROM be_users
WHERE uc LIKE '%password%' OR user_settings LIKE '%password%';

Operator recommendation

What should be operationally in place for which TYPO3 setup right now — depending on where you stand today.

• If you ran 14.2.0 in production and are not yet on 14.3.0 — then the update plus the SQL cleanup plus the forced password reset this week is the only sensible path. No content releases before that.
• If you are on 14.1.x or 13.x — then 14.3.0 is the next sensible LTS minor, not the parked 14.2.0. Maturation discipline has just paid off, keep it up.
• If backups from the 14.2.0 window sit with a managed-hosting provider or external backup vendor — then a written classification update goes to the vendor, with a deletion request for the affected backup generations where appropriate.
• If you fall under NIS-2 — then structured incident documentation (inventory of affected systems, people, backups, follow-up actions) is mandatory and should not be improvised in a ticket but live in a defined incident record.
• If you have not yet enabled MFA in the backend — then this is exactly the trigger to change that. A password reset without MFA only repairs half the consequence.

Cross-references: the Composer CVE post for update discipline, the Managed Hosting post for backup classification, and the Outsourced IT Department post for embedding into NIS-2 discipline.

Conclusion

Most pipeline reviews we have done in the past months show the same pattern: TYPO3 gets patched because the update arrives. It is rarely checked whether the data set after the update still matches the assumption the update was written against. With CVE-2026-6553, that is exactly where the extra work sits.

The question is not whether 14.3.0 is rolled out at your site. It is whether the be_users table in your productive database still carries traces from 14.2.0 today — and whether anyone has systematically checked that.

A longer write-up with concrete SQL snippets for the cleanup of be_users.uc and user_settings and the reasoning why a maturation window on LTS minor releases for TYPO3 is structurally sensible is available (in German) at ole-hartwig.eu.