Live › vulnerability › CVE-2026-115906
Go to dashboardThe zip Rust crate, versions 0.6.0 through 8.x, can return a clean end of stream for an AES-encrypted entry without verifying its authentication tag when the archive is truncated or the entry has no payload. An attacker who can modify an encrypted archive can get tampered plaintext accepted without an authentication error.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-26 17:31 UTC. All times on this page are UTC.
Applications that read AES-encrypted ZIP entries in Rust using the zip crate's decrypt or password-enabled reader APIs, where the archive can come from an untrusted or tamperable source. Projects that only write unencrypted zips or never decrypt untrusted archives can skip it.
No product ranges from the sources yet.
grep -A1 'name = "zip"' Cargo.lockby_index_decrypt, by_name_decrypt, by_path_decrypt or by_index_with_options with a password in the project source9.0.0 or later with cargo update -p zipEach row is the first time that source carried this signal. The analyst’s rows are its own findings.
zip is a zip library for Rust that supports reading and writing simple ZIP files. From 0.6.0 until 9.0.0, the AES entry reader in src/aes.rs verifies its HMAC only when the attacker-controlled data counter reaches zero. If the underlying bounded reader reaches the real end of the archive while data_remaining is still positive, or if an encrypted entry has no payload, the reader can return a clean end of stream without reading and comparing the authentication tag. Applications using by_index_decrypt, by_name_decrypt, by_path_decrypt, or password-enabled by_index_with_options can therefore accept modified plaintext without an authentication error. This issue is fixed in version 9.0.0.
This page as .md · .json · in your agent: get_signal("CVE-2026-115906")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.