CVE-2026-115906 in Zipinfo

Summary

by MITRE • 10/26/2026

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.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Analysis

by VulDB Data Team • 10/26/2026

The vulnerability identified within the zip library for Rust affects versions ranging from 0.6.0 through 9.0.0, specifically targeting the AES entry reader implementation located in src/aes.rs. The core technical flaw lies in a critical logic error regarding the verification of HMAC authentication tags during the decryption process. In secure cryptographic implementations, it is imperative to verify the integrity and authenticity of data before trusting its contents or proceeding with further operations. However, this library only performs the HMAC verification when an internal attacker-controlled data counter reaches zero. This design choice creates a significant gap in security assurance because it assumes that all encrypted payloads will be fully consumed by the reader under normal circumstances.

The operational impact arises from specific edge cases where the underlying bounded reader encounters the actual end of the archive file while the data_remaining variable remains positive, or when an encrypted entry contains no payload at all. In these scenarios, the reader returns a clean end-of-stream signal without ever reading and comparing the authentication tag against the decrypted content. Consequently, applications utilizing functions such as by_index_decrypt, by_name_decrypt, by_path_decrypt, or password-enabled by_index_with_options may accept modified plaintext data without triggering an authentication error. This effectively bypasses the integrity checks provided by AES encryption with HMAC, allowing potential attackers to manipulate encrypted ZIP entries if they can control the structure of the archive file and trigger these specific boundary conditions.

From a classification perspective, this vulnerability aligns closely with CWE-347, which describes Improper Verification of Cryptographic Signature. The failure to verify the authentication tag constitutes an improper verification mechanism that undermines the security guarantees provided by the encryption algorithm. Furthermore, in the context of the MITRE ATT&CK framework, this flaw facilitates techniques related to Tampering or Integrity Bypass, as it allows for the modification of data without detection. An attacker could potentially inject malicious payloads into encrypted archives if they can exploit these specific conditions where the HMAC check is skipped due to premature end-of-stream signals.

The severity of this issue depends heavily on how the zip library is integrated into downstream applications and whether those applications trust decrypted content from untrusted sources. If an application processes ZIP files obtained from external or potentially hostile environments, it may inadvertently execute malicious code or process corrupted data that has been tampered with during transit or storage. The lack of authentication verification means there is no guarantee that the decrypted plaintext matches what was originally encrypted by a legitimate party. This undermines both confidentiality and integrity assurances typically expected from AES-encrypted archives.

To mitigate this vulnerability, organizations must ensure they are not using any version of the zip library between 0.6.0 and 9.0.0 inclusive. The issue has been resolved in version 9.0.0, which corrects the logic to properly verify HMAC tags regardless of whether the data counter reaches zero or if an end-of-stream condition is encountered prematurely. Developers should update their dependencies immediately and review any custom implementations that might rely on similar patterns of reading bounded streams with encryption. Additionally, implementing defense-in-depth strategies such as validating file structures before decryption and monitoring for unusual archive sizes can provide additional layers of security against exploitation attempts involving malformed or truncated encrypted archives.

Responsible

GitHub M

Reservation

10/23/2026

Disclosure

10/26/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

very low

Sources

Interested in the pricing of exploits?

See the underground prices here!