Cloudanix VulnDB

CVE-2026-46644

Medium · 5.8

symfony/polyfill-intl-idn: xn-- labels with ASCII-only Punycode payloads are treated as equivalent to their decoded form

CVSS

5.8

EPSS

0.5%

Published

May 28, 2026

CISA due date

—

The record

`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.

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities