CVE-2026-77301: adm-zip: Uncontrolled memory allocation via the declared uncompressed size (DoS)
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.
Other sources
adm-zip is a JavaScript library for creating and extracting ZIP archives in Node.js. Prior to 0.6.1, getData() in zipEntry.js trusts an entry's central-directory uncompressed size and allocates output memory before validating that value against the actual compressed data and decompression result. A small crafted ZIP can declare a multi-gigabyte uncompressed size, causing Buffer.alloc and decompression handling to commit excessive resident memory before CRC validation reports an error. Applications that read entries from untrusted archives can therefore be terminated by the operating system or suffer service-wide memory exhaustion. This issue is fixed in version 0.6.1.
— MITRE
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 - Upgrade
Upgrade
adm-zipto a version that resolves this vulnerability.Fixed in 0.6.1 - Compensating control
When extracting ZIP entries from untrusted sources, bound/validate the declared uncompressed size against the compressed size and/or an explicit configurable maximum before allocating output buffers; reject implausible entries (e.g., require callers to apply size bounds as with yauzl).
Event History
Frequently Asked Questions
Which applications are exposed to this denial-of-service issue?
Applications using adm-zip before 0.6.1 are exposed if they call getData() on entries from ZIP archives that an attacker can supply or influence. A crafted small archive can trigger multi-gigabyte memory allocation and service-wide memory exhaustion.
Does exploitation require authentication or user interaction?
No. The supplied vector indicates network-reachable exploitation with low attack complexity, no privileges, and no user interaction, provided the application processes the crafted archive.
What should teams do if they cannot upgrade immediately?
Avoid calling getData() on untrusted ZIP entries until adm-zip can be updated to 0.6.1. Limit or reject untrusted archive processing where possible, since the allocation occurs before CRC validation detects the malformed entry.
How can an affected deployment be identified?
Check whether the application depends on npm/adm-zip at a version earlier than 0.6.1 and processes ZIP archives from untrusted sources. Errors may occur only after excessive memory has already been committed, so CRC failures do not reliably prevent impact.