lee1981 (@lee1981b) on X

What it is

CVE-2026-115905 is an interpretation-conflict flaw (CWE-436, plus CWE-20) in the Rust zip crate from zip-rs/zip2. The CNA rates it CVSS v4.0 10.0 (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:L) and lists versions below 9.0.5 as affected. The repository advisory says through 9.0.4. NVD is Awaiting Analysis. The CVE was published on 26 October 2026, and 9.0.5 was released on 17 October 2026.

How it works

ZipArchive reads central-directory metadata, while ZipStreamReader reads local file headers in order. A crafted archive can show a clean filename list to one reader and produce a different file in the other. A scanner on one path can therefore approve an archive that a streaming extractor then writes differently, overwriting a file the scanner never saw named. A destination-relative name can still hit a writable trusted file.

Preconditions / Affected

• Attacker-controlled archives must reach a pipeline where inspection and extraction use different reader paths.
• The application must embed the Rust zip crate. A standalone ZIP utility's version does not identify an embedded library, and other operating systems' ZIP tools are not implicated.
• Code execution needs more: the written content, worker permissions and a consumer that loads the file. Root, container escape and credential theft are not automatic.
• Debian's tracker at the cutoff still marked rust-zip as vulnerable in bookworm (0.6.3-3), trixie (2.5.0-1) and forky/sid (5.1.1+dfsg-1), with unstable unfixed.
• CISA KEV had no match (catalogue 2026.10.26). EPSS returned no data. No active exploitation was established. A public demonstration exists in the vendor advisory.

What to do

1. Resolve the real build from the built application's Cargo.lock or SBOM, including duplicate versions and git sources, and join it to the deployed image or executable digest. Cargo.toml requirements alone are not enough. Include old workers, queued jobs and replicas.
2. Upgrade to 9.0.5 or later, then turn the checks on. In tagged 9.0.5, ZipStreamReader::new sets enforce_header_consistency to false for backward compatibility. A builder method enables it. ZipArchive exposes validate_header_consistency for explicit validation. Check every call site, including wrappers and custom visitors.
3. Gate output. Extract into isolated staging and promote or let consumers read it only after full validation and policy success. Failed jobs must not release staging or trigger watchers.
4. To investigate, follow ZIP digest, then job, inspection decision, extraction worker, written file and later consumer. Keep timestamps, process identity and job IDs at each stage. Preserve original archive bytes without extracting them.
5. Escalate on an unexpected overwrite, output consumed after a validation failure, or corroborated unauthorised execution. A dependency or mismatch finding alone does not show compromise.

Caveats

• Extraction is not atomic. The streaming flow calls the file visitor, and extraction creates files, before the later central-directory comparisons finish. An error can therefore arrive after files are written. The consistency method's description promises rollback, but extract's documentation says files may remain after an error. Static review found no rollback routine.
• Upgrading, enabling validation, completing validation and releasing output safely are separate acceptance questions.
• The advisory's demonstration text mixes "10.0 / 9.9" labels. The post keeps the published v4.0 score. No CVSS v3.1 assessment was available.
• The source review was static. No reproduction or remediation test was run, and the six-step trail is CyberForge guidance, not a vendor detector. No campaign IOCs were verified. RustSec's zip entries cover separate symlink and permission issues.