adm-zip EUVD-2026-83170

Exploitation requires an application that (1) uses adm-zip prior to 0.6.1 and (2) reads entries from attacker-controlled/untrusted ZIP archives, then calls getData() (directly or via extraction). The malicious archive needs only a central-directory entry whose declared uncompressed size is large (POC uses 1,774,399,200 bytes with a 5-byte compressed payload); no authentication, user interaction, or non-default configuration is needed. The limiting factor is not the ZIP itself but the deployment: impact is greatest on memory-constrained hosts (containers, serverless, small VMs) where a single request OOM-kills the process before the uncatchable CRC error, while larger hosts require concurrent requests to exhaust memory. Applications that never parse untrusted ZIPs are not exposed.

This is a genuine but bounded risk. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, base 7.5) accurately characterizes a pure availability impact: no confidentiality or integrity loss, but a clean unauthenticated remote denial-of-service. CWE-789 (uncontrolled memory allocation) matches the root cause - getData() calls Buffer.alloc() on the attacker-declared central-directory uncompressed size before validating it against the compressed size or CRC. A working POC exists (a 105-byte ZIP inlined as base64 in the GHSA advisory, sha256 980d343..., demonstrating ~1.8 GB committed from ~16 million× amplification), so this is 'publicly available exploit code exists', NOT active exploitation - there is no CISA KEV listing and no EPSS score provided, so widespread automated exploitation cannot be asserted. The realistic caveat: exploitation depends on the application actually reading entries from untrusted archives and calling getData(); it is not a network-listening service flaw. Signals are consistent (CVSS DoS, CWE, POC, patch all align) - the only metadata conflict is the 'Information Disclosure' tag, which contradicts the C:N/I:N vector and is a mislabel.

An attacker uploads or submits a tiny (~105-byte) crafted ZIP to any service that parses untrusted archives with adm-zip and calls getEntries()[0].getData() - for example a file-upload endpoint, email attachment scanner, or serverless function. The malformed central directory declares a multi-gigabyte uncompressed size, so getData() commits ~1.8 GB of resident memory in seconds before the CRC check ever runs, OOM-killing the process. A public base64 POC is included in the advisory, and concurrent requests can exhaust memory on even large hosts.