CVE-2016-15059 — Heap Buffer Overflow in Net::IDN::Punycode's XS Encoder

Executive Summary

CVSS Score: 9.8 (Critical)

CVE-2016-15059 is a heap buffer overflow in Net::IDN::Punycode, the Bootstring/Punycode (RFC 3492) codec that ships as part of the Net-IDN-Encode distribution on CPAN — the Perl module widely used to convert internationalized domain names (IDNs) between Unicode and their ASCII/Punycode form. The flaw lives in encode_punycode, specifically in the module's XS (compiled C) backend: the function builds the encoded label directly in the string buffer of the scalar it returns, sizing that buffer from the input length. The write loop that emits the Bootstring digits for each code point checks for remaining room before every digit write — except for the final digit of each encoding round and the terminating NUL byte, which are written unconditionally. An input whose encoded Punycode label exactly fills the allocated buffer causes those two unchecked writes to land past the end of the heap allocation, corrupting adjacent heap memory. Only the XS backend is affected; pure-Perl fallback implementations are not.

A decade-old bug, only now carrying a CVE. Despite the "2016" number, this CVE was reserved on 2026-09-08 and published in the NVD feed on 2026-09-22 — a full decade after the underlying fix (version 2.301) actually shipped. This is not a new 2026 attack against current software; it is a retroactive disclosure. CPANSec, the CVE Numbering Authority (CNA) that now covers CPAN/Perl modules, was established well after this bug was originally fixed, and a 2026 security audit of Net::IDN::Punycode's Bootstring implementation went back and formally catalogued historical issues — including this one — that had never been assigned CVE identifiers. This pattern (a CVE minted years after the code was already patched) is common and does not by itself indicate active exploitation or a fresh vulnerable release; it mainly matters for organizations running old, unpatched, or vendored copies of the module that predate the 2.301 release from a decade ago.

Important complication: the fix for this CVE introduced a different heap bug. The same 2026 audit found that version 2.301 — the release that fixed this overflow — introduced a separate heap use-after-free in decode_punycode (tracked separately as CVE-2026-74766), along with several other related Punycode issues (an integer-overflow out-of-bounds read, an infinite-loop/crash on malformed UTF-8, quadratic-cost CPU exhaustion, and a memory leak on rejected labels). All of these, including this CVE, were resolved together in Net-IDN-Encode version 2.590. The remediation guidance below reflects that: upgrading only to 2.301 is not sufficient.

Vulnerability Overview

Affected Versions

The pure-Perl backend (e.g. the standalone Net::IDN::PP implementation) is not affected by this overflow — only the compiled XS backend builds the output buffer in the vulnerable way. Any application pinned to a Net-IDN-Encode release from before 2.301 — which, given the module's age, includes a meaningful number of long-lived Perl deployments and vendored/bundled copies — is exposed.

Attack Vector

encode_punycode converts Unicode text into ASCII Punycode, so the untrusted input here is any attacker-influenced Unicode string that a Perl application hands to the encoder — most commonly an internationalized domain name, a hostname, or the local part of an email address being normalized to its ASCII form before use in DNS, mail handling, URL construction, or certificate tooling.

1. An application accepts attacker-influenced Unicode text — e.g. a
   submitted domain name, hostname, or email address — and passes it
   to encode_punycode (directly, or via a wrapper such as
   domain_to_ascii / email_to_ascii, or Net::IDN::UTS46::to_ascii,
   which call into the same Punycode encoder).

2. The XS backend allocates the return scalar's string buffer sized
   from the input length, then begins writing the Bootstring-encoded
   label into it one code point at a time.

3. For each code point, the digit-emission loop checks remaining
   buffer room before every digit write — except the last digit of
   each encoding round and the terminating NUL byte, which are
   written unconditionally.

4. If the crafted input's encoded Punycode label exactly fills the
   allocated buffer, that unchecked final-digit write and/or the NUL
   terminator write land past the end of the heap allocation.

5. Adjacent heap memory is corrupted. Depending on heap layout and
   allocator internals at the time, this can crash the process
   (denial of service) or, in the worst case, be leveraged toward
   further memory corruption.

No authentication and no user interaction beyond delivering the crafted string is required — the overflow triggers purely from the content reaching the encoder function, which is why NVD scores this AV:N/AC:L/PR:N/UI:N despite the vulnerable code being a library function rather than a network service itself. The realistic exposure is any Perl service — a mail component, an IDN-aware web form, certificate or DNS tooling — that punycode-encodes externally supplied domain or email strings.

Impact of Successful Exploitation

Immediate Remediation

1. Upgrade Net-IDN-Encode to version 2.590 or later. Version 2.301 alone fixes this specific overflow but is not a safe stopping point — it introduced a different heap use-after-free (CVE-2026-74766) that was only resolved, along with several other related Punycode bugs, in 2.590.
2. Audit for pinned or vendored copies. Because this is a decade-old fix, check for old CPAN snapshots, vendored/bundled copies inside containers, or cpanfile.snapshot entries that predate 2.301 — these are the deployments actually at risk, not current, regularly-updated installs.
3. If immediate upgrade isn't possible, identify every code path that calls encode_punycode (directly or via domain_to_ascii, email_to_ascii, or Net::IDN::UTS46::to_ascii) with externally-supplied input, and treat those paths as high priority for the upgrade.
4. Don't deprioritize this because of the "2016" CVE number. The vulnerable code itself is only a real risk if you are running a build older than 2.301 (or, for the related follow-on bugs, older than 2.590) — verify your actual deployed version rather than assuming age implies irrelevance either way.

Detection Indicators

Post-Remediation Steps

1. Confirm the deployed Net-IDN-Encode version reports 2.590 or later — not merely 2.301 — across all affected services and container images.
2. Re-scan dependency manifests and SBOMs for any other Perl services still vendoring pre-2.301 Punycode code.
3. Review logs for crashes or anomalous domain/email input in the period before remediation, in case exploitation attempts predate the fix.
4. Add Net-IDN-Encode to routine CPAN dependency-update sweeps so future CPANSec advisories are caught promptly — this module has now had multiple related CVEs surface from a single 2026 audit.
5. If interim input-length or character-set validation was added as a mitigation, keep it as defense-in-depth even after upgrading.

References

• NVD — CVE-2016-15059
• Net-IDN-Encode — Changes (GitHub, cfaerber/Net-IDN-Encode)
• Net::IDN::Punycode — MetaCPAN
• Strix.ai — CVE-2016-15059 vulnerability summary