GHSA-7q85-xj36-vmfc: High severity npm/adm-zip vulnerability
Summary adm-zip allocates an entry's output buffer from the declared uncompressed size (central-directory size field) before validating it against the actual data. A tiny crafted ZIP that declares a huge uncompressed size forces a multi-gigabyte allocation from a few bytes.
Impact On adm-zip 0.5.17 (latest), Node 24, a 105-byte ZIP with one stored entry declaring size = 1,774,399,200 makes new AdmZip(buf).getEntries()[0].getData() commit ~1.8 GB of resident memory in ~4.4 s before throwing Error: ADM-ZIP: CRC32 checksum failed, roughly 16 million times the input size. Because the buffer is committed before any validation, on a memory-constrained host (containers, serverless, small VMs) the allocation OOM-kills the process before the CRC check (uncatchable), and concurrent requests can exhaust memory even on larger hosts. Any service that reads entries from untrusted ZIPs is exposed to a remote denial of service.
Steps to reproduce Attachments are not supported in the advisory form, so the 105-byte PoC (sha256 980d34356fbb248fe527b9d0ac3eabc5c99393a374014be6199523de16709386) is inlined as base64 in this self-contained reproducer:
js const AdmZip = require('adm-zip'); // 105-byte crafted ZIP, base64-inlined // sha256 980d34356fbb248fe527b9d0ac3eabc5c99393a374014be6199523de16709386 const b64 = "UEsDBBQAAAAAAAAAAAAAAAAABQAAAAUAAAABAAAAYWhlbGxvUEsBAhQAFAAAAAAAAAAAAAAAAAAFAAAA4C7DaQEAAAAAAAAAAAAAAAAAAAAAAGFQSwUGAAAAAAEAAQAvAAAAJAAAAAAA"; const buf = Buffer.from(b64, "base64"); // 105 bytes const zip = new AdmZip(buf); zip.getEntries()[0].getData(); // commits ~1.8 GB, then throws "ADM-ZIP: CRC32 checksum failed"
The single entry declares uncompressed size = 1,774,399,200 with a compressed size of 5. getData() allocates the full declared size before the CRC check runs, so the memory is committed regardless of the (tiny) actual payload.
Root cause zipEntry.js does Buffer.alloc(<declared uncompressed size>) before checking the declared size against the compressed size / available bytes.
Suggested fix Validate the declared uncompressed size against the compressed size and a configurable maximum before allocating (yauzl, for example, requires the caller to bound this); reject or stream when the declared size is implausible relative to the input. Happy to send a patch.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/adm-zipto a version that resolves this vulnerability.Fixed in 0.6.1
Event History
Frequently Asked Questions
Which deployments are most exposed?
Any service that calls getData() on entries from untrusted ZIP files is exposed to remote denial of service. Memory-constrained containers, serverless environments, and small VMs are especially susceptible to process termination from out-of-memory conditions.
What must an attacker do to trigger the issue?
An attacker needs to provide a crafted ZIP whose central-directory metadata declares a very large uncompressed entry size while containing very little actual data. The vulnerable application must read that entry's data using getData().
What symptoms indicate an attempted or successful attack?
Affected processing can rapidly consume multi-gigabyte resident memory relative to a very small ZIP input, potentially ending in an OOM kill. Where memory is available, processing may instead throw "Error: ADM-ZIP: CRC32 checksum failed" after the allocation has already occurred.