Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-08-31T18:17:14.320Z",
  "pubdate": "2026-08-31T18:17:14.320Z",
  "executiveSummary": "The URI module for Perl, in versions prior to 5.36, exhibits a vulnerability involving improper IDNA (Internationalized Domain Name in Applications) normalization during host name processing. The vulnerability stems from the failure to perform Unicode Normalization Form C (NFC) on host labels prior to punycode encoding, as mandated by RFC 5891. This deviation results in the generation of non-standard A-labels for non-NFC input strings.\nThe primary risk lies in security logic bypass. Because the URI module produces a non-standard punycode representation, a discrepancy is created between the host identifier perceived by internal security mechanisms—such as SSRF filters, allow/deny lists, and cache keys—and the identifier resolved by standard network clients that correctly implement NFC normalization. An attacker can exploit this inconsistency to circumvent security controls. By providing a crafted Unicode host string, the attacker ensures that the security filter validates one representation while the underlying HTTP client resolves an entirely different, normalized host, potentially leading to unauthorized network access, cache poisoning, or filter evasion. This vulnerability requires no specific authentication and can be triggered via untrusted user input provided to the host() function.",
  "technicalDetails": "The root cause of this vulnerability is a non-compliant implementation of nameprep within the URI Perl module. According to RFC 5891, IDNA specifications require that all domain name labels undergo Unicode Normalization Form C (NFC) before the application of punycode encoding. The URI module correctly performs label lowercasing; however, it fails to execute the required NFC normalization step.\nThis omission creates a transformation ambiguity. When a label containing non-NFC Unicode sequences is processed, the lack of normalization causes the punycode encoding algorithm to map the input to an incorrect A-label. For example, a Devanagari sequence represented by U+0958 U+093E, if processed without NFC normalization, results in the A-label 'xn--72b5c'. Conversely, if normalized to NFC first, the same sequence generates 'xn--11b2fg'. The original label cannot be recovered from the non-standard 'xn--72b5c' via standard round-trip procedures, demonstrating a fundamental break in IDNA compliance.\nThe attack flow proceeds as follows: 1) An attacker identifies a system utilizing the URI module to parse user-supplied URLs for security-sensitive operations (e.g., SSRF protection or domain allow-listing). 2) The attacker crafts a URI containing a specifically chosen Unicode hostname that resolves differently depending on whether NFC normalization is applied. 3) The attacker submits this URI to the target application. 4) The application invokes the vulnerable host() function to extract the hostname. 5) The security logic (e.g., a regex filter or database lookup) validates the non-standard A-label generated by the vulnerable module. 6) Because the security check operates on the incorrect, non-normalized label, it fails to detect a blacklisted or unauthorized domain. 7) The application then passes the URI to an underlying network client or resolver that adheres to RFC 5891 and performs the correct NFC normalization, causing the system to connect to the target host intended by the attacker.\nThis behavior facilitates successful bypass of SSRF filters, as the security middleware sees a 'safe' non-standard domain while the outbound request reaches the 'forbidden' normalized domain. Furthermore, this discrepancy can lead to cache pollution or deduplication errors, as the application treats the non-normalized and normalized labels as distinct entities despite them resolving to the same resource in a standard IDNA-compliant environment."
}