adm-zip EUVD-2026-42960

The only prerequisite is that the target application passes attacker-supplied ZIP data to any adm-zip read/extract method - readFile(), readAsText(), extractEntryTo(), extractAllTo(), extractAllToAsync(), test(), or entry.getData() - on a version before 0.5.18; no authentication, user interaction, or non-default configuration is required (AV:N/AC:L/PR:N/UI:N). The malicious ZIP simply needs a central-directory uncompressed-size field set far larger than the actual compressed data (e.g., ~4GB declared in a ~120-byte file). What limits exploitation: the application must actually accept and parse untrusted archives - systems that only handle trusted/internal ZIPs, that cap upload size before parsing, or that already run adm-zip 0.5.18+ are not exposed; impact is confined to a process crash (availability only), with no data disclosure or code execution.

The signals are internally consistent for a genuine but bounded-impact issue. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5 High) correctly reflects remote, unauthenticated, low-complexity triggering with availability-only impact - no confidentiality or integrity loss, so this is a crash/DoS rather than RCE. SSVC aligns: exploitation is proof-of-concept, automatable=yes (a script can spray malformed ZIPs), and technical impact is partial (single-process crash, not full system compromise). EPSS is low at 0.43% (35th percentile) and the CVE is not on CISA KEV, indicating no confirmed widespread exploitation. The realistic priority is moderate-to-high for any service that ingests user-supplied archives (file-upload handlers, mail/attachment scanners, CI pipelines) because exploitation is trivial and automatable, but the ceiling is a recoverable crash, not data theft or code execution. No conflicting signals: description, CVSS, and CWE all point to the same availability-only DoS.

An attacker uploads a ~120-byte ZIP file to any endpoint that processes archives with adm-zip - for example a document-import, avatar-unpack, or attachment-scanning feature - with the central-directory header declaring roughly 4GB uncompressed. When the application calls extractAllTo(), readFile(), or getData(), adm-zip issues a Buffer.alloc for the declared size before CRC checks, exhausting memory and crashing the Node.js process; because exploitation is automatable, the attacker scripts repeated requests to keep the service down. Proof-of-concept exploit code exists per the SSVC assessment.