CVE-2026-115906: AES Entry HMAC Authentication Bypass in Rust zip Crate

The zip crate (zip-rs/zip2) is a widely used Rust library for reading and writing ZIP archives. Among its supported features is WinZip AE-x (AE-1 and AE-2) encryption, which secures archive entries using Advanced Encryption Standard in Counter mode (AES-CTR) paired with a 10-byte HMAC-SHA1-80 authentication tag. When extracting password-protected archives via APIs such as ZipArchive::by_index_decrypt or ZipArchive::by_name_decrypt, applications rely on the library to enforce both confidentiality and data integrity.

In versions >= 0.6.0 and < 9.0.0, the AES decryption implementation in src/aes.rs contains a logic flaw in how stream completion and integrity verification are coupled. Specifically, the AesReaderValid::read implementation only triggers the HMAC-SHA1-80 verification routine when its internal byte counter (data_remaining) decrements to zero after a read operation. This counter is computed directly from the unauthenticated compressed_size field located in the ZIP entry's header.

If an attacker inflates the declared compressed_size in the header and positions the ciphertext at the physical end of the file, the underlying reader encounters an end-of-file (EOF) condition before data_remaining reaches zero. Under standard Rust std::io::Read semantics, the inner reader returns Ok(0) upon hitting EOF. The vulnerable AesReaderValid implementation passes this Ok(0) directly to the caller without checking whether data_remaining is still non-zero, bypassing the HMAC tag comparison.

This weakness is classified under CWE-354 (Improper Validation of Integrity Check Value) and CWE-1284 (Improper Validation of Specified Quantity in Input). Because AES-CTR is a malleable stream cipher and the WinZip AE-2 format explicitly suppresses standard CRC-32 checksum validation to prevent small-file plaintext recovery, the HMAC tag is the sole integrity control. Bypassing it allows an unauthenticated attacker who does not know the encryption password to alter known plaintext into arbitrary forged plaintext.

To understand the root cause of CVE-2026-115906, it is necessary to examine the structure of a WinZip AE-x encrypted entry and how src/aes.rs processes it. An AE-x entry stream consists of four sequential components: a variable-length salt (8, 12, or 16 bytes depending on key size), a 2-byte password verification value, the AES-CTR encrypted payload of $N$ bytes, and a trailing 10-byte HMAC-SHA1-80 authentication code (AUTH_CODE_LENGTH). When AesReader::new initializes, it calculates the expected payload length (data_length) by subtracting the fixed metadata overhead (salt length, 2-byte verifier, and 10-byte authentication code) from the header's compressed_size.

During decryption, AesReaderValid wraps the underlying reader and tracks progress using self.data_remaining, which starts at data_length. On each call to read(&mut self, buf: &mut [u8]), the reader limits the read request to min(buf.len(), self.data_remaining), decrypts the returned bytes in-place by applying the AES-CTR keystream, updates the running HMAC state over the ciphertext, and subtracts the number of bytes read (read) from self.data_remaining.

The vulnerability manifests in three distinct failure modes within src/aes.rs:

1. Premature EOF Bypass (data_remaining > 0 at EOF): When the underlying reader reaches the physical end of the stream before delivering all declared bytes, self.reader.read() returns Ok(0). The code subtracts 0 from self.data_remaining, leaving self.data_remaining > 0. Because the subsequent check if self.data_remaining == 0 evaluates to false, the HMAC verification block is skipped, and Ok(0) is returned to the caller. Standard consumers such as std::io::Read::read_to_end interpret Ok(0) as a normal stream termination and accept the decrypted buffer as complete and authentic.
2. Zero-Length Payload Bypass (data_length == 0): If an encrypted entry has an empty payload (compressed_size equals the exact metadata overhead), self.data_remaining is initialized to 0. At the very beginning of AesReaderValid::read, an early guard clause checks if self.data_remaining == 0 { return Ok(0); }. Consequently, on the first call to read(), the function returns Ok(0) immediately without ever reading or verifying the 10-byte HMAC tag for the empty file.
3. Unchecked Arithmetic Underflow: In AesReader::new, the subtraction compressed_size - (PWD_VERIFY_LENGTH + AUTH_CODE_LENGTH + aes_mode.salt_length()) was performed inside a const fn without verifying that compressed_size was greater than or equal to the metadata overhead. Supplying a malformed archive with a smaller compressed_size causes an integer underflow.

