CVE-2026-87078: Net::IDN::Punycode versions from 2.302 before 2.590 for Perl leak the output buffer on every rejected label in decode_punycode
Net::IDN::Punycode versions from 2.302 before 2.590 for Perl leak the output buffer on every rejected label in decodepunycode.
The XS backend allocates the scalar it returns before it validates the input, sizing the buffer at twice the input length. The scalar is released only on the success path, so each of the three croaks that reject a label leaves the scalar and its buffer allocated. Nothing bounds the label length in the to-Unicode direction, since the 63-byte DNS limit is checked only when converting to ASCII.
Only the XS backend is affected.
A sender who supplies invalid labels grows the process by twice the label length per rejected call, with no successful call needed.
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 deployments are exposed?
Only deployments using the XS backend are affected. The affected version range is Net::IDN::Punycode 2.302 through versions before 2.590.
What does an attacker need to trigger the memory growth?
An attacker needs to cause decode_punycode to process invalid labels. Each rejected label leaks memory, and no successful decode call is needed for the leak to occur.
Does the DNS 63-byte label limit restrict this attack path?
No. The 63-byte limit is checked only during conversion to ASCII, while the affected path is the to-Unicode direction, where label length is not bounded.
How does repeated exploitation affect a process?
The process grows by twice the supplied label length for every rejected call. Repeated invalid labels can therefore consume increasing process memory.