CVE-2026-87079: Net::IDN::Punycode versions before 2.590 for Perl allow CPU exhaustion via quadratic insertion cost when decoding a long label in decode_punycode
Net::IDN::Punycode versions before 2.590 for Perl allow CPU exhaustion via quadratic insertion cost when decoding a long label in decodepunycode.
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 domaintounicode and uts46tounicode pass an attacker-supplied label of any length to the decoder.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Net-IDN-Encodeto a version that resolves this vulnerability.Fixed in 2.590-TRIAL
Event History
Frequently Asked Questions
Which applications are most exposed to this issue?
Applications that pass attacker-controlled domain names or labels to domain_to_unicode or uts46_to_unicode are exposed, because those paths can supply labels of arbitrary length to the decoder. This can include services that display, normalize, or otherwise convert untrusted internationalized domain names to Unicode.
What does an attacker need to do to trigger the CPU exhaustion?
An attacker needs to provide a sufficiently long label for Punycode decoding. The vulnerable decoding paths have quadratic processing cost as the decoded output grows, allowing a long attacker-supplied label to consume excessive CPU time.
Does the DNS 63-byte label limit prevent exploitation?
No. The 63-byte DNS limit is enforced only when converting to ASCII, while the affected to-Unicode paths pass labels of any length to the decoder.
Are both the XS and pure-Perl backends affected?
Yes. The XS backend repeatedly scans the growing UTF-8 output buffer to locate insertion points, and the pure-Perl backend can similarly perform repeated scans when its input carries the UTF-8 flag.