CVE-2026-87080: 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
Net::IDN::Punycode::PP versions before 2.590 for Perl decode a truncated label to a name containing a character it never encoded in decodepunycode.
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.
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 to the inconsistent decoding behavior?
Deployments using Net::IDN::Punycode::PP before 2.590 are affected. Net::IDN::Punycode can use this pure-Perl backend where the XS backend does not build; the XS backend rejects the same truncated labels.
What must an attacker provide to trigger the issue?
An attacker must supply a truncated Punycode label to decode_punycode. The pure-Perl decoder deterministically produces a name containing an extra character, while the XS backend rejects that label.
What is the practical security concern?
The issue creates disagreement between installations about the meaning of a label: one system may resolve it to a name while another rejects it. This is relevant wherever different systems process or validate the same Punycode label using different backends.
What should be done if an installation cannot be updated immediately?
Use the XS backend where available, since it rejects the malformed truncated labels described. Avoid relying on the pure-Perl decoder for validation when backend-consistent handling is required.