In versions prior to 9.0.0, AesReader::new and AesReaderValid::read in src/aes.rs lacked bounds validation on initialization and failed to account for premature stream termination or empty payloads during read operations.

// Vulnerable code in src/aes.rs (prior to 9.0.0)
impl<R: Read> AesReader<R> {
    pub const fn new(reader: R, aes_mode: AesMode, compressed_size: u64) -> AesReader<R> {
        // BUG 3: Unchecked subtraction can underflow if compressed_size < overhead
        let data_length = compressed_size
            - (PWD_VERIFY_LENGTH + AUTH_CODE_LENGTH + aes_mode.salt_length()) as u64;
 
        Self {
            reader,
            aes_mode,
            data_length,
        }
    }
}
 
impl<R: Read> Read for AesReaderValid<R> {
    fn read(&mut self, buf: &mut [u8]) -> io::Result<usize> {
        // BUG 2: If data_length was 0 initially, returns Ok(0) immediately without verifying HMAC
        if self.data_remaining == 0 {
            return Ok(0);
        }
 
        let to_read = (buf.len() as u64).min(self.data_remaining) as usize;
        let read = self.reader.read(&mut buf[..to_read])?;
 
        self.cipher.apply_keystream(&mut buf[..read]);
        self.hmac.update(&buf[..read]);
 
        self.data_remaining -= read as u64;
 
        // BUG 1: If self.reader.read() returned 0 at physical EOF while data_remaining > 0,
        // this branch is skipped and Ok(0) is returned to the caller.
        if self.data_remaining == 0 {
            self.finalized = true;
            let mut read_auth_code = [0; AUTH_CODE_LENGTH];
            self.reader.read_exact(&mut read_auth_code)?;
            let computed_auth_code = &self.hmac.finalize_reset().into_bytes()[0..AUTH_CODE_LENGTH];
 
            if !constant_time_eq(computed_auth_code, &read_auth_code) {
                return Err(Error::new(
                    ErrorKind::InvalidData,
                    "Invalid authentication code, this could be due to an invalid password or errors in the data",
                ));
            }
        }
 
        Ok(read)
    }
}

Commit ec265db0b0602f8ffb9479327397bddefb7e2216 resolves all three issues. First, AesReader::new was changed from a const fn returning AesReader<R> to a fallible function returning ZipResult<AesReader<R>>, explicitly checking that compressed_size >= metadata_len before subtracting. Second, AesReaderValid now stores the original data_length alongside data_remaining and extracts HMAC verification into a dedicated verify_hmac(&mut self) helper method.

// Patched code in src/aes.rs (version 9.0.0)
impl<R: Read> AesReader<R> {
    pub fn new(reader: R, aes_mode: AesMode, compressed_size: u64) -> ZipResult<AesReader<R>> {
        let metadata_len = (PWD_VERIFY_LENGTH + AUTH_CODE_LENGTH + aes_mode.salt_length()) as u64;
        // FIX 3: Reject compressed_size smaller than required AES metadata
        if compressed_size < metadata_len {
            return Err(invalid!("Compressed size of AES data is invalid"));
        }
        let data_length = compressed_size - metadata_len;
        Ok(Self {
            reader,
            aes_mode,
            data_length,
        })
    }
}
 
impl<R: Read> Read for AesReaderValid<R> {
    fn read(&mut self, buf: &mut [u8]) -> io::Result<usize> {
        if self.data_remaining == 0 {
            // FIX 2: Ensure empty payloads still undergo HMAC verification on first read
            if self.data_length == 0 && !self.finalized {
                self.verify_hmac()?;
            }
            return Ok(0);
        }
 
        let to_read = (buf.len() as u64).min(self.data_remaining) as usize;
        let read = self.reader.read(&mut buf[..to_read])?;
 
        self.hmac.update(&buf[..read]);
        self.cipher.apply_keystream(&mut buf[..read]);
 
        self.data_remaining -= read as u64;
 
        if self.data_remaining == 0 {
            self.verify_hmac()?;
        } else if read == 0 && self.data_remaining > 0 {
            // FIX 1: Detect premature EOF when bytes are still expected
            return Err(Error::new(
                ErrorKind::UnexpectedEof,
                "Read 0 bytes of AES data but still contains remaining data",
            ));
        }
 
        Ok(read)
    }
}

