Bug 2539007 (CVE-2026-87078)

Summary: CVE-2026-87078 perl-Net-IDN-Encode: Net::IDN::Punycode versions from 2.302 before 2.590 for Perl leak the output buffer on every rejected label in decode_punycode
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: rhel-process-autobot, watson-tool-maintainers
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A memory leak flaw was found in the XS backend of the Perl Net::IDN::Punycode module (part of the Net-IDN-Encode distribution). The decode_punycode function allocates a scalar output buffer before validating the Punycode input. The buffer is released only on the success path, so each of the three croak paths that reject an invalid label leaks the buffer and its allocation. Since no bound is placed on the label length in the to-Unicode direction, an attacker supplying invalid labels can grow the process memory by twice the label length per rejected call, leading to resource exhaustion and denial of service.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-09-22 21:57:35 UTC 
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.