Description

Net::IDN::Punycode versions before 2.590 for Perl allow CPU exhaustion via quadratic insertion cost when decoding a long label in decode_punycode. The XS backend inserts each decoded code point into a UTF-8 buffer and finds the insertion point by scanning that buffer from the start, one character at a time. The scan runs once per code point over the output built so far, so the cost is quadratic in the label length. The pure-Perl backend downgrades its input to bytes so that substr can index it directly, but takes its working copy before the downgrade, so when the input carries the UTF-8 flag every substr on the copy scans from the start, with the same quadratic cost. Nothing bounds the label length in the to-Unicode direction. The 63-byte DNS limit is checked only when converting to ASCII, so domain_to_unicode and uts46_to_unicode pass an attacker-supplied label of any length to the decoder.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-22T08:16:40.637Z",
  "pubdate": "2026-09-22T08:16:40.637Z",
  "executiveSummary": "Net::IDN::Punycode versions prior to 2.590 are susceptible to a CPU exhaustion vulnerability stemming from an inefficient decoding algorithm in the decode_punycode function.\nThe vulnerability allows an attacker to trigger quadratic time complexity during the conversion of Punycode labels to Unicode, potentially leading to a Denial of Service (DoS) state.\nThis issue affects the XS backend and the pure-Perl backend, both of which lack sufficient length validation for input labels before processing.\nBecause the DNS 63-byte length constraint is enforced only during the conversion to ASCII, functions such as domain_to_unicode and uts46_to_unicode accept arbitrarily long labels, enabling remote attackers to consume excessive CPU cycles by submitting malicious Punycode strings.\nThe risk is elevated as no authentication is required to exploit this flaw, provided an attacker can supply input to the affected decoding functions.\nSystems processing user-supplied domain names or Internationalized Domain Names (IDN) are at significant risk of service degradation.",
  "technicalDetails": "The vulnerability originates in the decode_punycode function, where the logic implemented for managing the output buffer exhibits O(n^2) complexity relative to the label length. In the XS backend, the implementation inserts decoded code points into a UTF-8 buffer by scanning the entire existing output buffer from the start for every individual code point. As the output buffer grows, the number of operations increases quadratically, forcing the CPU to perform redundant scans for each character insertion.\nIn the pure-Perl backend, the vulnerability manifests due to inconsistent input handling. While the backend attempts to downgrade input to bytes to facilitate indexing, it captures a working copy of the input prior to this downgrade. If the input carries the UTF-8 flag, subsequent substr operations on the internal copy force the interpreter to scan from the start of the string, mirroring the quadratic cost observed in the XS implementation.\nThe exploitation flow begins when an attacker provides a maliciously crafted, excessively long Punycode string to domain_to_unicode or uts46_to_unicode. Since these higher-level functions do not enforce the standard 63-byte DNS label length limitation until the 'to-ASCII' conversion phase, the oversized input passes directly into the vulnerable decode_punycode decoder. There are no secondary bounds checks on the label length in the 'to-Unicode' direction, allowing for unbounded processing time.\nAn attacker can force the application to expend maximum computational resources by submitting an extremely long Punycode label. The resulting processing load can spike CPU usage to 100% per thread for a significant duration, effectively stalling the application or exhausting its thread pool. This impacts any network-facing service that parses or validates IDNs, making it a viable vector for a DoS attack. No authentication or elevated privileges are required to initiate this attack, as the decoder is reachable via standard public-facing interfaces that accept domain input."
}