Skip to main content
← Vulnerabilities

Symfony: NoPrivateNetworkHttpClient Does Not Pin the Checked IP of Cached Hosts, Letting DNS Rebinding Enumerate Internal Ports…

2.3LowCNA
Exploited
No known exploitation
Fix
Fixed in 5.4.56, 6.4.50, 7.4.23, 8.1.11
Who is exposed
Not reported

Do first: Upgrade to a fixed version: 5.4.56, 6.4.50, 7.4.23, 8.1.11.

Published
Last modified
15/100 · provisional
None on Exploit-DB, Metasploit or GitHub
  • Exploitation: none
  • Automatable: no
  • Technical impact: partial

Summary

Symfony's HttpClient component (NoPrivateNetworkHttpClient) fails to pin the checked IP address for cached hosts, so an attacker controlling a host's DNS can use DNS rebinding to get past private-network restrictions and enumerate internal hosts and ports, remotely and with low-privilege login. The attack requires an application that sends several requests to the attacker's host through the same client, such as one fetching multiple user-supplied repository URLs.

Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.

Read the original description

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.

cve.now Index

15Pcve.now Index 15 of 100 · methodology v3 · provisional
  • Exploitation0/40No signal
  • Exposure3/25Reachable over the network · Unknown: No advisory context yet
  • Reach10/20Affects Packagist packages
  • Severity2.3/10CVSS 2.3
  • No patch0/5No signal

What would change the score

  • Would score about 70 if added to CISA KEV
  • Would score about 65 if CISA's SSVC rates exploitation active
  • Would score about 34 if advisories confirm default setups are exposed

What to do

  • Upgrade to a fixed version: 5.4.56, 6.4.50, 7.4.23, 8.1.11.

Timeline

  1. CVE published
  2. First seen by cve.now
  3. CISA SSVC assessment

    Exploitation: none · Automatable: no · Technical impact: partial

  4. Record last updated

Affected versions

  • symfony/http-clientPackagist

    fixed in 5.4.56; From 6.0.0 · fixed in 6.4.50; From 7.0.0 · fixed in 7.4.23; From 8.0.0 · fixed in 8.1.11

Evidence 2

  1. Advisory
  2. Patch

Corrections

None so far.

Something wrong on this page? Report an error. Every fix is listed here.

Questions about CVE-2026-123119

Is CVE-2026-123119 being exploited?

It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data

Which versions are affected by CVE-2026-123119?

symfony/http-client (Packagist): before 5.4.56; from 6.0.0 before 6.4.50; from 7.0.0 before 7.4.23; from 8.0.0 before 8.1.11.Source: cve.now feed data

How do I fix CVE-2026-123119?

Upgrade to a fixed version: 5.4.56, 6.4.50, 7.4.23, 8.1.11.Source: cve.now feed data