CVE-2026-123339 in Symfony
Summary
by MITRE • 11/06/2026
Improper trust of forwarded headers in RouterListener::onKernelFinishRequest() in Symfony HttpKernel versions prior to 5.4.56, 6.x prior to 6.4.50, 7.x prior to 7.4.23, and 8.x prior to 8.1.11 allows a remote attacker to control the host, scheme, and port of absolute URLs generated for the rest of the request, poisoning links in pages stored by a shared cache and in e-mails sent after the page was rendered.When a page renders an inline fragment (render() in Twig, or an ESI tag rendered inline), SubRequestHandler temporarily adds 127.0.0.1 to the trusted proxies, and RouterListener rebuilds the router context from the main request while that trust is still active, so the X-Forwarded-* and Forwarded headers of a request whose client address is 127.0.0.1 are trusted even though that address is not a configured trusted proxy. From that point on, every absolute URL the router generates for the rest of the main request takes its host, scheme, and port from headers sent by the client, including URLs produced by url() in Twig and by UrlGeneratorInterface::ABSOLUTE_URL.
Applications are affected when they are reached over HTTP from 127.0.0.1, for example behind a TLS terminator, reverse proxy, local HTTP cache, or sidecar proxy on the same host, and that proxy passes the client’s forwarded headers along. With the default configuration (framework.trusted_proxies unset), all forwarded headers, including X-Forwarded-Host, are trusted during that window. Applications served through php-fpm, mod_php, or a proxy on another host are not affected. When framework.trusted_hosts is configured, a forwarded host outside the list is rejected, but the scheme and port can still be changed.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 11/06/2026
The vulnerability identified in Symfony HttpKernel versions prior to 5.4.56, 6.x prior to 6.4.50, 7.x prior to 7.4.23, and 8.x prior to 8.1.11 represents a critical flaw in the framework's handling of forwarded HTTP headers during specific request processing phases. This issue stems from an improper trust mechanism within the RouterListener::onKernelFinishRequest() method, which allows remote attackers to manipulate the host, scheme, and port parameters used when generating absolute URLs. The core technical failure occurs because Symfony temporarily expands its list of trusted proxies to include 127.0.0.1 during the rendering of inline fragments or Edge Side Include tags. This temporary expansion is intended to allow internal sub-requests to function correctly behind local proxies, but it inadvertently creates a window where headers from any client connecting via localhost are treated as if they originated from a trusted infrastructure component. Consequently, when RouterListener rebuilds the router context during this specific phase, it accepts X-Forwarded-* and Forwarded headers sent by an attacker who can reach the application through 127.0.0.1, such as those behind a TLS terminator, reverse proxy, local HTTP cache, or sidecar proxy on the same host that forwards these client-supplied values.
The operational impact of this vulnerability is significant for applications relying on shared caching mechanisms and email generation systems. Because the router context is poisoned with attacker-controlled header data during the fragment rendering phase, every absolute URL generated subsequently in the main request inherits these malicious parameters. This includes URLs produced by standard template functions like url() in Twig or implementations of UrlGeneratorInterface::ABSOLUTE_URL. The primary consequence is cache poisoning and email link manipulation. Attackers can inject their own domain names into links stored within shared caches, causing all subsequent users accessing that cached content to be redirected to malicious sites rather than the legitimate application host. Similarly, if emails are generated after such a page render, they will contain phishing links pointing to attacker-controlled infrastructure instead of the intended service endpoints. This undermines user trust and can facilitate broader attack chains including credential theft or malware distribution through compromised email communications.
From a classification perspective, this vulnerability aligns with CWE-94 Improper Control of Generation of Code (Code Injection) in its application-specific context where dynamic URL generation is manipulated, but more accurately maps to CWE-15 External Control of System or Configuration Setting regarding the misconfiguration of trusted proxy logic. In terms of offensive security frameworks, it corresponds to MITRE ATT&CK technique T1078 Valid Accounts if used in conjunction with compromised internal services, though primarily it represents a configuration-based vulnerability exploitation path often categorized under Improper Input Validation (CWE-20) leading to Cache Poisoning. The risk is mitigated by the fact that applications served through php-fpm or mod_php without local proxy intermediaries are not affected, as they do not receive forwarded headers from 127.0.0.1 in this manner. Furthermore, if framework.trusted_hosts is explicitly configured with a whitelist of allowed hosts, requests containing host values outside this list will be rejected by the router listener itself, providing a partial defense against host manipulation. However, even when trusted hosts are configured, the scheme and port remain vulnerable to modification because the header trust logic operates independently of the host validation check during the fragment rendering window.
To mitigate this vulnerability, organizations must upgrade their Symfony HttpKernel components to versions 5.4.56 or later for the 5.x branch, 6.4.50 or later for the 6.x branch, 7.4.23 or later for the 7.x branch, and 8.1.11 or later for the 8.x branch. For environments where immediate upgrading is not feasible, administrators should ensure that framework.trusted_hosts is strictly configured to whitelist only legitimate domain names associated with their application. While this does not fully prevent scheme and port manipulation due to the architectural separation of host validation from header trust logic in the vulnerable code path, it significantly reduces the attack surface by preventing the acceptance of arbitrary host values. Additionally, reviewing proxy configurations to ensure that X-Forwarded-* headers are only passed when strictly necessary and originating from verified internal infrastructure can help reduce exposure. Developers should also audit any custom implementations or extensions that interact with RouterListener or sub-request handling to ensure they do not inadvertently extend trust boundaries beyond the intended scope during inline fragment processing.