CVE-2026-115909 in zip2
Summary
by MITRE • 10/26/2026
zip is a zip library for Rust that supports reading and writing simple ZIP files. From 1.3.0 until 9.0.0, ZipArchive::extract in src/read/mod.rs calls Vec::with_capacity for a symbolic link target using the attacker-controlled ZIP64 uncompressed_size before reading entry data. A small archive can request an impossible capacity, causing the infallible allocation path to abort the process before the entry is validated. The failure cannot be contained with catch_unwind or a worker thread, allowing repeated denial of service in archive-processing applications. This issue is fixed in version 9.0.0.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/26/2026
The vulnerability identified within the Rust zip library affects versions ranging from 1.3.0 through 9.0.0 and centers on improper handling of memory allocation during the extraction process for ZIP archives containing symbolic links. The core technical flaw resides in the ZipArchive::extract function located in src/read/mod.rs, where the implementation attempts to pre-allocate a vector buffer using Vec::with_capacity based on the uncompressed_size field extracted from the archive metadata. This behavior is particularly problematic when processing entries that represent symbolic links, as the library incorrectly utilizes the ZIP64 uncompressed_size value for this allocation decision rather than validating it against realistic constraints or expected payload sizes. By relying directly on an attacker-controlled input parameter without sufficient bounds checking prior to memory reservation, the application exposes itself to a critical resource management failure.
This specific implementation error leads to a denial of service condition due to the invocation of an infallible allocation path that aborts the process when requested capacity exceeds system limits or available resources. In many computing environments, requesting an excessively large buffer size triggers immediate termination rather than returning an error code that could be gracefully handled by the application logic. Because this failure occurs during the initial setup phase before entry data validation takes place, it bypasses standard security checks designed to filter malicious content after parsing begins. Consequently, a small but carefully crafted ZIP archive can trigger this abort condition reliably, resulting in immediate process termination without any opportunity for error recovery or graceful degradation of service.
The operational impact of this vulnerability is severe because the crash cannot be contained using common resilience patterns such as catch_unwind or execution within isolated worker threads. In typical application architectures that rely on thread-based concurrency to maintain availability during processing tasks, a panic in one thread often propagates up and terminates the entire process if not explicitly caught at every level of abstraction. Since this allocation failure causes an abort rather than a recoverable error state, repeated attempts by an attacker to submit malicious archives can lead to sustained denial of service against archive-processing applications. This makes the vulnerability particularly dangerous for services that accept user-uploaded files or process untrusted data streams as part of their normal operations.
From a classification perspective, this issue aligns with CWE-789: Memory Allocation with Excessive Size Value and CWE-400: Uncontrolled Resource Consumption. The attack vector is categorized under the MITRE ATT&CK framework technique T1496: Resource Hijacking, specifically within the sub-category of Denial of Service via resource exhaustion or application crash. To mitigate this risk, organizations relying on affected versions must upgrade to version 9.0.0 or later where the allocation logic has been corrected to validate input sizes before attempting memory reservation. Additionally, defensive coding practices such as implementing strict size limits for all incoming archive entries and utilizing catch_unwind at critical failure points can provide temporary protection until patching is completed. Security teams should also audit their deployment pipelines to ensure that no legacy versions of the zip library remain in production environments where they are exposed to untrusted input sources.