CVE-2026-87078 in Punycode
Summary
by MITRE • 09/22/2026
Net::IDN::Punycode versions from 2.302 before 2.590 for Perl leak the output buffer on every rejected label in decode_punycode.
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/22/2026
The vulnerability identified in Net::IDN::Punycode versions ranging from 2.302 to just before 2.590 for Perl represents a significant resource management flaw within the XS backend implementation of the library. This issue specifically manifests as an output buffer leak during the decoding process, where memory is allocated but never freed under specific error conditions. The core technical defect lies in the sequence of operations performed by the decode_punycode function. When processing input to convert Punycode labels into Unicode strings, the XS backend pre-allocates a scalar variable intended to hold the result. This allocation sizes the buffer at twice the length of the provided input string, anticipating potential expansion during decoding. However, this memory reservation occurs before any validation of the input data takes place. Consequently, if the input contains invalid characters or structural errors that cause the function to reject the label and trigger a croak exception, the allocated scalar is not properly released. The code path for successful conversion includes logic to free the buffer, but the error handling paths associated with rejecting malformed labels fail to perform this cleanup operation.
This architectural oversight results in a direct memory leak every time an invalid Punycode label is submitted for decoding. Since there are three distinct points within the validation logic where a croak can be triggered upon detecting errors such as illegal character sequences or out-of-bounds values, each of these rejection events leaves behind an allocated scalar and its associated buffer in memory. The vulnerability is particularly insidious because it does not require a successful conversion to exploit; merely submitting invalid data triggers the leak. Furthermore, there is no bounding mechanism on the label length during the Unicode-to-ASCII direction that would mitigate this specific issue, although the 63-byte DNS limit check exists for ASCII conversions, it does not apply here since the flaw occurs in the decoding path where input validation happens post-allocation. Only the XS backend implementation of Net::IDN::Punycode is affected by this defect, meaning pure Perl implementations or other language bindings are not susceptible to this specific memory leak pattern.
The operational impact of this vulnerability centers on resource exhaustion and potential denial of service against applications that rely heavily on IDNA processing with untrusted input. An attacker who supplies a stream of invalid labels can systematically grow the process memory footprint by twice the length of each rejected label per call. Because there is no successful call required to trigger the leak, an adversary does not need to bypass any authentication or success criteria; they simply need to send malformed data repeatedly. Over time, this unbounded allocation will consume available system RAM, potentially leading to application crashes, swapping activity that degrades performance for other processes, or a complete denial of service if the operating system kills the process due to excessive memory usage. This is particularly dangerous in high-throughput environments such as web servers processing domain name lookups or email systems validating sender domains, where rapid submission of malformed data can accelerate resource depletion.
From a classification perspective, this vulnerability aligns with CWE-401, which describes missing release of memory after effective usage, and more specifically reflects the consequences outlined in CWE-772 regarding Missing Release of Resource after Effective Lifetime. In terms of attack patterns, it facilitates Denial of Service (DoS) attacks as described in MITRE ATT&CK technique T1499, where an attacker degrades or disrupts the availability of a target resource by exhausting system resources such as memory. To mitigate this risk, organizations using Net::IDN::Punycode must upgrade to version 2.590 or later, where the XS backend has been patched to ensure that allocated buffers are correctly released even when input validation fails and exceptions are raised. Until an update can be applied, defensive programming practices should be employed by validating Punycode strings against known good patterns before passing them to the decode function, thereby reducing the likelihood of triggering the error paths that lead to memory leaks. Additionally, monitoring process memory usage for applications utilizing this library can help detect anomalous growth indicative of such exploitation attempts.