Listen to this Post
The vulnerability arises from a missing UTS 46 revision 33 validity check in the Punycode decoding routine of the `symfony/polyfill-intl-idn` component. The component provides drop‑in replacements for the PHP functions `idn_to_ascii()` and `idn_to_utf8()` on systems without the `ext‑intl` extension. Internally, its `Idn::process()` method decodes domain labels that start with the `xn--` prefix using Punycode. However, prior to the fix, it did not enforce the rule that a successfully decoded Punycode label must contain at least one non‑ASCII code point.
Consequently, the polyfill accepted two classes of invalid Punycode labels:
Empty payloads (e.g. the `xn--` label all by itself)
Payloads that decode to a string that is still entirely ASCII (e.g. xn--kc1zs4-)
PHP’s native `ext-intl` correctly rejects both cases and returns an `IDNA_ERROR_INVALID_ACE_LABEL` error (error code 1024). By accepting these labels, the polyfill treated originally distinct domain names as equivalent. This leads to several security consequences:
Blacklist bypass – an application that blocks “poc.kc1zs4.com” could be evaded by using poc.xn--kc1zs4-.com, because the polyfill would canonicalise the latter to the former.
Inconsistent URL parsing – different parts of an application may normalise the same input differently, leading to logic bugs.
Server‑side request forgery (SSRF) – if a URL blacklist is enforced through the polyfill, an attacker can feed a malicious hostname that bypasses the filter, potentially allowing requests to internal services.
The polyfill now records `IDNA_ERROR_INVALID_ACE_LABEL` when the Punycode payload is empty or decodes to an ASCII‑only string, bringing its behaviour in line with both `ext-intl` and the IDNA specification.
DailyCVE Form:
Platform: PHP package symfony/polyfill-intl-idn
Version: 1.17.1 – 1.38.0
Vulnerability: IDN Punycode validation bypass
Severity: Medium
date: 2026-05-26
Prediction: patch available since 2026-05-26
Analytics (What Undercode Say)
Detect vulnerable version
composer show symfony/polyfill-intl-idn | grep versions
Test with a known invalid Punycode label (before patching)
php -r "
\$options = IDNA_USE_STD3_RULES | IDNA_CHECK_BIDI | IDNA_CHECK_CONTEXTJ | IDNA_NONTRANSITIONAL_TO_ASCII;
if (function_exists('idn_to_ascii')) {
var_dump(idn_to_ascii('poc.xn--kc1zs4-.com', \$options, INTL_IDNA_VARIANT_UTS46, \$info));
var_dump(\$info['errors']);
}
"
After patching, the same command should return false (error) and errors=1024 (IDNA_ERROR_INVALID_ACE_LABEL)
// Exploit snippet: bypass blacklist for "poc.kc1zs4.com"
$malicious = "poc.xn--kc1zs4-.com";
$normalized = idn_to_ascii($malicious, IDNA_NONTRANSITIONAL_TO_ASCII, INTL_IDNA_VARIANT_UTS46);
// On vulnerable version: 'poc.kc1zs4.com' (bypass!)
// On patched version: false (rejected)
if ($normalized === false) {
echo "Blocked: invalid Punycode label\n";
} else {
// This should not be reached after the patch
echo "Canonicalized to: $normalized\n";
}
How Exploit
An attacker crafts a domain name with an ASCII‑only or empty Punycode label, for example:
– `xn--kc1zs4-` (decodes to kc1zs4, all ASCII)
– `xn--` (empty payload)
When an application that uses the vulnerable polyfill normalises a URL or compares hostnames, the malicious input is treated as equivalent to its decoded ASCII form. This can be used to:
1. Bypass hostname blacklists – a blacklist entry for `poc.kc1zs4.com` is circumvented by poc.xn--kc1zs4-.com.
2. Manipulate URL parsing – different components (e.g. a WAF and a backend server) may canonicalise hostnames inconsistently, leading to request smuggling or SSRF.
3. Evade IDN‑based protections – content security policies that block certain IDNs may be fooled.
The vulnerability is triggered automatically whenever the polyfill is called with `IDNA_NONTRANSITIONAL_TO_ASCII` or similar flags. No special environment or user interaction is required beyond being able to supply a domain name to an affected function.
Protection
Upgrade the package to version 1.38.1 or later.
composer require symfony/polyfill-intl-idn:^1.38.1
If you cannot upgrade immediately, replace the vulnerable polyfill with the native `ext-intl` extension. Ensure the extension is enabled and that your application does not fall back to the polyfill.
sudo apt-get install php-intl phpenmod intl
Validate all hostnames manually before passing them to any IDN function. Reject any label that starts with `xn--` but decodes to an all‑ASCII string or an empty string.
Monitor application logs for error code 1024 (IDNA_ERROR_INVALID_ACE_LABEL) – after the patch, this error will be raised for malicious labels.
Run a Composer audit to confirm that no other dependencies pull in a vulnerable version.
composer audit
Impact
Blacklist bypass – an attacker can evade domain‑based blocklists by encoding the target domain in a way that the polyfill accepts but `ext-intl` would reject.
Inconsistent URL processing – different parts of an application (or different applications in a pipeline) may canonicalise the same input differently, leading to request smuggling, open redirects, or SSRF.
SSRF – if internal service access is restricted via a hostname whitelist that relies on the vulnerable polyfill, an attacker could feed a malicious hostname that passes the check but resolves to an internal IP.
Broken IDN security policies – applications that rely on the polyfill to enforce content security policies based on IDNs (e.g. `script-src` with IDNs) may be bypassed.
Wide exposure – the polyfill is a dependency of many popular PHP packages (Guzzle, Symfony, Drupal, etc.). Any application that uses it on a system without `ext-intl` is vulnerable.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
