zip2 EUVD-2026-109983

Requires the application to decrypt entries through the password-bearing APIs by_index_decrypt(), by_name_decrypt(), by_path_decrypt(), or by_index_with_options() with a supplied password; bare extract() calls by_index() without a password and rejects AES entries, so it is not affected. The attacker must be able to modify or supply the archive (e.g. tampering in transit) but needs no password, and must craft the entry so the bounded reader hits the archive's true EOF while the attacker-declared compressed_size leaves data_remaining positive, OR make the entry a zero-payload entry - in both cases src/aes.rs returns before reading/comparing the HMAC-SHA1-80 tag. For AE-2 entries the CRC-32 check is also disabled by design, leaving no integrity check at all. Limiting factors: victim must open the crafted archive with a valid password via those specific APIs (UI:R), and only zip2 versions 0.6.0 through < 9.0.0 are affected; AES-CTR malleability makes the actual byte manipulation straightforward once those conditions hold.

This is a genuine cryptographic authentication-bypass (CWE-354 / CWE-1284), scored CVSS 6.5 (Medium) with vector AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N - integrity-only impact, no confidentiality or availability loss. The signals are mostly consistent: no CISA KEV listing and no EPSS score was provided in the input, so wild-exploitation probability cannot be quantified (this gap is stated rather than assumed to be low), while the vendor's own GHSA advisory ships a working proof-of-concept (three tests reported passing against commit 6f09b30 and release 8.6.0). The vuln.today decision label is 'this_month', i.e. a normal patch-cycle priority rather than emergency/act_now. Real-world risk is raised by PR:N (the attacker needs no password - AES-CTR malleability lets them bit-flip or forge plaintext) and the published PoC, but tempered by UI:R: a victim application must actually decrypt an attacker-supplied/modified archive through the password-bearing APIs (by_index_decrypt, by_name_decrypt, by_path_decrypt, or by_index_with_options with a password). Bare extract() is not affected. Net: a real defect worth remediating this cycle, not a drop-everything RCE. Note a labeling conflict - the input tag 'Information Disclosure' contradicts the CVSS (C:N/I:H) and the mechanism, which is an integrity/authentication bypass, not disclosure.

An attacker who can modify an AES-encrypted ZIP in transit (or supply a crafted one) rewrites an entry so its data ends exactly at the archive's true EOF while the central-directory compressed_size stays larger, or makes the entry zero-payload; because AES-CTR is malleable they XOR chosen bits onto the ciphertext without knowing the password. When a victim application opens the archive with the correct password via by_index_decrypt/by_name_decrypt/by_path_decrypt (or by_index_with_options with a password), the HMAC-SHA1-80 tag is never read or compared, so the forged plaintext is returned as a clean end-of-stream with no authentication error. A full working PoC with three passing tests is published in the GHSA advisory.