> [!NOTE] > In the patched verify_hmac method, self.finalized is checked and set to true before reading the authentication code. One subtle detail in the patch diff is that when self.data_length == 0, calling read() once triggers self.verify_hmac()? and sets self.finalized = true. If a caller invokes read() a second time on that same zero-length entry after receiving Ok(0), self.data_length == 0 is still true, causing verify_hmac() to be called a second time and return an ErrorKind::InvalidData ("Tried to use an already finalized HMAC"). Standard Read consumers stop reading upon receiving Ok(0) (when buf is non-empty), and passing an empty buffer buf = &mut [] on a non-empty entry hits read == 0 && self.data_remaining > 0 if not guarded. However, for standard extraction workflows, the fix completely closes the premature EOF and zero-length authentication bypasses.

Exploiting CVE-2026-115906 to inject chosen plaintext into an encrypted ZIP archive requires no knowledge of the archive password, provided the attacker has access to an existing encrypted entry whose plaintext prefix is known (a known-plaintext scenario) and uses the Stored (uncompressed) method or a predictable compression stream. Because AES-CTR encrypts data by XORing the plaintext $P$ with a keystream $K$ derived from the password and salt ($C = P \oplus K$), an attacker who knows $P_{\text{genuine}}$ for a given ciphertext $C_{\text{genuine}}$ can compute a forged ciphertext $C_{\text{forged}}$ that decrypts to arbitrary chosen plaintext $P_{\text{forged}}$ of the same length:

$$C_{\text{forged}} = C_{\text{genuine}} \oplus P_{\text{genuine}} \oplus P_{\text{forged}}$$

In a normal archive, modifying $C_{\text{genuine}}$ invalidates the trailing 10-byte HMAC-SHA1-80 tag. Furthermore, if the attacker simply increases compressed_size in place within a multi-file archive or before the Central Directory, the reader will keep reading past the ciphertext into the subsequent ZIP structures (such as the 10-byte tag or the Central Directory headers), appending garbage bytes to the decrypted output before hitting EOF.

To prevent trailing archive metadata from being decrypted as part of the payload, the attacker relocates ("parks") the forged entry at the physical end of the archive, immediately after the End of Central Directory (EOCD) record, inside the variable-length ZIP Archive Comment field. The exploitation sequence operates as follows:

1. Duplicate Entry Metadata to Tail: The attacker takes a genuine encrypted ZIP archive and appends a copy of the target entry's Local File Header, AES salt (e.g., 16 bytes for AES-256), and 2-byte password verification value to the very end of the file (after the 22-byte EOCD record). Because the salt and 2-byte password verifier are copied verbatim, the initial password check in AesReader::validate succeeds when the victim provides the legitimate password.
2. Forge Ciphertext and Omit Tag: Immediately following the 2-byte verifier at the end of the file, the attacker appends the XOR-modified ciphertext $C_{\text{forged}}$. The 10-byte HMAC tag is omitted entirely so that the physical file ends on the exact last byte of $C_{\text{forged}}$.
3. Encapsulate in Archive Comment: To ensure the ZIP parser accepts the trailing bytes during archive initialization (ZipArchive::new), the attacker updates the 2-byte comment length field at offset +20 of the EOCD record to cover the newly appended bytes.
4. Manipulate Central Directory and Local Headers: The attacker modifies the Central Directory header for the target entry, updating relative_offset_of_local_header (offset +42 in the CD record) to point to the parked header inside the archive comment. Both the CD header (offset +20) and the parked Local File Header (offset +18) have their compressed_size fields overwritten with an inflated value (e.g., AES256_OVERHEAD + payload_len + 64).

The regression test committed in tests/aes_encryption.rs demonstrates this exact attack, converting "balance: 100 USD\n" into "balance: 999 USD\n" without knowing the password:

let mut evil = genuine.clone();
let new_hdr_offset = evil.len() as u32;
evil.extend_from_slice(&genuine[..hdr_len + 18]); // local header + 16B salt + 2B verifier
for i in 0..GENUINE.len() {
    // XOR keystream onto chosen plaintext; omit 10-byte HMAC tag
    evil.push(genuine[hdr_len + 18 + i] ^ GENUINE[i] ^ FORGED[i]);
}
let comment_len = (evil.len() - genuine.len()) as u16;
evil[eocd + 20..eocd + 22].copy_from_slice(&comment_len.to_le_bytes());
 
