CVE-2026-57433

What it actually does

Storable before version 3.41 for Perl contains a signed integer overflow in SX_HOOK record deserialization. When Storable::thaw or Storable::retrieve processes a crafted serialized blob, retrieve_hook_common reads a signed 32-bit item count and passes count + 1 to av_extend. If the attacker supplies the maximum signed 32-bit value, the addition wraps to a negative value, causing av_extend to panic and terminate the deserialization process. In services that deserialize attacker-controlled Storable data, this can cause process crashes and denial of service. Because unsafe deserialization occurs in a component that reconstructs Perl data structures and hook-related records, any exposure should be treated as high risk, although the described primitive is primarily a crash condition based on the available details.

Why it matters to the business

Applications, APIs, workers, or automation that accept untrusted Storable data can be crashed remotely by a crafted payload, causing service interruption, failed jobs, degraded availability, and potential cascading operational failures if supervisors repeatedly restart vulnerable processes. The CVSS score is critical, but current exploitation signals are limited: EPSS is low, there is no known CISA KEV listing, no ransomware association, and no public exploit maturity reported. Organizations should still prioritize remediation where Storable deserialization is reachable from users, network inputs, message queues, file uploads, caches, or partner integrations.

How an attack unfolds

An attacker first identifies an application path that passes externally influenced data into Perl Storable deserialization, commonly through Storable::thaw on a byte string or Storable::retrieve on a file. The attacker then supplies a crafted Storable blob containing an SX_HOOK record with an item count set to the maximum signed 32-bit value. During deserialization, the vulnerable code adds one to that count before extending a Perl array. The addition overflows into a negative value, av_extend receives an invalid negative size, and the Perl interpreter raises a panic. In typical server or worker deployments, this terminates the process handling the input, which can be repeated to cause sustained denial of service. No named threat actor activity or confirmed in-the-wild exploitation is currently indicated by the provided data.

How to fix it

Upgrade the Perl Storable module to version 3.41 or later wherever it is installed or bundled. If Storable is supplied by the operating system, language distribution, vendor appliance, or application package, apply the relevant vendor update that includes the fixed Storable release. Rebuild and redeploy containers, static application bundles, and Perl environments that vendor or pin older Storable versions. Where immediate upgrade is not possible, prevent Storable::thaw and Storable::retrieve from processing untrusted data, reject serialized payloads from remote users, restrict file locations used for retrieval, add strict input provenance checks, and isolate deserialization workloads with process supervision, resource limits, and crash containment. Do not rely on authentication alone if low-privileged users can influence serialized blobs.

How to confirm the fix worked

Confirm the installed Storable version is 3.41 or later in every runtime, container image, application bundle, and host package where Perl code executes. For CPAN-based installs, run a version check such as perl -MStorable -e 'print $Storable::VERSION, "\n"' and verify the result is at least 3.41. For OS packages, use the platform package manager to verify that the vendor package includes the fixed Storable code. Review code and dependency manifests for direct use of Storable::thaw, Storable::retrieve, lock_retrieve, or fd_retrieve and determine whether any inputs are user-controlled, network-provided, queue-delivered, or read from writable locations. After patching, restart long-running services and workers so the fixed module is loaded. Validate exposure reduction by confirming that untrusted inputs are not passed to Storable deserialization and that vulnerable package versions no longer appear in software composition analysis, container scans, or runtime inventories.

Typical attack path

1. Find an exposed feature, API, job consumer, file parser, cache loader, or integration that accepts serialized Perl Storable data.
2. Send or place a crafted Storable payload that will be passed to Storable::thaw or Storable::retrieve.
3. Embed an SX_HOOK record with a signed 32-bit item count of 2147483647.
4. Trigger deserialization of the crafted blob.
5. Cause the count + 1 calculation to overflow and pass a negative value to av_extend.
6. Crash the Perl process with a panic during deserialization.
7. Repeat delivery to create persistent application, worker, or service denial of service.

How to detect it

To determine whether exploitation has already occurred, review application logs, Perl stderr output, web server error logs, process supervisor logs, container logs, systemd journal entries, crash dumps, and centralized observability data for unexpected Perl process termination during Storable deserialization. Focus on events involving Storable::thaw, Storable::retrieve, retrieve_hook_common, SX_HOOK, av_extend, or Perl panic messages. Correlate crashes with inbound requests, file uploads, queue messages, cache objects, or partner data deliveries immediately preceding the termination. Look for repeated requests or messages that consistently crash the same endpoint or worker, especially from the same source IP, account, queue producer, or file drop location. Since no public exploit indicators or actor-specific infrastructure are provided, detection should emphasize behavioral signs: repeated interpreter panics, abnormal worker restarts, malformed serialized payloads, and deserialization failures close in time to process exits.

• panic: av_extend
• retrieve_hook_common
• SX_HOOK
• Storable::thaw
• Storable::retrieve
• lock_retrieve
• fd_retrieve
• Storable.pm
• item count 2147483647
• 2147483647
• Perl panic
• panic:
• terminated during deserialization

What your security team should do

• Inventory all Perl applications and third-party products that include or depend on Storable, prioritizing internet-facing services, APIs, asynchronous workers, file ingestion pipelines, and systems that process partner-supplied data.
• Upgrade Storable to 3.41 or later and redeploy affected services, containers, and packaged applications.
• Search source code and runtime configurations for Storable::thaw, Storable::retrieve, lock_retrieve, and fd_retrieve, then classify whether the serialized input can be influenced by an attacker.
• Block or disable workflows that deserialize untrusted Storable blobs until patched, especially upload handlers, queue consumers, cache loaders, and import features.
• Add application-level validation so only trusted, authenticated, integrity-protected serialized data is accepted, preferably replacing Storable for untrusted interchange formats.
• Review crash logs and process supervisor events from the publication date onward for Perl panics associated with Storable deserialization or av_extend.
• Add SIEM detections for repeated Perl process crashes, panic messages, or failed requests associated with deserialization endpoints.
• Because EPSS is currently low and the issue is not in KEV, prioritize based on reachability: remotely reachable deserialization paths first, internal batch-only uses afterward.