CVE-2026-123339 · Package
NO FIX YET · SEE WHAT TO DO
Symfony HttpKernel trusts X-Forwarded-* and Forwarded headers from 127.0.0.1 while rendering inline fragments, even when that address is not a configured trusted proxy. An attacker can then set the host, scheme and port of every absolute URL generated for the rest of the request, poisoning links in cached pages and in emails.
first public Nov 4, 2026 · 1 source
Check it with your coding agent
It checks your repository and tells you if you’re affected, with the fix.
Applications built on Symfony HttpKernel that receive HTTP requests from 127.0.0.1, such as apps behind a same-host reverse proxy, TLS terminator, local HTTP cache or sidecar that forwards client headers. Apps served through php-fpm, mod_php or a proxy on another host are not affected, and apps with framework.trusted_hosts set still have the scheme and port exposed.
Not affected if mod-php, php-fpm, proxy-on-other-host
Who cares http-kernel, php, reverse-proxy, shared-cache, symfony
composer show symfony/http-kernel and compare the version with the fixed ranges.framework.trusted_proxies is set in the Symfony configuration.5.4.566.4.50Improper 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.
Are you affected?
Tell InfraStack what you run. It checks this one, and every next one, against your stack.
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
7.4.238.1.11This page as .md · .json · CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:N/VI:L/VA:N/SC:L/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.