CVE-2026-115907 in zip2
Summary
by MITRE • 10/26/2026
zip is a zip library for Rust that supports reading and writing simple ZIP files. From 5.1.0 until 9.0.0, applications built with the legacy-zip feature can reserve output capacity from an attacker-controlled ZIP64 uncompressed size before validating the compressed stream. The ShrinkDecoder path in src/legacy/shrink.rs can panic with a capacity overflow during ZipArchive::extract, and the Reduce and Implode decoders contain the same unbounded preallocation pattern. An unhandled panic can terminate an archive-processing service. This issue is fixed in version 9.0.0.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/26/2026
The vulnerability identified within the Rust zip library affects versions ranging from 5.1.0 through 9.0.0, specifically impacting applications that utilize the legacy-zip feature set. The core technical flaw resides in the handling of ZIP64 archives where the uncompressed size is specified by an attacker-controlled input prior to any validation of the compressed data stream itself. In these affected versions, when processing a maliciously crafted archive, the library attempts to reserve output capacity based on the declared uncompressed size before verifying whether the actual compressed content matches that expectation or adheres to valid structural constraints. This architectural decision creates a window for resource exhaustion attacks because the system allocates memory proportional to potentially massive and unverified values provided in the ZIP64 header fields rather than limiting allocation to realistic bounds derived from the actual data payload.
The operational impact of this flaw is most severe when utilizing specific decoding paths within the library, particularly the ShrinkDecoder located in src/legacy/shrink.rs. During execution of ZipArchive::extract on a malicious archive, the unbounded preallocation can lead to a capacity overflow condition that triggers an unhandled panic. Since Rust panics are not caught by default unless explicitly handled by the application logic, this results in the immediate termination of the process running the archive extraction service. Furthermore, similar vulnerabilities exist within the Reduce and Implode decoders which share the same flawed pattern of preallocating memory based on attacker-controlled size metadata without sufficient validation. This consistency across multiple decompression algorithms means that an adversary can reliably trigger a denial-of-service condition against any service processing untrusted ZIP files using these legacy features.
From a classification perspective, this vulnerability aligns with CWE-789: Memory Allocation with Excessive Size Value and CWE-400: Uncontrolled Resource Consumption. The attack vector allows for remote exploitation if the affected library is used in a network-facing application that accepts user-uploaded archives or processes files from untrusted sources without prior sanitization of archive metadata. In terms of adversary tactics, this behavior facilitates Denial-of-Service operations as described in MITRE ATT&CK technique T1499: Endpoint Denial of Service, where the attacker leverages resource exhaustion to disrupt availability rather than compromising confidentiality or integrity directly. The reliance on legacy features also highlights risks associated with maintaining backward compatibility code paths that may not adhere to modern security best practices regarding input validation and memory management boundaries.
Mitigation strategies primarily involve upgrading the zip library dependency to version 9.0.0 or later, where this preallocation logic has been corrected to validate inputs before reserving resources. For applications unable to upgrade immediately due to compatibility constraints, it is critical to disable the legacy-zip feature in Cargo.toml configurations if its functionality is not strictly required. Additionally, developers should implement robust input validation at the application layer by inspecting ZIP64 headers for reasonable size limits relative to available system memory before invoking extraction methods. Implementing resource quotas and monitoring mechanisms can also help detect anomalous allocation patterns early, although these are compensatory controls rather than definitive fixes for the underlying library defect.