CVE-2026-123125: 
PHP vulnerability analysis and mitigation

CVE-2026-123125 is an SSRF filter bypass vulnerability in the Symfony Validator component's IpValidator, where incomplete classification of internal IP addresses allows certain non-public addresses to pass as public in filtered validation modes. It affects symfony/symfony and symfony/validator 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. The vulnerability was published on November 5, 2026, and was reported by researcher zx (Jace) and assigned by Checkmarx. It carries a CVSS v3.1 base score of 6.5 (Medium) and a CVSS v4.0 base score of 6.3 (Medium) (GitHub Advisory, Feedly).

The root cause is classified as CWE-184 (Incomplete List of Disallowed Inputs) and CWE-918 (Server-Side Request Forgery). IpValidator relies exclusively on PHP's FILTER_FLAG_NO_PRIV_RANGE and FILTER_FLAG_NO_RES_RANGE flags to classify IP addresses, but these flags do not cover several non-public ranges: shared address space (100.64.0.0/10, RFC 6598), documentation TEST-NET ranges (192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24), benchmarking ranges (198.18.0.0/15), and the entire IPv6 special-purpose family including 6to4 (2002::/16), Teredo (2001::/32), NAT64, and IPv4-mapped/IPv4-compatible addresses (e.g., ::ffff:127.0.0.1). Additionally, classification is spelling-dependent for IPv6 — ::7f00:1 and ::127.0.0.1 represent the same 128 bits but may be treated differently depending on PHP version. This only affects applications using the filtered modes (NO_PRIV, NO_RES, ONLY_PUBLIC); the default V4 mode performs no range filtering and is unaffected (GitHub Advisory, Patch Commit).

Applications that use the Symfony Ip constraint with filtered modes (ALL_ONLY_PUBLIC, ALL_NO_PRIV, etc.) as a security guard before making server-side HTTP requests to user-supplied addresses are exposed to SSRF. An attacker can supply an IPv4-mapped address such as ::ffff:10.0.0.1 or a 6to4 address like 2002:7f00:1:: that passes validation but resolves to an internal host, potentially allowing access to internal services, metadata endpoints (e.g., cloud IMDS), or other resources not intended to be reachable from the public internet. The confidentiality and integrity of subsequent (downstream) systems are at low risk, while availability is not directly impacted (GitHub Advisory, Feedly).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported as of the disclosure date. The NVD SSVC assessment indicates exploitation is currently "none" and the EPSS score is 0.0, suggesting low near-term exploitation probability. The vulnerability is automatable (no user interaction required) and requires no authentication, but exploitation depends on the target application specifically using Symfony's Ip constraint in a filtered mode as an SSRF mitigation. The CVE is not listed in the CISA Known Exploited Vulnerabilities catalog (Feedly, GitHub Advisory).

1. Identify target application: Find a Symfony-based application that accepts a user-supplied IP address or URL and uses the Ip constraint with a filtered mode (ALL_ONLY_PUBLIC, ALL_NO_PRIV, V4_ONLY_PUBLIC, etc.) before making a server-side HTTP request.
2. Craft a bypass payload: Construct an IP address that represents an internal host but is not blocked by PHP's FILTER_FLAG_NO_PRIV_RANGE/FILTER_FLAG_NO_RES_RANGE flags. Examples include:
   • ::ffff:127.0.0.1 (IPv4-mapped loopback, bypasses ALL_NO_PRIV on PHP < 8.3)
   • ::ffff:10.0.0.1 (IPv4-mapped private address)
   • 2002:7f00:1:: (6to4 encoding of 127.0.0.1)
   • 100.64.0.1 (shared address space, bypasses all filtered modes)
3. Submit the payload: Send the crafted address to the application's input field or API endpoint that performs IP validation.
4. Trigger server-side request: The application validates the address (which passes), then makes an HTTP request to the supplied address, reaching the internal host.
5. Exfiltrate data: Retrieve the response from the internal service (e.g., cloud metadata at 169.254.169.254, internal APIs, or admin interfaces) via the application's response or an out-of-band channel (GitHub Advisory).

• Network: Outbound HTTP requests from the application server to internal IP ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, 100.64.0.0/10, 169.254.0.0/16) or to IPv6 addresses in the 2002::/16 or ::ffff:0:0/96 ranges; unexpected requests to cloud metadata endpoints (e.g., 169.254.169.254).
• Logs: Application access logs showing user-supplied IP values containing IPv6 notation with embedded IPv4 addresses (e.g., ::ffff:, 2002:, ::7f) in input fields or API parameters; HTTP responses containing internal service data.
• Application Behavior: Symfony validator accepting addresses like ::ffff:10.0.0.1, 2002:7f00:1::, or 100.64.x.x without raising a validation violation in filtered modes.

Upgrade symfony/symfony or symfony/validator to one of the patched versions: 5.4.56, 6.4.50, 7.4.23, or 8.1.11. The fix adds explicit subnet-based rejection of all non-public IPv4 and IPv6 ranges (mirroring IpUtils::PRIVATE_SUBNETS) on top of the existing filter_var() call, applied only to the filtered modes. As a workaround for applications that cannot immediately upgrade, implement an independent IP allowlist/denylist check using Symfony\Component\HttpFoundation\IpUtils::isPrivateIp() before making any server-side request to a user-supplied address. Note that after patching, some previously accepted addresses (e.g., 100.64.0.1, ::ffff:8.8.8.8) will now be rejected in filtered modes, which may require application-level adjustments (GitHub Advisory, Patch Commit).

The advisory was published by Symfony maintainer fabpot on GitHub and credits researcher zx (Jace) for the discovery and nicolas-grekas for the remediation. The fix was assessed as a "Moderate" severity issue by the Symfony security team. No significant broader media coverage or notable social media discussion has been identified beyond the standard vulnerability tracking aggregators (GitHub Advisory).