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.
nameprep lowercases each host label but performs no Unicode normalization. IDNA requires a label to be normalized to Form C before it is encoded (RFC 5891), so a label that is not already in NFC is encoded to a different A-label than its normalized form. A label built from the precomposed Devanagari sequence U+0958 U+093E encodes to xn--72b5c without normalization but to xn--11b2fg after NFC normalization, and xn--72b5c does not round-trip back to the original label.
Any caller that reads host() from a URI built from untrusted input and uses it for a security decision (an allow or deny list, an SSRF filter, deduplication, a cache key) sees the non-standard label, while a client that fetches the same URL resolves the NFC form, so the check and the fetch can disagree about the host.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Perl URIto a version that resolves this vulnerability.Fixed in 5.36 - Configuration
Ensure nameprep performs Unicode normalization to Form C (NFC) before encoding non-NFC host labels into punycode, since nameprep lowercases each host label but performs no Unicode normalization.
Perl nameprep Unicode normalization = NFC - Compensating control
Avoid using non-normalized, untrusted URI host() values for security decisions (allow/deny lists, SSRF filtering, deduplication, or cache keys); normalize/validate the host consistently before comparing and before performing any network fetch.
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.