Description

Net::IDN::UTS46 versions before 2.590 for Perl allow CPU exhaustion via quadratic punycode encoding of an overlong label before the length check in to_ascii. to_ascii punycode encodes each label and only then applies the 63-byte DNS limit. encode_punycode in both backends follows the sample implementation in RFC 3492, whose outer loop runs once per distinct non-ASCII code point and scans the whole input each round, so a label of distinct non-ASCII characters costs the square of its length before the limit rejects it. Every ASCII conversion in the distribution, including domain_to_ascii and email_to_ascii, goes through to_ascii.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-22T08:16:40.863Z",
  "pubdate": "2026-09-22T08:16:40.863Z",
  "executiveSummary": "Net::IDN::UTS46 versions prior to 2.590 are susceptible to a CPU exhaustion vulnerability stemming from inefficient punycode encoding logic.\nThe vulnerability occurs because the library processes input strings through the punycode encoding algorithm before enforcing RFC-mandated length constraints.\nAn attacker can trigger a Denial of Service (DoS) by providing a carefully crafted, overlong domain label containing a sequence of unique non-ASCII characters.\nThis leads to quadratic time complexity during the encoding phase, forcing the system to consume excessive CPU cycles before ultimately rejecting the input due to length constraints.\nThe flaw affects any application utilizing Net::IDN::UTS46, including those performing domain_to_ascii or email_to_ascii transformations.\nExploitation does not require authentication or elevated privileges, as the vulnerability is triggered by parsing user-supplied input strings, making it a critical risk for internet-facing applications that perform DNS normalization.",
  "technicalDetails": "The root cause of this vulnerability lies in the implementation of the `to_ascii` function within the Net::IDN::UTS46 Perl distribution. The library performs punycode encoding on input labels prior to validating them against the 63-byte DNS length limit.\nThe underlying `encode_punycode` routine, implemented in both available backends, adheres to the sample implementation logic defined in RFC 3492. This algorithm is inherently inefficient when handling specific input structures; the outer loop of the encoder executes once for every distinct non-ASCII code point present in the string. Within each iteration of this loop, the encoder performs a complete scan of the entire input string to manage state and maintain the encoding sequence.\nWhen a label is composed of a long string of unique non-ASCII characters, this implementation results in O(n^2) quadratic time complexity. Because the length constraint check is performed only after the full punycode conversion process is complete, an attacker can supply an arbitrarily long, valid-format label that satisfies the library's input expectations but forces the CPU to perform an exponentially increasing number of operations.\nThe attack flow follows a predictable pattern: 1) The attacker provides a malformed domain string to an application utilizing `Net::IDN::UTS46`. 2) The application passes this string to `to_ascii`, `domain_to_ascii`, or `email_to_ascii`. 3) The `to_ascii` function enters the `encode_punycode` backend loop. 4) The quadratic processing logic triggers high CPU utilization, stalling the process or thread. 5) Only after the intensive computation concludes is the string compared against the 63-byte limit, triggering a rejection. By flooding the application with these requests, an attacker can monopolize CPU resources, causing a state of resource exhaustion.\nThis vulnerability is particularly impactful as it is triggered by standard DNS resolution and email processing workflows. It requires no authentication and is remotely exploitable, allowing an unauthenticated attacker to impact service availability by forcing the CPU to expend cycles on computationally expensive, yet ultimately invalid, punycode transformations."
}