CVE-2026-6553: Cleartext Password Exposure in TYPO3 CMS Backend User Settings

CVE-2026-6553 is a sensitive data exposure vulnerability affecting the SetupModuleController component within the ext:backend system extension of TYPO3 CMS. The flaw is specifically isolated to version 14.2.0. The vulnerability triggers when a backend user interacts with the "User Settings" module to update profile details or change their password.

The root of the issue stems from an architectural shift introduced in TYPO3 14.2.0 regarding how backend user preferences are managed. The system stores user configuration data as serialized JSON within specific columns of the be_users table. The regression occurs because the application fails to distinguish between primary authentication fields and general user preferences during the form submission process.

While the core authentication handler correctly hashes the submitted password before writing it to the primary be_users.password column, a secondary execution path mismanages the raw POST data. The system takes the unhashed password and appends it to the user's preference array, persisting the exact plaintext string to the database. This behavior constitutes a CWE-312 (Cleartext Storage of Sensitive Information) violation.

The vulnerability originates within the storeIncomingData method of the SetupModuleController. This controller processes the incoming POST request when a user submits the settings form. The fundamental error is the absence of a strict boundary separating distinct data domains during processing.

TYPO3 utilizes a system where "virtual fields" (such as UI language, theme preferences, and layout options) are stored in a configuration object accessed via $backendUser->uc. Conversely, "database fields" (such as the authentication password or primary email) correspond directly to structural columns in the relational database. The controller is responsible for routing these fields to their appropriate storage mechanisms.

In version 14.2.0, the controller merges all submitted fields into a single flat array before processing. The logic iterates through this array without filtering out sensitive inputs. Consequently, the raw password and password2 fields are assigned directly to the $backendUser->uc object alongside benign user preferences.

An examination of the vulnerable implementation in TYPO3 14.2.0 reveals a direct assignment pattern that lacks input sanitization. The SetupModuleController loops over the submitted configuration keys and populates the user object.

// Vulnerable pattern in TYPO3 14.2.0
foreach ($columns as $field => $config) {
    // The application assigns submitted values directly to the 'uc' array
    // Sensitive fields like 'password' are not excluded
    $backendUser->uc[$field] = $d[$field] ?? ''; 
}

The remediation implemented in commit 9a6e913f70767f63b322ae3e2d2f4e302624c291 resolves the flaw by introducing strict data partitioning and explicit field blocklisting. The patch defines a new constant, DISALLOWED_FIELD_NAMES, which enumerates sensitive keys that must never enter the configuration blob.

// Patched logic
private const DISALLOWED_FIELD_NAMES = ['password', 'email', 'realName', 'avatar'];
 
foreach ($columns as $field => $config) {
    if (in_array($field, self::DISALLOWED_FIELD_NAMES, true)) {
        continue;
    }
    $backendUser->uc[$field] = $d[$field] ?? '';
}

Beyond the specific blocklist, the patch refactors the form submission handling to split the data payload into two separate arrays immediately upon receipt. One array is strictly designated for primary database columns, while the other is reserved exclusively for the serialized user_settings blob. This defense-in-depth approach ensures that future additions to the user model do not inadvertently leak sensitive data.

Exploitation of CVE-2026-6553 requires an attacker to possess read access to the underlying TYPO3 database. This vulnerability functions primarily as an escalation vector rather than an initial access method. An attacker typically achieves this prerequisite access through an adjacent SQL injection vulnerability, compromised database backup files, or an unauthorized connection to the database server.

Once database access is secured, the attacker queries the be_users table and inspects the contents of the uc and user_settings columns. Because the configuration object is serialized using standard PHP formatting, the stored cleartext password is easily identifiable within the string output.

A typical compromised record will contain a serialized structure similar to s:8:"password";s:12:"mysecret123";. The attacker extracts the value mysecret123 and utilizes it to authenticate directly against the TYPO3 backend. Currently, no public exploit code or automated weaponized tools exist, given the prerequisite of database access.

The exposure of cleartext passwords directly compromises the confidentiality of backend user accounts. If an attacker successfully harvests these credentials, they can authenticate as the compromised user. In TYPO3 environments, backend user access frequently equates to comprehensive administrative control over the content management system.

Administrative access allows an attacker to alter website content, modify system configurations, and deploy malicious extensions. The capability to upload arbitrary PHP code via backend extensions results in full Remote Code Execution (RCE) on the underlying web server.

The CVSS 4.0 vector assesses this vulnerability at 7.3 (CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:N/VA:N/SC:H/SI:H/SA:H). The confidentiality metric is marked as High due to the complete exposure of the authentication string. The User Interaction (UI) metric is set to Required, as the user must actively submit the settings form to trigger the data leak. The low EPSS score (0.00029) reflects the structural requirements for exploitation, indicating a low probability of widespread automated attacks.

The primary remediation for CVE-2026-6553 requires upgrading the TYPO3 CMS installation to version 14.3.0. Deploying the patch corrects the vulnerable controller logic and prevents any future plaintext storage of passwords during profile updates. However, applying the code update does not retroactively secure data already persisted in the database.

Administrators must execute a manual database scrubbing procedure to remove existing compromised records. TYPO3 14.3.0 includes a specific upgrade wizard named "User Settings Scrubbing" (UserSettingsScrubbingMigration.php). This tool is accessible via the TYPO3 Install Tool under Admin Tools, then Upgrade, and finally Upgrade Wizard. Running this script identifies and removes leaked credentials from the uc arrays.

Following the database scrubbing process, security teams must force a password reset for all backend users. Any user who interacted with the settings module while version 14.2.0 was active must be considered compromised. To identify potentially affected rows prior to scrubbing, administrators can execute the following diagnostic SQL query:

SELECT uid, username 
FROM be_users 
WHERE uc LIKE '%"password"%' OR user_settings LIKE '%"password"%';