CVE-2026-87080 in Net::IDN::Punycode::PP
Summary
by MITRE • 09/22/2026
Net::IDN::Punycode::PP versions before 2.590 for Perl decode a truncated label to a name containing a character it never encoded in decode_punycode.
The pure-Perl decoder reads one digit at a time with four-argument substr and tests the result with defined to detect the end of the input. substr on an exhausted string returns the empty string rather than undef, so decoding continues past the end. The empty string converts to a digit value below the range, reducing the accumulator, and the decoder derives one extra code point and its position from it. The result is deterministic. The XS backend rejects the same label.
Net::IDN::Punycode uses this backend wherever the XS does not build.
The two backends disagree about what such a label means, so a sender can pick a label that one installation resolves to a name and another rejects.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/22/2026
The vulnerability in Net::IDN::Punycode versions prior to 2.590 represents a critical logic error within the pure-Perl implementation of the Punycode decoding algorithm, specifically affecting how truncated input labels are processed. This flaw arises from an incorrect boundary check mechanism when reading digits sequentially using the Perl substr function with four arguments. In standard Perl behavior, accessing characters beyond the end of a string returns an empty string rather than undef or triggering an error under typical strictures used in this module's logic. The decoder relies on testing whether the extracted character is defined to determine if input has been exhausted; however, because an empty string evaluates as defined but falsy, the loop continues processing past the actual end of the provided data. This leads to a deterministic state where the empty string converts to a numeric value below the valid range for Punycode digits, which in turn reduces the internal accumulator variable used during decoding. Consequently, the algorithm derives one extra code point and its position from this erroneous calculation, resulting in a decoded name that contains characters never present in the original encoded input.
This implementation discrepancy creates a significant security risk due to backend inconsistency within the Net::IDN::Punycode module architecture. The module utilizes an XS (C-based) backend for performance when available, falling back to the pure-Perl version only when the C extension cannot be compiled or loaded. These two implementations handle truncated labels differently; while the XS backend correctly rejects such malformed input as invalid, the Perl backend proceeds with decoding and produces a valid-looking but semantically incorrect domain name. This divergence allows an attacker to craft specific Punycode strings that are accepted by systems running the pure-Perl variant but rejected by those using the XS variant. Such inconsistency undermines the reliability of internationalized domain name resolution across heterogeneous server environments, potentially leading to confusion or misrouting depending on which backend is active at any given time.
From a security operations perspective, this vulnerability aligns with CWE-20 Improper Input Validation and CWE-754: Incorrect Check for Unusual or Exceptional Conditions. The failure to properly detect the end of input constitutes an improper check that allows out-of-bounds logical processing rather than physical memory access, which is characteristic of logic flaws in interpreted languages like Perl. In terms of attack vectors, this could be leveraged in contexts where domain name validation is critical for security controls, such as URL filtering or identity verification systems. Although it does not directly lead to remote code execution, the ability to manipulate decoded output based on backend availability can facilitate phishing attacks by creating subtle variations in displayed domain names that appear valid to some users but are flagged differently by others. This technique exploits the ambiguity introduced by inconsistent parsing logic across different deployment configurations.
Mitigation strategies must focus on immediate patching and defensive coding practices. The primary remediation is upgrading Net::IDN::Punycode to version 2.590 or later, where this boundary condition has been corrected to ensure consistent behavior between both backends. For environments unable to upgrade immediately, developers should implement explicit length checks before invoking the decode function or wrap calls in eval blocks with strict error handling to catch unexpected results. Additionally, security teams should audit applications that rely on domain name normalization for authentication or authorization decisions, ensuring they validate decoded outputs against expected character sets and lengths rather than trusting the decoder alone. Regular updates of Perl modules are essential to maintain integrity in internationalized text processing pipelines, as inconsistencies between XS and pure-Perl implementations can introduce subtle but exploitable discrepancies in security-critical logic flows.