CVE-2026-115906: 
Linux Debian vulnerability analysis and mitigation

CVE-2026-115906 is an AES entry HMAC authentication bypass vulnerability in the zip2 Rust crate (crate name: zip, maintained by zip-rs). The flaw allows an attacker to supply a crafted AES-encrypted ZIP archive whose authentication tag (HMAC-SHA1-80) is never verified, causing the library to return modified or attacker-chosen plaintext without raising an error. Affected versions span from 0.6.0 up to (but not including) 9.0.0. It was published on October 26, 2026, with a CVSS v3.1 base score of 6.5 (Medium) (GitHub Advisory).

The root cause is classified as CWE-354 (Improper Validation of Integrity Check Value) and CWE-1284 (Improper Validation of Specified Quantity in Input). In src/aes.rs, the AesReaderValid::read() method only performs HMAC verification when the internal data_remaining counter reaches exactly zero. Two bypass paths exist: (1) if the underlying bounded reader hits true EOF while data_remaining is still positive (e.g., because the attacker-controlled central directory declares a compressed_size larger than the actual data), the inner reader returns Ok(0), the counter never decrements to zero, and the HMAC block is never executed; (2) if an encrypted entry has zero payload bytes, the early-return guard at the top of read() fires before any authentication occurs. Because AES-CTR is malleable and AE-2 entries skip CRC-32 by design, an attacker who can modify an archive in transit — without knowing the password — can XOR chosen plaintext onto the ciphertext and arrange for the entry to terminate at true EOF, delivering arbitrary content with no integrity error (GitHub Advisory, Fix Commit).

Successful exploitation completely undermines the integrity guarantee of AES-encrypted (AE-x) ZIP entries: an attacker without the password can deliver modified or chosen plaintext to any application that decrypts entries via by_index_decrypt, by_name_decrypt, by_path_decrypt, or password-enabled by_index_with_options. Affected use cases include backup restore pipelines, software artifact/package ingestion, mail attachment processing, and file upload handlers — anywhere untrusted or in-transit archives are decrypted. Confidentiality and availability are not impacted, and there is no memory-safety issue; the loss is solely the integrity assurance that authenticated encryption is meant to provide (GitHub Advisory).

A proof-of-concept is included in the security advisory itself (tests/aes_hmac_bypass.rs), demonstrating three test cases: normal tamper detection, the premature-EOF bypass, and the zero-payload bypass. The PoC works against the published 8.6.0 release without modification. No in-the-wild exploitation has been reported, no threat actor attribution exists, and the vulnerability is not listed in the CISA KEV catalog. The EPSS score is 0.0 at time of publication (GitHub Advisory, Feedly).

1. Obtain a genuine archive: Acquire or intercept a legitimate AES-256 encrypted ZIP archive produced by the target application (e.g., via a man-in-the-middle position on a backup or artifact pipeline).
2. Identify archive structure: Parse the local file header to locate the payload start offset (30 + filename_length + extra_length), the central directory offset, and the end-of-central-directory (EOCD) record.
3. Craft the malicious entry: Copy the local file header, 16-byte AES salt, and 2-byte password verifier verbatim (no password knowledge required). XOR the original ciphertext bytes with original_plaintext[i] XOR desired_plaintext[i] to produce the forged ciphertext. Omit the 10-byte HMAC authentication tag so the entry ends at true EOF.
4. Embed the forged entry: Append the forged entry (header + salt + verifier + forged ciphertext, no tag) into the archive comment area so its data terminates at the file's true EOF.
5. Manipulate the central directory: Update the central directory entry to point to the new local header offset and declare a compressed_size larger than the actual forged data (e.g., add 64 bytes), ensuring data_remaining can never reach zero during reading.
6. Update EOCD comment length: Set the archive comment length field in the EOCD record to cover the appended bytes.
7. Deliver the archive: Serve the crafted archive to the victim application. When it calls by_index_decrypt (or equivalent) with the correct password, the reader hits true EOF before data_remaining reaches zero, the HMAC block never executes, and the forged plaintext is returned without error (GitHub Advisory).

• File System: ZIP archives with a compressed_size declared in the central directory that is significantly larger than the actual data present in the file; archives where the local file entry data terminates at true EOF without a trailing HMAC tag.
• File System: ZIP archives containing an unusually large archive comment section that embeds a duplicate local file header, AES salt, and verifier bytes.
• Logs: Application logs showing successful decryption of AES-encrypted ZIP entries that are immediately followed by data integrity failures in downstream processing (e.g., checksum mismatches on extracted content).
• Network: Unexpected modification of ZIP archives in transit (detectable via transport-layer integrity checks such as TLS certificate pinning or signed artifact hashes) where the archive comment length field is non-zero and the comment contains ZIP local file header magic bytes (PK\x03\x04).

Upgrade the zip crate (zip-rs/zip2) to version 9.0.0, which contains the fix (v9.0.0 Release, Fix Commit). The patch refactors AesReaderValid::read() to: (1) treat a short inner read (read == 0 while data_remaining > 0) as an UnexpectedEof error rather than a clean EOF; (2) invoke HMAC verification for zero-payload entries at the point of the early return; and (3) add a checked subtraction in AesReader::new() that rejects a declared compressed_size below the AES metadata overhead. No configuration-based workaround is available for affected versions; the only remediation is to update the dependency in Cargo.toml to zip = "9.0.0" or later and rebuild.

The vulnerability was reported by security researchers secstant-sigp and Its-Just-Nans, with the fix implemented by Its-Just-Nans (GitHub Advisory). No significant broader media coverage or notable social media commentary has been identified at time of publication.