Rust zip crate flaw lets archives hide a second filename

A critical flaw in the Rust zip crate lets a single archive present one filename to a scanner and a different one to the code that unpacks it, according to a GitHub security advisory published on 28 October 2026. The issue is tracked as CVE-2026-115905 and affects all versions up to and including 9.0.4. The advisory rates it critical, citing a CVSS score of 9.9 to 10.0.

The cause is a parser differential, meaning two parts of the same library disagree about what an archive contains. ZIP files record each entry twice: once in a local file header that sits just before the compressed data, and once in the central directory, an index at the end of the file. The advisory says the crate's random-access reader, ZipArchive, treats the central directory as authoritative and ignores the local header name entirely. Its streaming reader, ZipStreamReader, does the opposite and writes files to disk using the unverified name from the local header.

That split matters for any pipeline that inspects an archive with one reader and extracts it with the other. The advisory sets out a scenario in which an attacker uploads a file whose central directory declares a harmless doc_report.pdf while the local header declares a shell script. A gateway, antivirus or content-sanitising service that parses the central directory sees only the PDF and lets the file through. A backend worker that then extracts the archive with the streaming reader writes the script instead.

Because the attacker controls the name in the local header, they can point it at a file that already exists on the target system. The advisory's worked example overwrites a production cron_worker.sh health-check script with attacker-supplied shell commands, destroying the original file and planting a payload in its place. The advisory describes the result as both a denial of service and remote code execution, and includes a Rust integration test that reproduces the chain end to end along with its test output.

The advisory also points to an existing feature of the library as part of the problem. It says src/write.rs exposes an API called shallow_copy_file, which adds a new central directory entry under an alias name that points at an existing file without updating the original local header. In other words, the crate ships a supported way to produce archives whose two headers disagree.

The advisory names the specific code paths involved: src/read/zip_archive.rs for the central-directory-first lookups, and lines 86 to 141 of src/read/stream.rs for the streaming visit and extract functions that write to disk without checking the central directory index.

The technique is relevant to anyone building automated file-handling systems, including agent workflows that accept uploads, scan them and then unpack them in a separate step. The scanning stage and the extraction stage only provide protection if they agree on what the file is. The advisory does not state that the flaw has been exploited outside the proof of concept.