TYPO3's Fatal Typo: How One CamelCase Character Allowed RCE

In the world of secure coding, intent means nothing. Implementation is everything. The developers behind TYPO3, one of the enterprise world's favorite Content Management Systems, intended to write secure code. They knew that PHP's unserialize() function is a loaded gun pointed at the foot of any application that uses it. They tried to use the safety mechanism introduced way back in PHP 7.0: the allowed_classes filter.

But they made one fatal mistake: they respected the variable naming conventions of their own codebase (camelCase) rather than the snake_case requirements of the PHP interpreter. They wrote 'allowedClasses' instead of 'allowed_classes'.

This is the story of CVE-2026-0859, a vulnerability that proves that in PHP, a single capital letter can be the difference between a rejected packet and a root shell. It highlights a terrifying behavior in PHP: when you pass an invalid option to a security function, it often doesn't throw an error—it just silently ignores you and proceeds as if you hadn't tried to secure it at all.

To understand this vulnerability, you have to appreciate the awkward evolution of PHP object injection. For years, unserialize() was simply unsafe. Then, PHP 7 introduced a chaotic-good feature: the options array. This allows developers to pass a whitelist of classes that are allowed to be instantiated. If an attacker tries to inject a GuzzleHttp\Client object to trigger a destructor gadget, but the whitelist only allows stdClass, the exploit fails.

Here is where the logic flaw occurred. The TYPO3 FileSpool class manages queued emails by saving them to disk and reading them back later. To read them back, it uses unserialize. The developers passed an array of safe mail-related classes (like RawMessage, Email, etc.) to the function.

However, because they used the key allowedClasses (notice the capital 'C'), PHP's internal engine looked at the options array, didn't see the expected allowed_classes key, and shrugged. It defaulted to allowed_classes => true, which means "allow everything." The filter was effectively nonexistent. The code looked secure during code review, but it was functionally wide open.

Let's look at the diff. It is rare to see a vulnerability so starkly defined by a syntax error. This isn't a complex logic race condition; it's a typo.

The Vulnerable Code (Simplified):

// TYPO3/CMS/Core/Mail/FileSpool.php
$message = unserialize((string)file_get_contents($file), [
    // The fatal mistake: CamelCase key is ignored by PHP
    'allowedClasses' => [
        RawMessage::class,
        Message::class,
        Email::class,
        // ... list of safe classes
    ],
]);

The Patch (Commit 3225d705...):

In the fix, the developers didn't just correct the typo; they completely overhauled the deserialization logic. They realized that trusting unserialize with a simple list might be fragile given the complexity of Symfony Mailer objects. They introduced a PolymorphicDeserializer that pre-scans the string.

// The Fix: Using a wrapper and correct keys
$message = $this->deserializer->deserialize(
    (string)file_get_contents($file),
    [
        SentMessage::class,
        RawMessage::class,
        // ...
    ]
);

Internally, that deserializer ensures the payload doesn't contain dangerous object markers before even letting PHP touch it. They went from "oops, typo" to "defense-in-depth."

So, we have an insecure deserialization sink. How do we reach it? This vulnerability is classified as AV:L (Local) because the input vector comes from a file on disk: the mail spool.

Step 1: The Gadget Chain TYPO3 is built on top of Symfony components and includes a massive amount of dependencies (Guzzle, Doctrine, etc.). This is a playground for tools like PHPGGC. An attacker would generate a payload using a standard chain, for example, Monolog/RCE1 or a generic Symfony/RCE chain, wrapping a command like id or a reverse shell.

Step 2: The Delivery The attacker needs to write this payload to the configured transport_spool_filepath. If the attacker has compromised a low-privileged account (e.g., via an unrestricted file upload or a separate LFI), they can drop a file named payload.sending into the spool directory.

Step 3: The Trigger The beauty (and horror) of this exploit is that the attacker doesn't need to trigger it manually. TYPO3 relies on a scheduler (cron job) to flush the mail queue. The attacker plants the bomb and walks away. When the system administrator's cron job runs typo3 mailer:spool:send, the script iterates over the directory, reads payload.sending, and deserializes it. Boom—code execution running as the user invoking the scheduler (often the web user or even root/cron user).

While the requirement for local file write lowers the CVSS score to a 7.8, the impact is undeniably critical. This acts as a privilege escalation or persistence mechanism. If an attacker can write to the spool but cannot execute PHP directly (perhaps due to disable_functions or WAF rules blocking direct execution), this vulnerability bypasses those restrictions.

The deserialization happens deep within the core framework logic, often outside the context of the web request, meaning it might bypass web-based intrusion detection systems (WAFs) entirely. Furthermore, because it executes during the scheduler run, it could potentially escalate privileges if the scheduler is run by a user with higher permissions than the web server itself.

The remediation is straightforward: Update. The patch versions (10.4.55, 11.5.49, 12.4.41, 13.4.23, 14.0.2) contain the fix. The fix is robust; it moves away from the fragile unserialize allow-list and implements a rigorous check on the serialized string content before processing.

Defensive Strategy:

1. Update Immediately: This is the only sure fix.
2. Disable File Spooling: If you don't need to queue emails to disk, don't. Configure TYPO3 to send emails immediately (transport_spool_type = memory) or use a proper SMTP server without local spooling. This removes the attack surface entirely.
3. Check Permissions: Ensure your var/spool or fileadmin directories are not writable by untrusted users. If an attacker can't write the file, they can't trigger the deserialization.