The vulnerability in versions of Net::IDN::Punycode::PP before 2.590 causes the pure‑Perl Punycode decoder to read past the end of a label. When the decoder slices an exhausted string it receives an empty string instead of undefined, which is treated as an invalid digit and reduces the accumulated value. This logic produces an extra Unicode code point, leading the decoder to return a hostname that contains a character it never encoded. The XS backend does not exhibit this behaviour; it rejects the problematic label. The discrepancy makes the result deterministic but inconsistent between installations that use the pure‑Perl decoder and those that use the XS backend.

The affected product is the Perl module Net::IDN::Punycode::PP. Versions earlier than 2.590 are impacted because the pure‑Perl decoder is used when the XS backend cannot be built. Systems that rely on this module for Punycode decoding – for example, web applications, DNS libraries, or any software that performs IDN validation – are susceptible to inconsistent hostname resolution.

Because the flaw lies in how Punycode is decoded, an attacker can craft a Punycode label that will resolve to one name on a vulnerable system while resolving to a different name on a system that has the fixed parser or the XS backend. This discrepancy can be exploited to bypass hostname checks, impersonate domains, or facilitate phishing and social‑engineering attacks. The CVSS score is 9.1, and the EPSS score is < 1%, indicating limited publicly known exploitation. The flaw is not listed in CISA KEV, but the deterministic nature of the bug means the risk is primarily in environments where hostname consistency is critical.