News

Rust zip headers cloak overwrite targets

Louis Stowasser
Louis Stowasser
Sunday 1 November 2026

CVE-2026-115905 is a flaw in zip, the open-source Rust library applications embed to read and write ZIP archives. It matters to the people running upload-processing microservices, SaaS back ends, background workers and cloud functions—not operators of a separate ZIP product. Any organisation that accepts archives and hands them between inspection and extraction components can be exposed, including containerised workloads and software that inherits the crate indirectly.

A ZIP records each member twice: once in a Local File Header beside its data, and again in the Central Directory index at the end. Before the fix, ZipArchive treated the central-directory name as authoritative, while ZipStreamReader extracted according to the local-header name. An attacker can craft an archive whose index advertises a harmless path for a gateway, antivirus or allowlist to inspect, but whose streaming entry names a different destination.

One archive, two answers

That disagreement is the security-control bypass. A service might approve report.txt after random-access inspection, then a downstream streaming extractor writes an attacker-selected file. The extractor's path-preparation routine may stop simple traversal, but it cannot make the filename match the one the earlier control saw. If the target is a script, executable, configuration or another file consumed by a service, later use can turn the overwrite into code execution.

The attacker needs a route to submit a crafted ZIP to a vulnerable workflow; no authenticated foothold on the host is inherent to the flaw. The outcome still depends on permissions, the extraction directory, and whether a useful overwrite target is reachable. The vendor advisory documents arbitrary overwrite and this conditional route to execution under GHSA-m665-v7pm-7grj.

A public proof of concept does exist: the advisory publishes an integration test, and a separate live sandbox demonstration uses crafted archives against deliberately vulnerable code. That is not evidence of attacks. No exploitation in the wild, attributable incident or campaign had been confirmed as of November 1, 2026, and the CVE was absent from CISA's KEV catalogue snapshot released October 30.

Upgrade—and turn on the check

The vendor lists zip 9.0.4 and earlier as affected and 9.0.5 as patched; 9.0.5 was released October 17, 2026. But this is not a conventional upgrade-and-forget fix. ZipStreamReader::new leaves enforce_header_consistency false for backward compatibility, so applications using the streaming API must explicitly call enforce_header_consistency(true). That activates comparisons between local and central names, along with other duplicated metadata, and rejects a mismatch.

Teams should inventory direct and transitive uses, upgrade to 9.0.5, enable enforcement wherever untrusted archives are streamed, and test workflows that separate scanning from extraction. Until then, isolate extractors with minimal filesystem permissions, use a fresh destination per job, and avoid placing service-consumed files beneath it. SecAlerts monitors an organisation's actual software stack and alerts on new vulnerabilities affecting the products it runs; here, that visibility needs to be paired with the application-level opt-in that actually contains the risk.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203