Critical Parser Differential in Rust zip Crate Enables Security Gateway Bypass and Arbitrary File Overwrite

What happened

A GitHub Security Advisory (GHSA-m665-v7pm-7grj) discloses a critical architectural flaw in the Rust zip crate (versions ≤9.0.4, tracked as CVE-2026-115905). The issue is a parser differential between the crate's two reader implementations. ZipArchive trusts the filename in the Central Directory File Header (CDFH). ZipStreamReader trusts the filename in the Local File Header (LFH). Because the ZIP format stores filenames in both locations independently, an attacker can craft a single archive where the two headers disagree. For example, a CDFH that names a benign file like doc_report.pdf alongside an LFH that names a malicious script. The advisory includes a proof-of-concept showing that a simulated security gateway using ZipArchive approves the archive while a backend extractor using ZipStreamReader writes out the attacker's file, overwriting an existing script on disk.

Why it matters

This is a security-control-bypass primitive, not a memory-safety bug. It targets architectures where one component (an AV scanner, upload gateway, or CDR tool) validates an archive using one parsing strategy while a separate downstream component (an ingestion microservice, cloud function, or extraction worker) writes files to disk using the other. Any Rust service that relies on the zip crate's streaming reader to extract user-supplied archives, especially after that archive passed an earlier automated review step built on the random-access reader, is exposed to arbitrary file overwrite. The advisory escalates this to denial of service and remote code execution depending on what gets overwritten.

What defenders should watch for

• Inventory services and pipelines that depend on the zip crate (directly or transitively) for extracting untrusted or user-submitted archives, and identify which reader API (ZipArchive vs. ZipStreamReader/streaming extraction) each one uses.
• Flag any architecture where archive inspection and archive extraction are performed by different components or at different times. This decoupling is the precondition for exploitation.
• As a hunting angle, look for ZIP uploads where the filename reported by metadata or inspection tooling differs from the filename that appears on disk after extraction. This discrepancy is the core exploit signature.
• As a general mitigation, ensure any single ingestion pipeline uses one consistent, authoritative parsing path for both validation and extraction, and prioritize patching once a fixed zip crate release is available.

Developing intel

This is a same-day advisory and details may evolve as maintainers respond and a patched release is published. This is not a confirmed in-the-wild exploitation report, only a disclosed PoC. For the full technical writeup and proof-of-concept code, see the original advisory: GHSA-m665-v7pm-7grj.