CVE-2026-121619: Symfony: The "private_ranges" Trusted Proxies Shortcut Trusts Clients Presenting an IPv4-Mapped, 6to4, Teredo or NAT64 Address as Reverse Proxies

Published Nov 12, 2026
·
Updated

The Symfony FrameworkBundle framework.trustedproxies option and the HttpFoundation Request::setTrustedProxies() method trust remote clients as reverse proxies when the privateranges shortcut is used, allowing remote attackers to spoof the client IP address, host and scheme in Symfony FrameworkBundle versions 7.1 prior to 7.4.23 and 8.x prior to 8.1.11, and HttpFoundation versions 7.2 prior to 7.4.23 and 8.x prior to 8.1.11. The privateranges and PRIVATESUBNETS keywords resolved to IpUtils::PRIVATESUBNETS, the deny list of NoPrivateNetworkHttpClient, which lists the private and special-purpose prefixes a server must not connect to. Since the fix for CVE-2026-48736 (7.4.13 and 8.0.13), this list also covers the IPv6 prefixes that embed an IPv4 address: IPv4-mapped (::ffff:0:0/96), IPv4-compatible (::/96), 6to4 (2002::/16), Teredo (2001::/32) and NAT64 (64:ff9b::/96). The IPv4-mapped entry has been in the list since the privateranges shortcut was introduced, in 7.1 for framework.trustedproxies and in 7.2 for Request::setTrustedProxies(). Over-blocking is safe for a deny list, but when the same entries are used as the allow list of trusted proxies, they trust remote clients. A client whose connection arrives with such a source address is treated as a reverse proxy, and the X-Forwarded-For, X-Forwarded-Host, X-Forwarded-Proto, X-Forwarded-Port and X-Forwarded-Prefix headers it sends are honoured. For example, with Request::setTrustedProxies(['privateranges'], ...), a request with REMOTEADDR set to ::ffff:203.0.113.7 and the headers X-Forwarded-For: 10.0.0.9, X-Forwarded-Host: evil.example.com and X-Forwarded-Proto: https makes getClientIp() return 10.0.0.9, getHost() return evil.example.com and isSecure() return true. Two kinds of deployments are exposed: a server listening on the IPv6 wildcard address without IPV6V6ONLY reports every IPv4 client in the IPv4-mapped form, so every client is trusted, and a server reachable over IPv6 trusts any client sourcing from 6to4 or Teredo space, which is globally routed, whatever its listener. A spoofed client address defeats IP allow lists, rate limiting and audit logs; a spoofed host poisons the URLs written into password reset and login link e-mails and into shared caches; a spoofed scheme satisfies requireschannel: https over plain HTTP. Symfony 6.4 does not point any trusted proxy setting at IpUtils::PRIVATESUBNETS and is not affected by default, but an application that passes that constant to Request::setTrustedProxies() itself could be exposed in the same way on any version. This issue is fixed in 7.4.23 and 8.1.11.

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade Symfony FrameworkBundle and HttpFoundation to a version that resolves this vulnerability.

    Fixed in 7.4.23
  2. Upgrade

    Upgrade Symfony FrameworkBundle and HttpFoundation to a version that resolves this vulnerability.

    Fixed in 8.1.11

Event History

Nov 12, 2026
CVE Published
via MITRE·06:05 PM
Data Sourced
via MITRE·06:05 PM
DescriptionWeakness

Frequently Asked Questions

1

Which Symfony configurations are affected?

The issue affects applications that use the private_ranges shortcut in framework.trusted_proxies or pass private_ranges or PRIVATE_SUBNETS to Request::setTrustedProxies(). FrameworkBundle exposure begins in 7.1, while Request::setTrustedProxies() exposure begins in 7.2.

2

What does an attacker need to do to exploit this?

An attacker must be able to connect as a remote client while presenting an IPv4-mapped, IPv4-compatible, 6to4, Teredo, or NAT64 address. The affected configuration can then treat that client as a trusted reverse proxy, allowing spoofing of the client IP address, host, and scheme.

3

What versions contain the fix?

Upgrade FrameworkBundle 7.1 through 7.4 to 7.4.23 or later, or upgrade 8.x to 8.1.11 or later. Upgrade HttpFoundation 7.2 through 7.4 to 7.4.23 or later, or 8.x to 8.1.11 or later.

4

What can be done if an upgrade cannot happen immediately?

Do not use private_ranges or PRIVATE_SUBNETS as the trusted-proxy allow list. The issue results from using entries intended as a deny list for outbound connections as an allow list of trusted reverse proxies.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203