CVE-2026-47347: Open Redirect Vulnerability in TYPO3 CMS GeneralUtility::sanitizeLocalUrl

The TYPO3 Content Management System exposes an attack surface via input parameters that dictate downstream HTTP redirections. TYPO3 Core relies on the GeneralUtility::sanitizeLocalUrl function to ensure user-controlled destination strings are confined to safe, local directory paths. This function serves as the central control mechanism for preventing open redirect vectors across both core components and third-party extensions.

The core issue lies in the validation method's failure to address browser-level URL parsing and normalization behavior. While the utility is designed to validate relative paths, it incorrectly classifies structurally malformed strings as local paths. This discrepancy exposes applications to Open Redirect (CWE-601) exploits, where malicious external domains can be disguised as benign internal links.

An attacker can exploit this flaw to orchestrate highly targeted spearphishing or credential harvesting campaigns. Users clicking on a trusted link containing the bypass payload are silently redirected to a malicious destination. This degrades the perceived trustworthiness of the host application, facilitating secondary exploitation vectors.

The root cause of CVE-2026-47347 is a parser differential between the server-side validation logic and client-side web browser normalization rules. When processing an input URL, GeneralUtility::sanitizeLocalUrl historically used a simple blocklist strategy. It scanned the target string for only three characters: the newline (\n), carriage return (\r), and the null byte (\x00).

If these three characters were absent, the function assumed the path was safe to treat as local. It failed to validate the presence of other control characters, such as vertical tabs (\v), form feeds (\f), or backslash delimiters (\). PHP's native parsing and string operations did not treat a sequence starting with backslashes (e.g., \\evil.com) as a valid absolute URL, leading the application to classify it as a relative path.

Conversely, modern web browsers, following the WHATWG URL Living Standard, auto-normalize backslashes to forward slashes before making network requests. When a browser receives a Location: \\\\attacker.com HTTP response header, it normalizes the target to //attacker.com. The browser parses this as a protocol-relative URL and redirects the user's connection to the external domain, bypassing the application's intended restrictions.

Prior to the security patch, the vulnerable logic in typo3/sysext/core/Classes/Utility/GeneralUtility.php checked for forbidden control characters via strpbrk. It did not apply a structured character whitelist. This blocklist approach allowed any invalid characters not specified in the blocklist to flow to the redirection engine.

