CVE-2026-57432

What it actually does

Perl versions through 5.43.10 contain an integer overflow in the internal S_measure_struct logic used by pack and unpack template processing. A very large repeat count in a template can cause the signed SSize_t size accumulator to wrap negative. Subsequent handling of position-control template codes such as @, X, and x can incorrectly accept the negative length and advance an internal buffer pointer outside the intended heap buffer. When an application processes attacker-controlled pack or unpack templates, this can result in out-of-bounds heap reads and potential disclosure of adjacent process memory. Depending on allocator behavior, calling context, and how returned data is used, the flaw may also create stability risks and possible memory-corruption side effects.

Why it matters to the business

Systems and applications that allow untrusted users, files, plugins, scripts, or data formats to influence Perl pack or unpack templates may leak sensitive process memory such as secrets, tokens, configuration values, or user data. Perl is widely embedded in automation, system tooling, package scripts, administrative utilities, and legacy application stacks, so the operational risk is highest where Perl code processes externally supplied templates or complex binary formats. The CVSS score is high, but the current EPSS is low, it is not listed in CISA KEV, and no exploit maturity is reported, so prioritization should focus on exposed Perl-based services and applications that use pack/unpack with user-influenced templates.

How an attack unfolds

An attacker first needs a path to influence the template argument passed to Perl's pack or unpack functions. This could occur through an application feature that parses user-supplied binary formats, protocol descriptions, serialization templates, import/export definitions, plugin input, or scripting interfaces. The attacker supplies a crafted template containing an extremely large repeat count combined with position-control codes such as @, X, or x. During template measurement, Perl calculates the expected size by multiplying item size by repeat count and adding it to a signed running total without checking for overflow. The total wraps negative, causing later signed bounds checks to pass incorrectly. Perl then advances the buffer pointer outside the valid heap allocation and reads memory beyond the intended buffer. If the application returns, logs, serializes, or otherwise exposes the resulting unpacked data, the attacker can recover heap contents from the Perl process. There is currently no public evidence in the provided data of active exploitation, ransomware use, or named threat actor activity.

How to fix it

Upgrade affected Perl packages to a fixed vendor release. For Red Hat perl-main, apply RHSA-2026:39997, which fixes perl-main in version 1.03-524.3.hum1. Where immediate patching is not possible, mitigate by preventing untrusted input from controlling pack or unpack templates, allowlisting known-safe templates, rejecting very large repeat counts, and avoiding dynamic construction of templates from request parameters, file contents, plugin metadata, or user scripts. Treat templates as code-like control input, not ordinary data. Restart long-running Perl services after patching so fixed interpreter libraries are loaded.

How to confirm the fix worked

Confirm that all installed Perl packages are updated to the vendor-fixed version or later. On Red Hat-derived systems, query the installed perl-main package and verify that RHSA-2026:39997 or a superseding advisory is applied. Review application code for calls to pack and unpack where the template argument is derived from external input, configuration uploaded by users, parsed files, plugin metadata, or request parameters. Add regression tests using oversized repeat counts and position-control codes to ensure the application rejects unsafe templates and that patched Perl no longer performs out-of-bounds reads. For long-running services, verify processes were restarted after package updates by comparing process start times against patch deployment time.

Typical attack path

1. Identify an application, script, service, import pipeline, or plugin interface that runs affected Perl code.
2. Determine whether attacker-controlled input can influence a pack or unpack template rather than only the data buffer.
3. Craft a Perl pack/unpack template with a very large repeat count that triggers signed SSize_t overflow during S_measure_struct processing.
4. Include position-control template codes such as @, X, or x so the negative measured length bypasses movement checks.
5. Submit the crafted template through the exposed feature or file format.
6. Cause the Perl process to read out-of-bounds heap memory during pack/unpack processing.
7. Recover leaked memory if the application returns, logs, stores, or otherwise exposes the resulting data.

How to detect it

There are no universal network indicators for this vulnerability because exploitation occurs inside Perl template parsing and depends on application-specific exposure. To assess possible prior exploitation, review application logs, API request logs, web access logs, job-processing logs, import/export audit logs, and plugin or script execution logs for unusually large numeric repeat counts or suspicious pack/unpack template strings submitted by users. Focus on inputs containing very large integers combined with Perl template position codes such as @, X, or x. Review crash reports, core dumps, kernel logs, and service supervisor logs for unexplained Perl process crashes or memory errors around suspicious requests, although successful exploitation may only leak memory and not crash. Where application logs capture returned data, investigate anomalous binary output, unexpectedly large responses, or responses containing fragments of secrets, environment variables, heap data, or unrelated user data. Endpoint telemetry may show Perl processes handling unusual files or requests but will not reliably identify the out-of-bounds read without application-level context or memory-safety instrumentation.

• pack(
• unpack(
• S_measure_struct
• @999999999
• X999999999
• x999999999
• @2147483647
• X2147483647
• x2147483647
• @9223372036854775807
• X9223372036854775807
• x9223372036854775807
• panic: memory wrap
• perl: Segmentation fault
• segfault at
• core dumped

What your security team should do

• Inventory systems and containers running Perl versions through 5.43.10, prioritizing internet-facing services, automation platforms, CI/CD workers, file-processing systems, and applications that parse user-supplied binary formats.
• Patch Red Hat perl-main to 1.03-524.3.hum1 via RHSA-2026:39997 or a later fixed release, and restart Perl-based services after upgrade.
• Search code repositories for pack and unpack usage where the template string is not constant or is influenced by user input, uploaded files, plugins, or configuration.
• Implement template allowlisting and reject large repeat counts or position-control constructs in any application-level parser that accepts template-like input.
• Because EPSS is currently low and the issue is not in KEV, prioritize remediation by exposure and data sensitivity rather than treating all internal-only Perl installations as emergency fixes.
• Monitor advisories and exploit intelligence for changes in exploit maturity, EPSS trend, or KEV status, as weaponization would materially increase urgency.