Perl CVE-2026-57432

Exploitation requires the application to construct a pack or unpack template from attacker-influenced input - specifically an oversized item repeat count - combined with use of the @, X, or x position codes that perform signed-length pointer moves; running Perl at or below version 5.43.10. What limits it: templates in the vast majority of Perl programs are static/hardcoded, so an attacker who controls only the packed DATA (not the template structure) cannot trigger the wrap; there is no authentication or user-interaction requirement in the code path itself (PR:N/UI:N), but the non-default 'template derived from untrusted input' pattern is the decisive prerequisite and is uncommon in practice.

Signals are mixed and warrant scrutiny. The published CVSS 3.1 vector (AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, 8.4 High) rates confidentiality, integrity AND availability as High, but the description characterizes the primitive as a read-only out-of-bounds disclosure - integrity impact in particular appears overstated, so treat I:H skeptically and verify with the vendor. No EPSS score, KEV entry, or SSVC decision data was provided; there is no CISA KEV listing, so this is not confirmed actively exploited, and no proof-of-concept is referenced - no public exploit identified at time of analysis. The most important real-world limiter is not in the raw score: exploitation requires the application to derive the pack/unpack template (specifically a repeat count) from untrusted input, which is an uncommon coding pattern - most Perl programs use static templates. Net assessment: a genuine memory-disclosure bug worth patching promptly on multi-tenant or input-driven Perl systems, but the practical attack surface is far narrower than the 8.4 suggests, making this a moderate rather than emergency priority absent evidence of a vulnerable template pattern.

A Perl web service builds a pack/unpack template from client-supplied parameters (for example, a binary-protocol parser that lets the caller specify field repeat counts). An attacker submits a template containing an enormous repeat count together with a @, X, or x position code, overflowing the size total; the interpreter then reads heap memory past the buffer and returns those bytes in the response, leaking secrets such as keys or other users' data. No proof-of-concept is referenced, and the attack requires the application to feed untrusted data into the template rather than the data stream alone.