Symfony HttpClient EUVD-2026-44372

The application must explicitly use Symfony\Component\HttpClient\NoPrivateNetworkHttpClient as its HTTP client and must accept attacker-controlled input as the request URL or URL host - the exact use case the decorator is designed for, such as webhook processors, RSS/Atom feed fetchers, or link preview generators. On the network side, successful packet delivery to the embedded private IPv4 target additionally requires one of: a 6to4 tunnel interface on the server (for 2002::/16 payloads), an upstream NAT64 gateway in the network path (for 64:ff9b::/96 payloads), or kernel-level IPv4-compatible address handling (for ::/96 payloads, behavior is OS-dependent and often dropped on modern Linux). Teredo (2001::/32) is the broadest prefix and may overlap legitimate global unicast addresses, requiring care if used as a network-layer block. Deployments with independent egress firewall rules blocking outbound connections to RFC1918/loopback ranges or blocking all IPv6 reduce the exploitability of specific transition methods even though the application-layer filter bypass is unconditional.

No CVSS vector was provided by NVD or the vendor for this CVE, so all scoring is independently assessed. The vulnerability represents a meaningful SSRF protection failure for applications that rely solely on NoPrivateNetworkHttpClient as their egress guard - a pattern explicitly encouraged by Symfony documentation for webhook processors, RSS importers, and link preview services. Real-world exploitation is layered: the security boundary violation (the false-negative dispatch decision from IpUtils::isPrivateIp()) occurs unconditionally on all affected versions, but packet delivery to the embedded private IPv4 target further requires the server's IPv6 routing to support the specific transition mechanism used (6to4 tunnel interface, NAT64 upstream gateway, or kernel IPv4-compatible handling). Environments with strict egress firewall rules blocking IPv6 or outbound connections to private ranges are partially protected at the network layer even if the application-layer filter is bypassed. No EPSS score is available; no KEV listing exists; no POC code has been publicly released. Risk is real but bounded: it is highest in cloud-hosted applications without independent network-layer egress controls, particularly those vulnerable to cloud metadata endpoint exposure (169.254.169.254).

An attacker who can submit URLs to a Symfony-powered webhook registration endpoint posts http://[2002:7f00:1::]/ - the 6to4 encoding of 127.0.0.1. IpUtils::isPrivateIp() evaluates this address against the incomplete prefix list, returns false, and NoPrivateNetworkHttpClient dispatches the HTTP GET. If the application server has a 6to4 tunnel interface or an upstream NAT64 gateway, the request reaches the loopback interface, where a locally bound service (such as a database admin console, internal API, or cloud instance metadata endpoint at http://169.254.169.254/ via a second crafted payload) returns its response body to the attacker. No public POC code has been released, but the bypass payloads are fully documented in the official advisory.