GIVE YOUR AGENT THE EVIDENCE

Set up in your agent.

One prompt to get started. Paste it into your coding agent to connect cve.new through MCP and bring vulnerability context into your workflow.

Your agent needs remote MCP support and access to https://cve.new/mcp.

Read the setup guide

GIVE YOUR AGENT THE EVIDENCE

Investigate in your agent.

Turn this advisory into a focused investigation. Ask your agent to check your project’s versions, explain the evidence, and suggest a compatible fix.

Your agent needs remote MCP support and access to https://cve.new/mcp.

Read the setup guide

cve.new
Check your stack
GHSA-38cx-cq6f-5755medium6.3

Symfony: IpUtils::PRIVATE_SUBNETS Omits IPv6 Transition Forms (6to4, NAT64, Teredo, IPv4-compatible): SSRF Bypass in NoPrivateNetworkHttpClient

Impact

Symfony\Component\HttpClient\NoPrivateNetworkHttpClient is documented as a decorator that blocks requests to private networks by default. The list of blocked subnets (Symfony\Component\HttpFoundation\IpUtils::PRIVATE_SUBNETS on 6.4+, a private constant in NoPrivateNetworkHttpClient on 5.4) enumerates RFC1918, loopback, link-local and IPv4-mapped IPv6 (::ffff:0:0/96) prefixes, but omits the remaining IPv6 transition forms that can embed a private IPv4 destination: 6to4 (2002::/16, RFC 3056), Teredo (2001::/32, RFC 4380), NAT64 (64:ff9b::/96, RFC 6052 and 64:ff9b:1::/48, RFC 8215) and…

Source excerpt · OSV

Affected packages

Start with the recorded fix for your release branch. Check your installed version and test compatibility before upgrading. Fixing this advisory does not rule out other vulnerabilities in the release.

symfony/http-client Packagist
Affected rangeRecorded fix
From 5.4.0 before 5.4.53Ecosystem versions5.4.53

Version evidence: OSV · GHSA-38cx-cq6f-5755

View original version evidence (41 explicit versions)
symfony/http-foundation Packagist
Affected rangeRecorded fix
From 6.4.0 before 6.4.41Ecosystem versions6.4.41
From 7.0.0 before 7.4.13Ecosystem versions7.4.13
From 8.0.0 before 8.0.13Ecosystem versions8.0.13

Version evidence: OSV · GHSA-38cx-cq6f-5755

View original version evidence (91 explicit versions)
symfony/symfony Packagist
Affected rangeRecorded fix
From 5.4.0 before 5.4.53Ecosystem versions5.4.53
From 6.4.0 before 6.4.41Ecosystem versions6.4.41
From 7.0.0 before 7.4.13Ecosystem versions7.4.13
From 8.0.0 before 8.0.13Ecosystem versions8.0.13

Version evidence: OSV · GHSA-38cx-cq6f-5755

View original version evidence (178 explicit versions)

Original source description

Description

Symfony\Component\HttpClient\NoPrivateNetworkHttpClient is documented as a decorator that blocks requests to private networks by default. The list of blocked subnets (Symfony\Component\HttpFoundation\IpUtils::PRIVATE_SUBNETS on 6.4+, a private constant in NoPrivateNetworkHttpClient on 5.4) enumerates RFC1918, loopback, link-local and IPv4-mapped IPv6 (::ffff:0:0/96) prefixes, but omits the remaining IPv6 transition forms that can embed a private IPv4 destination: 6to4 (2002::/16, RFC 3056), Teredo (2001::/32, RFC 4380), NAT64 (64:ff9b::/96, RFC 6052 and 64:ff9b:1::/48, RFC 8215) and IPv4-compatible IPv6 (::/96, RFC 4291 §2.5.5.1).

IpUtils::checkIp6() is a pure bitwise CIDR comparison against the constants list and never extracts the embedded IPv4, so an attacker who can supply a URL writes the loopback / RFC1918 IPv4 target as e.g. http://[2002:7f00:1::]/ (6to4 → 127.0.0.1), http://[64:ff9b::7f00:1]/ (NAT64 → 127.0.0.1), http://[::7f00:1]/ (IPv4-compatible → 127.0.0.1) or http://[2001::1]/ (Teredo). IpUtils::isPrivateIp() returns false and NoPrivateNetworkHttpClient dispatches the request.

Real-world reachability of the embedded IPv4 depends on the deploy's IPv6 routing (6to4 tunnel interface, upstream NAT64 gateway, kernel handling of IPv4-compatible addresses), but the security boundary the decorator promises — the dispatch decision — is crossed regardless of whether the packet ultimately lands on the embedded IPv4.

Resolution

The private-subnet list now includes ::/96, 2002::/16, 2001::/32, 64:ff9b::/96 and 64:ff9b:1::/48. Blanket blocking of these prefixes matches the policy applied by Chromium and Mozilla's Private Network Access; server-side HTTPS APIs are not legitimately published on these prefixes.

The patches for this issue are available here for branch 5.4 and here for branch 6.4 (and forward-ported to 7.4, 8.0 and 8.1).

Credits

Symfony would like to thank tonghuaroot for reporting the issue and Nicolas Grekas for providing the fix.

References