CVE-2026-123119 · Package
NO FIX YET · SEE WHAT TO DO
Symfony's NoPrivateNetworkHttpClient caches the checked IP per host but only pins it on the first request, so later requests resolve DNS again. An attacker who controls a DNS record can switch it to a private IP and use the application to enumerate internal hosts and open ports.
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 that use Symfony's NoPrivateNetworkHttpClient to fetch user-supplied URLs and send several requests to the same host through one client instance. Applications that do not use this decorator, or that only fetch fixed trusted URLs, are not meaningfully exposed.
Not affected if does-not-use-no-private-network-client, fixed-urls-only
Who cares http-client, php, symfony
symfony/http-client version with composer show symfony/http-clientNoPrivateNetworkHttpClient in the codebase, especially where user-supplied URLs are fetched repeatedly through the same client5.4.56, 6.4.50, 7.4.23, and 8.1.11 or later (fixed versions prior to which the component is affected)The Symfony HttpClient component NoPrivateNetworkHttpClient does not pin the checked IP address of cached hosts, allowing for DNS rebinding to bypass private network restrictions, resulting in enumeration of internal hosts and ports in Symfony 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.
NoPrivateNetworkHttpClient resolves the host of each request and checks the IP before connecting. It caches the result per host, and passes the IP to the decorated client through the resolve option so that the client connects to the exact IP that was checked. The issue is that resolve was only passed on the first lookup of a host: on subsequent requests, the decorated client resolved the host again on its own.
An attacker who controls a host's DNS can exploit this with DNS rebinding by answering the first lookup with a public IP, and subsequent lookups with a private IP, so when an application sends several requests to that host through the same client, the later requests connect to the private IP. This happens, for example, when an application fetches several URLs of a repository provided by a user. The check of the primary_ip in the on_progress callback still aborts the request before anything is sent, but the connection is made, and the error differs depending on whether the port is open or closed. This allows enumerating internal hosts and ports, as in CVE-2024-50342.
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.
This page as .md · .json · CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/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.