// Vulnerable Implementation
public static function sanitizeLocalUrl(string $url): string
{
    $sanitizedUrl = '';
    if (!empty($url)) {
        // Only checks for basic newline, carriage return, and null bytes
        if (strpbrk($url, "\n\r\x00") !== false) {
            static::getLogger()->notice('URL "{url}" contains unexpected whitespace and was denied as local url.', ['url' => $url]);
            return '';
        }
        // Downstream parsing continues, mistakenly allowing backslashes
        ...

The patch introduces a strict RFC 3986 compliance check, switching the design paradigm from a blocklist to a robust whitelist. It defines an explicit array of allowed characters containing alphanumerics, unreserved characters, and valid percent-encoding or scheme-delimiting symbols.

// Patched Implementation
public static function sanitizeLocalUrl(string $url, ServerRequestInterface $req = null): string
{
    $sanitizedUrl = '';
    if (!empty($url)) {
        $validUrlCharacters = [
            // Percent-Encoding
            '%',
            // Reserved Characters (gen-delims & sub-delims)
            ':', '/', '?', '#', '[', ']', '@',
            '!', '$', '&', '\'', '(', ')', '*', '+', ',', ';', '=',
            // Unreserved Characters (ALPHA & DIGIT)
            '-', '.', '_', '~',
            'a', 'b', 'c', 'd', 'e', 'f', 'g', 'h', 'i', 'j', 'k', 'l', 'm', 'n', 'o', 'p', 'q', 'r', 's', 't', 'u', 'v', 'w', 'x', 'y', 'z',
            'A', 'B', 'C', 'D', 'E', 'F', 'G', 'H', 'I', 'J', 'K', 'L', 'M', 'N', 'O', 'P', 'Q', 'R', 'S', 'T', 'U', 'V', 'W', 'X', 'Y', 'Z',
            '0', '1', '2', '3', '4', '5', '6', '7', '8', '9',
        ];
 
        // Remove all valid characters; if any remain, the URL is invalid
        $hasInvalidCharacters = str_replace($validUrlCharacters, '', $url) !== '';
        if ($hasInvalidCharacters) {
            static::getLogger()->notice('The URL "{url}" contains unexpected characters and was denied as local url.', ['url' => $url]);
            return '';
        }

By utilizing str_replace, the patched code effectively strips all legitimate URL characters from the input. If any character remains, the string contains illegal symbols such as backslashes or non-standard control characters. The function logs a notice and returns an empty string, completely preventing downstream execution of dangerous inputs.

Exploiting this vulnerability requires the presence of an endpoint that accepts a destination URL parameter and processes it via GeneralUtility::sanitizeLocalUrl before initiating a redirect. Standard vectors include authentication forms, language selection switches, or custom payment processing and back-to-origin flows.

An attacker crafts an exploitation vector by supplying a protocol-relative address masked with backslashes. For example, the input \\attacker-controlled-site.com is submitted as the return path. Since the server does not find any blocked control characters (\n, \r, or \x00), it allows the input to pass to the client browser via a Location header.

Other payload variants leverage mixed slashes and control characters to achieve the same result. Payloads such as \v//attacker-controlled-site.com or \x0c//attacker-controlled-site.com evade simplistic regex checks while inducing browser-level normalization. The visual structure of the target URL remains masked in the user's initial interface, decreasing the likelihood of detection prior to execution.

The severity of CVE-2026-47347 is rated as Medium with a CVSS v4.0 score of 5.3. Although it does not permit arbitrary code execution or direct compromise of local system files, the vulnerability significantly undermines the session integrity of application clients. An attacker can use the open redirect to masquerade external landing pages as trusted local modules.

This technique corresponds to MITRE ATT&CK technique T1566.002 (Spearphishing Link). Phishing filters and email security gateways often trust links targeting legitimate enterprise TYPO3 domains. By routing malicious links through the open redirect, attackers bypass automated detection, facilitating high-yield phishing and credential harvesting campaigns.

The EPSS score of 0.00484 indicates a low immediate probability of mass automated exploit campaigns, which is typical for open redirect vulnerabilities. However, because this vulnerability involves a core helper utility in TYPO3 CMS, any third-party extensions using sanitizeLocalUrl are equally exposed. Organizations should immediately prioritize patching to prevent targeted social engineering campaigns against their users.

The primary remediation path is upgrading the TYPO3 installation to the patched releases. The TYPO3 security team has released security updates covering all active LTS and ELTS branches. Administrators should verify their core versions match or exceed 10.4.57 ELTS, 11.5.51 ELTS, 12.4.46 ELTS, 13.4.31 LTS, or 14.3.3 LTS.

If immediate patching is unfeasible, administrators can deploy defensive rules at the Web Application Firewall (WAF) layer. Because the exploit relies on raw or percent-encoded backslashes in query parameters, rules can be configured to drop incoming requests containing these patterns. A sample ModSecurity rule targetting the URI arguments and detecting double backslashes looks like this:

SecRule ARGS "@rx (?i)(?:\\|%5c){2,}[a-z0-9]" "id:1000099,phase:2,deny,status:400,log,msg:'Potential CVE-2026-47347 Open Redirect Bypass Attempt'"

Additionally, network-level intrusion detection systems (IDS) can flag these exploitation attempts. A Snort rule focusing on the raw parameters within incoming HTTP request payloads can alert administrators to validation bypass attempts:

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"TYPO3 sanitizeLocalUrl Open Redirect Bypass Attempt"; flow:established,to_server; content:"/alt_intro.php"; http_uri; content:"\\"; http_uri; sid:1000001; rev:1;)