Traffic Cop Gone Rogue: Hijacking TYPO3 Redirects

TYPO3 is the heavy lifter of the CMS world. It is built for enterprise complexity, specifically the ability to host dozens of disparate websites on a single installation. The security model relies heavily on a concept called Webmounts. Think of a Webmount as a sandbox; if you are an editor for blog.example.com, your Webmount restricts you to that specific branch of the page tree. You shouldn't even know corporate.example.com exists.

However, software architecture is like a chain—it is only as strong as its weakest link. In this case, the weak link was the system extension ext:redirects. This module handles URL forwarding, a critical function for SEO and marketing.

Here is the punchline: While TYPO3 rigorously checked if you were allowed to edit pages within your mount, the Redirects module simply checked if you had permission to write to the sys_redirect database table. It forgot to check which redirects you were touching. It's like giving a janitor keys to the building but forgetting to lock the CEO's office.

The vulnerability is a textbook case of CWE-862: Missing Authorization. In technical terms, the application performed a Class-Level access check but failed to perform an Object-Level access check.

When a backend user accesses the Redirects module, the system loads records from the sys_redirect table. In the vulnerable versions (10.x through 14.x), the controller logic looked something like this:

1. Authentication: Is the user logged in? (Yes)
2. Module Access: Does the user have access to the 'Redirects' module? (Yes)
3. Table Access: Does the user have edit permissions for the sys_redirect table? (Yes)

If those three checks passed, the controller served up every redirect in the database. It ignored the source_host field, which binds a redirect to a specific domain. Consequently, our hypothetical blog editor could see—and modify—redirects belonging to the root domain or other client sites hosted on the same server.

The fix, orchestrated by the TYPO3 Security Team, involved retrofitting a granular permission model onto the existing module. They couldn't just patch a line; they had to invent a new authorization layer.

The Fix Components:

1. SourceHostProvider: A new service that acts as the source of truth. It calculates exactly which hostnames a user is allowed to touch by analyzing their Webmounts and matching them against Site Configurations.

2. RedirectPermissionGuard: This is the bouncer. Before any action is taken on a redirect record, this guard verifies two things: Is the source_host in the user's allowed list? And, if the target is an internal page, is that page within the user's Webmount?

The Diff Logic:

Previously, the repository might have executed a query roughly equivalent to:

// Vulnerable: Fetch everything if the user has table access
return $query->execute();

The patched version injects a mandatory constraint for non-admin users:

// Patched: Fetch only what the user owns
if (!$this->security->isAdmin()) {
    $allowedHosts = $this->sourceHostProvider->getAllowedHosts();
    $query->matching($query->in('source_host', $allowedHosts));
}

Furthermore, they implemented a DataHandler Hook. This is crucial because savvy attackers don't always use the UI; they might send raw HTTP requests to the core DataHandler. The hook ensures that even direct API manipulation attempts are blocked if the user lacks authority over the specific source_host.

Let's construct a realistic attack scenario. Assume we have a compromised low-privileged account, Bob, who manages campaign-site.com on a shared TYPO3 instance that also hosts main-bank.com.

Step 1: Reconnaissance Bob logs into the backend and opens the Redirects module. Because of the flaw, the list isn't filtered. He searches for redirects associated with main-bank.com.

Step 2: The Setup Bob finds a redirect that is frequently used, or he decides to create a new one. He creates a redirect record:

• Source Host: main-bank.com
• Source Path: /support-portal
• Target: https://attacker-controlled-site.com/fake-login

Step 3: Execution Bob saves the record. Because he has write access to the sys_redirect table (intended for his campaign site), the system accepts the row. The application logic fails to validate that main-bank.com is not in Bob's Webmount.

Step 4: The Impact Users visiting main-bank.com/support-portal are now silently bounced to Bob's phishing page. To the user, the link looked legitimate coming from the main domain. Bob collects credentials, and the TYPO3 admins are none the wiser until a user complains.

This isn't a configuration issue you can fix with a checkbox. The logic gap is deep within the PHP classes of the extension. You must upgrade.

Version Targets:

• v10: Upgrade to 10.4.55 (ELTS)
• v11: Upgrade to 11.5.49 (ELTS)
• v12: Upgrade to 12.4.41 (LTS)
• v13: Upgrade to 13.4.23 (LTS)
• v14: Upgrade to 14.0.2

Post-Patch Audit: After patching, run a sanity check on your sys_redirect table. Look for redirects where the source_host does not match the expected domain for the cruser_id (creator user ID). If User A only manages Domain A, but created records for Domain B, you have a breach.