CVE-2026-46644: Symfony Polyfill SSRF Vulnerability

CVE-2026-46644 Overview

CVE-2026-46644 affects Symfony Polyfill's symfony/polyfill-intl-idn component in versions 1.17.1 through 1.38.0. The Idn::process() function accepts xn-- labels whose Punycode payload is empty or decodes to ASCII-only code points. This violates the UTS #46 revision 33 requirement that decoded ACE labels contain at least one non-ASCII code point. Applications using the polyfill to canonicalize or compare hostnames may treat distinct domain names as equivalent. The flaw is categorized under [CWE-1289] Improper Validation of Unsafe Equivalence in Input.

Critical Impact
Attackers can bypass hostname allowlists and blocklists, trigger inconsistent URL parsing across components, and induce server-side request forgery (SSRF) in downstream applications.

Affected Products

Symfony Polyfill symfony/polyfill-intl-idn versions 1.17.1 through 1.38.0
PHP applications relying on the polyfill for IDN normalization
Downstream frameworks and libraries that consume the polyfill for URL canonicalization

Discovery Timeline

2026-07-14 - CVE-2026-46644 published to NVD
2026-07-15 - Last updated in NVD database

Technical Details for CVE-2026-46644

Vulnerability Analysis

The Internationalized Domain Names in Applications (IDNA) standard permits hostnames to include non-ASCII characters through ASCII-Compatible Encoding (ACE) labels prefixed with xn--. UTS #46 revision 33 mandates that a decoded ACE label must contain at least one non-ASCII code point. Otherwise, the label is invalid and must be rejected. The Symfony Polyfill IDN implementation omitted this validation step.

An attacker can craft a hostname such as xn--example.com where the Punycode payload after xn-- decodes to empty output or to a string composed entirely of ASCII characters. The polyfill silently accepts the label and yields a normalized hostname that differs from what strict IDN implementations produce. Downstream logic that compares hostnames, applies allow/deny lists, or resolves origins can be tricked into treating two syntactically distinct hostnames as equivalent.

Root Cause

The root cause is a missing post-decode validation branch inside Idn::process() in src/Intl/Idn/Idn.php. After Punycode decoding via self::punycodeDecode(), the code did not verify that the resulting label contained at least one non-ASCII code point. The fix adds this check per UTS #46 revision 33.

Attack Vector

Exploitation is network-based, requires no authentication, and no user interaction. An attacker supplies a malformed IDN hostname to any application entry point that ultimately invokes the polyfill for normalization or comparison. Typical attack chains involve URL validators, HTTP client libraries, and SSRF filters that rely on canonicalized hostnames to enforce security decisions.

php

                // Step 4.2. Attempt to convert the rest of the label to Unicode according to Punycode [RFC3492]. If
                // that conversion fails, record that there was an error, and continue
                // with the next label. Otherwise replace the original label in the string by the results of the
                // conversion. Per UTS #46 revision 33, if the conversion succeeds but the result is empty or
                // contains only ASCII code points, record that there was an error and continue with the next label.
                try {
                    $label = self::punycodeDecode(substr($label, 4));
                } catch (\Exception $e) {

Source: GitHub commit 1be936e — patch adds the UTS #46 revision 33 validation that rejects xn-- labels decoding to empty or ASCII-only output.

Detection Methods for CVE-2026-46644

Indicators of Compromise

HTTP request logs containing hostnames with xn-- prefixes whose Punycode payload decodes to ASCII-only characters or empty strings
Repeated requests targeting URL validators, webhook endpoints, or SSRF-sensitive parsers with mismatched Host headers and URL authorities
Outbound connections from application servers to internal or metadata addresses following user-supplied URLs

Detection Strategies

Perform software composition analysis to identify symfony/polyfill-intl-idn versions between 1.17.1 and 1.38.0 in application dependencies and lockfiles
Instrument application middleware to log the pre- and post-normalization form of hostnames processed by Idn::process() and alert on divergence
Compare polyfill output against native intl extension output where available to detect canonicalization mismatches

Monitoring Recommendations

Monitor egress traffic from web applications for connections to RFC 1918, link-local, and cloud metadata endpoints originating from URL-fetching features
Track WAF and application logs for xn-- labels in Host headers, URL paths, and JSON payloads
Audit dependency update pipelines to confirm remediated versions are deployed across all environments

How to Mitigate CVE-2026-46644

Immediate Actions Required

Upgrade symfony/polyfill-intl-idn to version 1.38.1 or later across all Composer-managed projects
Inventory all applications and container images embedding the vulnerable polyfill and prioritize remediation of internet-facing services
Review SSRF defenses and hostname allowlist logic to confirm they do not rely solely on the polyfill for normalization

Patch Information

The fix is available in Symfony Polyfill version 1.38.1. See the GitHub Release v1.38.1 and the GitHub Security Advisory GHSA-2xf4-cg6j-vhgq for full details. The patch adds validation in src/Intl/Idn/Idn.php to reject decoded ACE labels that are empty or ASCII-only.

Workarounds

Install and enable the native PHP intl extension so the polyfill code paths are bypassed at runtime
Add input-layer validation that rejects any hostname label starting with xn-- whose decoded form does not contain a non-ASCII code point
Deny user-supplied URLs pointing to internal IP ranges and cloud metadata services at the network egress layer

bash

# Update the polyfill to the fixed release using Composer
composer require symfony/polyfill-intl-idn:^1.38.1
composer update symfony/polyfill-intl-idn --with-dependencies

# Verify the installed version
composer show symfony/polyfill-intl-idn | grep versions