zip2 CVE-2026-115907

Exploitation requires BOTH a specific build configuration and a specific API path: the target application must be compiled with the opt-in legacy-zip Cargo feature (which is what compiles the vulnerable Shrink/Reduce/Implode decoders), and it must call ZipArchive::extract() on (or otherwise read) an attacker-supplied archive. The malicious entry must use a legacy compression method (Shrink/Reduce/Implode) and declare an attacker-controlled ZIP64 uncompressed size - the PoC sets it to u64::MAX while supplying one byte of compressed data - so the oversized Vec::reserve runs before hwunshrink()/hwexpand()/hwexplode() can validate the stream. The decisive limiting factor is that legacy-zip is not enabled by default; applications using zip2's default features are not exposed. No authentication or user interaction is required at the library level once legacy-zip is enabled and untrusted archives are extracted; versions outside 5.1.0-8.x (i.e. 9.0.0 and later) are fixed.

All severity signals here describe a single impact: denial of service. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, base 7.5) correctly reflects a network-reachable, low-complexity, unauthenticated availability-only flaw with no confidentiality or integrity impact - an unhandled Rust panic (capacity overflow) that aborts the process. The GHSA advisory supplies a complete, demonstrated 149-byte reproducer with observed panic output, so trigger reliability is high and deterministic. However, the real-world risk is strongly gated by a configuration prerequisite the raw CVSS score does not capture: the vulnerable legacy Shrink/Reduce/Implode decoders are only compiled when the opt-in legacy-zip Cargo feature is enabled, and the panic is only reached through ZipArchive::extract() (or reading such legacy entries). The vuln.today Decision label is 'this_week' (not act_now/emergency). No EPSS score, no CISA KEV listing, and no SSVC decision values were supplied in the input, so exploitation-probability and active-exploitation signals cannot be weighed - their absence is not evidence either way. Net: this is a genuine, easily-triggered availability bug worth patching on a near-term schedule for any service that extracts untrusted archives with legacy-zip enabled, but it is not a code-execution issue and the opt-in feature gate means most zip2 consumers are not exposed. One notable classification point: NVD assigns CWE-400 while the GHSA assigns CWE-400 plus CWE-789 (memory allocation with excessive size), the latter being the more mechanistically precise fit.

A service that accepts user-uploaded ZIP files and extracts them with zip2 built using the legacy-zip feature receives a crafted 149-byte archive whose ZIP64 extra field declares an uncompressed size of u64::MAX for a Shrink-compressed entry. When the service calls ZipArchive::extract(), the decoder reserves the impossible capacity before validating the compressed stream and the process panics with 'capacity overflow' (exit status 101), terminating the archive-processing service. The GHSA advisory includes a complete working reproducer with observed crash output, so the trigger is confirmed and reliable in optimized release builds.