CVE-2026-46644
MEDIUM
GHSA-2xf4-cg6j-vhgq
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Hardware access control
|
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – May 28, 2026
Symfony's polyfill-intl-idn library (versions 1.17.1–1.38.0) silently accepts malformed Punycode ACE labels — specifically xn-- prefixed labels whose decoded payload is empty or contains only ASCII characters — which native PHP ext-intl correctly rejects. This divergence allows attackers to craft domain names such as poc.xn--kc1zs4-.com that the polyfill normalizes to poc.kc1zs4.com, causing hostname blacklist bypasses and inconsistent URL parsing in applications that rely on the polyfill for canonicalization or security-sensitive hostname comparisons. The flaw directly enables server-side request forgery (SSRF) in affected deployments, mirrors the pattern established by CVE-2024-12224, and no public exploit has been identified at time of analysis beyond the proof-of-concept inputs included in the vendor advisory.
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 2 packages in composer
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:L/SI:L/SA:N
Primary rating from Vendor (https://github.com/symfony/polyfill) · only source for this CVE.
CVSS VectorVendor: https://github.com/symfony/polyfill
Lifecycle Timeline
1DescriptionCVE.org
Description
symfony/polyfill-intl-idn provides a userland implementation of idn_to_utf8() and idn_to_ascii() for runtimes that lack the intl extension. Its Idn::process() method decodes labels prefixed with xn-- using Punycode but never enforces the validity criterion added in UTS #46 revision 33 Section 4 step 4.1.2: after a successful Punycode decode, the result must contain at least one non-ASCII code point.
As a consequence, xn-- labels whose Punycode payload is empty (xn--) or decodes to a string made of only ASCII code points (e.g. xn--kc1zs4-) are accepted by the polyfill while PHP's native ext-intl rejects them with IDNA_ERROR_INVALID_ACE_LABEL. Originally unequal domain names are therefore regarded as equal, which can lead to blacklist bypassing, inconsistent URL parsing and server-side request forgery (similar to CVE-2024-12224).
Example with IDNA_USE_STD3_RULES | IDNA_CHECK_BIDI | IDNA_CHECK_CONTEXTJ | IDNA_NONTRANSITIONAL_TO_ASCII:
| Input | Polyfill output | Native ext-intl output |
|---|---|---|
poc.xn--kc1zs4-.com | poc.kc1zs4.com | false (errors=1024) |
poc.kc1zs4.xn-- | poc.kc1zs4. | false (errors=1024) |
Applications using the polyfill to canonicalise or compare hostnames inherit the inconsistency.
Resolution
Idn::process() now records IDNA_ERROR_INVALID_ACE_LABEL when a Punycode payload decodes to an empty string or to a string containing only ASCII code points, matching the native ext-intl behaviour and UTS #46 revision 33.
The patch for this issue is available here for branch 1.x.
Credits
Symfony would like to thank Nazy Mad for reporting the issue and Nicolas Grekas for providing the fix.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Server-Side Request Forgery exploits applications that fetch remote resources based on user-supplied URLs.
Exploit-DB