// Repoint central directory to parked entry and inflate compressed_size
let declared = (AES256_OVERHEAD + GENUINE.len() + 64) as u32;
evil[cd_offset + 42..cd_offset + 46].copy_from_slice(&new_hdr_offset.to_le_bytes());
evil[cd_offset + 20..cd_offset + 24].copy_from_slice(&declared.to_le_bytes());
let hdr2 = new_hdr_offset as usize;
evil[hdr2 + 18..hdr2 + 22].copy_from_slice(&declared.to_le_bytes());

When a victim application opens evil and calls read_to_end on the decrypted entry stream, AesReaderValid decrypts the forged bytes, hits physical EOF, receives Ok(0) while data_remaining == 64, skips the HMAC check, and returns the forged plaintext.

The primary impact of CVE-2026-115906 is a complete compromise of data integrity for WinZip AE-x encrypted entries processed by vulnerable versions of the zip crate. It carries a CVSS v3.1 base score of 6.5 (Medium) with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N. The attack vector is Network (AV:N) with Low attack complexity (AC:L) and no privileges required (PR:N), though User Interaction (UI:R) is required in the sense that a victim user or automated service must supply the decryption password to extract the tampered archive.

In the WinZip AE-2 specification—which is the default mode generated by zip-rs and most modern archivers—the standard CRC-32 field in the ZIP header is set to 0 and never verified upon extraction. Furthermore, in the zip crate's implementation (src/read.rs), CryptoReader::Ae applies only to stored or compressed streams wrapped inside ZipFileReader, where AE-1 CRC checks are also bypassed if the stream terminates early or if AE-2 is used. Consequently, there is no secondary checksum layer to catch ciphertext modifications once the HMAC-SHA1-80 check is bypassed.

The concrete security consequences depend on how the consuming Rust application uses decrypted archive data:

• Stored Data Manipulation: If an application ingests password-protected ZIP archives containing structured data (such as financial records, JSON/TOML configuration files, or database backups) and relies on the AES password to guarantee that the file came from a trusted sender who possesses the shared secret, an attacker in transit can alter values (for example, changing account numbers, balances, or permission flags) if they know the structure of the underlying plaintext.
• Truncated Payload Delivery: Even when an attacker does not know the underlying plaintext to perform an exact XOR bit-flipping forgery, they can truncate any AES-encrypted entry (including compressed Deflate streams that have self-contained block boundaries) at an arbitrary byte offset by parking the truncated ciphertext at EOF and inflating compressed_size, without triggering an authentication error.
• Denial of Service via Panic (Secondary): When compressed_size is set below the metadata length (e.g., < 28 bytes for AES-256) in debug builds or environments with overflow checks enabled, the unchecked subtraction in AesReader::new triggers a thread panic.

The vulnerability is fixed in version 9.0.0 of the zip crate via commit ec265db0b0602f8ffb9479327397bddefb7e2216. Development teams using the zip crate should update their Cargo.toml manifest to require version 9.0.0 or higher and regenerate their lockfiles.

[dependencies]
zip = "^9.0.0"

After updating Cargo.toml, apply the upgrade and verify that no transitive dependencies pull in an older version:

cargo update -p zip
cargo tree -i zip

Note that 9.0.0 is a major semver release of the zip crate. If breaking API changes prevent an immediate upgrade to 9.0.0, engineering teams can implement structural pre-validation workarounds in their application code before reading encrypted entries:

1. Validate Entry Offset and Size Against Archive Bounds: Before reading from a decrypted ZipFile, verify that entry.data_start() + entry.compressed_size() does not exceed the starting byte offset of the Central Directory or the total physical length of the archive file. Reject any archive where an entry's header or payload resides past the Central Directory or inside the archive comment.
2. Enforce Exact Byte Read Counts: When reading a stored (CompressionMethod::Stored) AES-encrypted entry, compare the total number of plaintext bytes returned by read_to_end against entry.uncompressed_size(). Furthermore, reject zero-length AES-encrypted entries (entry.uncompressed_size() == 0) if empty authenticated files are security-relevant in your protocol.
3. Use Dedicated Cryptographic Containers: Do not rely on the WinZip AE-x format as a primary cryptographic authentication mechanism for high-value workflows. Sign payloads inside the archive using asymmetric digital signatures (such as Ed25519) or encrypt archives externally using modern authenticated encryption formats (such as age or NaCl/libsodium secretbox) prior to transmission.