CVE-2025-59020: The 'Trust Me Bro' Vulnerability in TYPO3 CMS

TYPO3 is the enterprise heavy lifter of the CMS world. It’s complex, granular, and usually pretty good about telling you "No." Specifically, the backend uses a massive configuration array (TCA) to decide exactly which fields a user can see or touch. If you are a lowly Editor, you might be allowed to write the bodytext of an article, but absolutely forbidden from touching the hidden flag or the access_group settings. Those are for the adults in the room.

Enter the EditDocumentController. Its job is to render the form for creating or editing records. To be helpful, it accepts a parameter called defVals (Default Values). The idea is innocent enough: if you create a new record, maybe you want to pre-fill the date or a category ID to save time. It's the digital equivalent of a butler saying, "Shall I pre-select the 1982 Bordeaux, sir?"

But here is where things get dark. In cybersecurity, we have a golden rule: Input is the enemy. If you treat user input as trusted system instructions, you are going to have a bad time. The developers of TYPO3 made a classic mistake—they took the user's suggestion for default values and handed it directly to the database engine as a trusted command, effectively letting the user say, "Actually, I'll take the keys to the wine cellar instead."

To understand this exploit, you have to understand the TYPO3 DataHandler. This class is the bouncer. It stands between the HTTP request and the database. When you submit a form, the DataHandler iterates through every field, checks your user group's Access Control List (ACL), and looks at the TCA exclude fields. If you try to submit a value for a field you don't have access to, the DataHandler silently strips it out. Access Denied.

However, the DataHandler has a backdoor for the system itself, a property called $defaultValues. This property is intended for values that the system needs to set automatically—values that shouldn't necessarily trigger permission checks because the system (presumably) knows what it's doing.

The vulnerability lies in how the EditDocumentController connected the two. Before the patch, the controller took the raw $_GET['defVals'] array—controlled entirely by the attacker—and assigned it directly to the $dataHandler->defaultValues property.

[!WARNING] The Logic Gap: The code essentially said: "Here are the values the user submitted (CHECK THESE), and here are the values the user put in defVals (TRUST THESE BLINDLY)."

Because the DataHandler assumes defaultValues come from a trusted internal source, it applies them to the new record without running the standard checkFieldEditAccess routine. It’s a classic privilege escalation via trusted input channel abuse.

Let's look at the diff. It's subtle, but it makes all the difference in the world. This is primarily located in EXT:backend/Classes/Controller/EditDocumentController.php.

The Vulnerable Code

Before the fix, the controller simply passed the property along. It didn't care what was inside defVals. It could be innocent data, or it could be a restricted system flag.

// ... inside processRequest or similar logic
 
// ❌ CRITICAL FAIL: Assigning user input to trusted property
$dataHandler->defaultValues = $this->defVals ?? [];
 
// Then we start the data processing
$dataHandler->start($dataMap, $cmdMap);
$dataHandler->process_datamap();

The Fixed Code

The patch changes the philosophy entirely. Instead of slipping defVals into the trusted defaultValues side door, the patch forces these values into the main $dataMap. This is the "untrusted" bucket. By merging them here, they are forced to walk through the front door—right past the DataHandler bouncer.

// ✅ THE FIX: Merge defVals into the untrusted dataMap
 
if (is_array($dataMap)) {
    foreach ($dataMap as $tableName => $records) {
        // Check if we have default values for this table
        if (is_array($this->defVals[$tableName] ?? null)) {
            foreach ($records as $uid => $_) {
                // Only apply to NEW records
                if (str_contains((string)$uid, 'NEW')) {
                    // Merge! Now these values will be subject to
                    // standard permission checks later in the pipeline.
                    $dataMap[$tableName][$uid] = array_merge(
                        $this->defVals[$tableName],
                        $dataMap[$tableName][$uid]
                    );
                }
            }
        }
    }
}
 
// The trusted property is no longer used for user input
// $dataHandler->defaultValues = ... (Removed)

By moving the data, the developers ensured that if a user tries to set a field they can't access, checkFieldEditAccess will see it in the $dataMap, realize the user is unauthorized, and discard it.

Exploiting this requires a valid backend account. You don't need to be an admin; you just need permission to create some record (like a Content Element) and have some fields restricted from you. This is a very common scenario in enterprise TYPO3 setups where editors are locked down tightly.

The Setup:

1. Target: tt_content table.
2. Restricted Field: subheader (or hidden, starttime, fe_group). Let's say your admin explicitly set exclude=1 on subheader so you can't touch it.
3. Goal: Write "HACKED" into the subheader field.

The Attack: Normally, when you save a record, the POST request sends data like data[tt_content][NEW123][bodytext]=Hello. If you try to send data[tt_content][NEW123][subheader]=HACKED, the backend ignores it because you lack permission.

But, we can abuse the defVals query parameter when opening the creation wizard or submitting the request.

POST /typo3/record/edit?edit[tt_content][NEW123]=new&defVals[tt_content][subheader]=HACKED HTTP/1.1
Host: vulnerable-typo3.com
Cookie: be_typo_user=...
 
(Standard POST body)

The Result:

1. EditDocumentController reads defVals.
2. It sets $dataHandler->defaultValues['tt_content']['subheader'] = 'HACKED'.
3. DataHandler processes the main data. It checks permissions for bodytext (allowed).
4. DataHandler creates the SQL INSERT statement.
5. It sees the defaultValues array. It assumes these are system mandates. It adds subheader = 'HACKED' to the query.
6. Record created. Access control bypassed.

A CVSS score of 5.3 might make this sound like a "medium" severity snooze-fest, but context is king. In a complex CMS, "Integrity" is everything. This vulnerability allows for horizontal and vertical privilege escalation within the scope of content management.

Scenario 1: Defacement / SEO Poisoning An attacker with limited rights could inject scripts or spam into fields that are normally hidden from them (e.g., raw HTML headers, SEO keywords, or redirects) which the frontend renders blindly because it trusts the CMS data.

Scenario 2: Workflow Bypass Many TYPO3 installations use the hidden or starttime fields to control publication workflows. A junior editor might draft content, but only a senior editor can "unhide" it. With this exploit, the junior editor can force the hidden=0 flag via defVals during creation, instantly publishing unapproved content to the live site.

Scenario 3: Access Control List Manipulation If the attacker creates a User Group record (if they have create perms there) and uses defVals to inject specific ACL bits into fields they shouldn't see, they might be able to grant themselves wider access or create backdoors for later use.

It's not a remote root shell, but it creates a chaotic environment where the concept of "Least Privilege" is effectively null and void for record creation.

The mitigation is straightforward: Update. The patch provided by TYPO3 doesn't just block a specific keyword; it fundamentally refactors the data flow to ensure security consistency.

Remediation Steps:

1. Composer Update: Run composer update typo3/cms-backend immediately.
2. Verify Versions: Ensure you are on one of the patched versions: 10.4.55, 11.5.49, 12.4.41, 13.4.23, or 14.0.2.
3. Audit Logs: Check your sys_log table for record creations where restricted fields were modified. This is tricky since the logs might just show the record being created, but anomalous data in restricted fields is a red flag.

Developer Lesson: Never assume that a variable used for "internal logic" (like default values) is safe from external manipulation if there is a direct path from $_GET or $_POST to that variable. Always funnel user input through your most rigorous validation logic, no matter how "helpful" the feature is intended to be.