CVE-2026-19953: URI versions before 5.36 for Perl encode non-NFC host names to non-standard punycode labels via missing normalization in nameprep
URI versions before 5.36 for Perl encode non-NFC host names to non-standard punycode labels via missing normalization in nameprep
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 5.21-3 - Upgrade
Upgrade
Perl URIto a version that resolves this vulnerability.Fixed in 5.36 - Compensating control
Ensure any security decision that uses the host() from untrusted URIs compares against a normalized (NFC) host form, so the allow/deny/SSRF filter/deduplication/cache key uses the same encoding that clients resolve.
Event History
Frequently Asked Questions
Which uses are exposed to a security impact?
Applications are exposed when they build a URI from untrusted input, read host(), and use that value for a security decision such as an allowlist, denylist, SSRF filter, deduplication check, or cache key. The impact arises because the security check can see a different hostname representation than the client resolves.
What does an attacker need to supply?
An attacker needs to provide a URL containing a hostname label that is not normalized to Unicode NFC. Such a label can produce a non-standard punycode A-label through URI while the client resolves the NFC-normalized form.
How can I determine whether my application is affected?
Check whether it uses Perl URI before 5.36 and passes untrusted URLs through URI parsing before making host-based security decisions. A relevant test case is a host label containing the precomposed Devanagari sequence U+0958 U+093E, which URI can encode as xn--72b5c without normalization while its NFC form encodes as xn--11b2fg.