adm-zip CVE-2026-114103

The target application must (1) read ZIP entries using adm-zip's asynchronous getDataAsync() path rather than the synchronous getData() path, and (2) rely on the entry's declared uncompressed size as its decompression-bomb protection - the async path in methods/inflater.js passes maxOutputLength to createInflateRaw but never enforces it, accumulating the entire decompressed stream regardless of declared size. The attacker must be able to supply a ZIP whose entries have falsified small declared uncompressed sizes paired with high-ratio DEFLATE payloads. Limiting factors: applications that use the synchronous getData() path are NOT affected (maxOutputLength is enforced there by Node's inflateRawSync); impact is limited to memory consumption (availability only, no code execution or data exposure); and meaningful denial of service typically requires repeated or large crafted submissions. Affected versions are adm-zip <= 0.6.0, fixed in 0.6.1.

This is a genuine but bounded availability issue, not a top-tier priority. The input CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) describes a remotely reachable, low-complexity, unauthenticated trigger, but the ONLY impact metric set is VA:L - low availability impact, with no confidentiality or integrity impact (VC:N/VI:N) and no subsequent-system effect. This aligns with CWE-400 (uncontrolled resource consumption) and the Denial Of Service tag. A working PoC is published in the GHSA advisory, so publicly available exploit code exists; however, there is NO CISA KEV listing and NO EPSS score was provided in the input, so there is no signal of active or widespread exploitation - this should be read as a disclosed, POC-backed DoS weakness rather than an actively exploited threat. A key conditional limits real-world risk: exploitation only matters for applications that both (a) read ZIP entries via the asynchronous getDataAsync() path and (b) rely on the declared uncompressed size as their bomb protection; applications using synchronous getData() are already protected. The CVSS AC:L/PR:N signals suggest easy exploitation, but the practical precondition (specific API usage pattern) is an application-level dependency the CVSS vector cannot capture - verify your own code path before prioritizing. Overall: a medium-severity, patch-now-on-next-cycle issue for affected consumers, not an emergency.

An attacker uploads or supplies a crafted ZIP file to a Node.js service that uses adm-zip and reads entries via getDataAsync() after trusting the entry's declared uncompressed size. The ZIP contains an entry with a falsified tiny declared size (e.g. 1 byte) but a high-ratio DEFLATE payload that decompresses to tens of megabytes, which the async path accumulates fully into memory, bypassing the maxOutputLength guard. A working proof-of-concept demonstrating the 64 MiB-from-1-byte bypass is published in the GHSA advisory, and repeated or larger submissions can drive memory exhaustion.