Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
8 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
A ZIP file can contain two entries with the identical name. adm-zip keeps both in its internal entry list, but its name-lookup table only retains the last one written. getEntry(name) and extractAllTo() walk these two different internal structures, so they can each resolve a duplicate name to a different entry. An application that validates a named entry's contents via getEntry() before trusting an archive, then extracts the whole archive, can end up approving one file's content while a different file's bytes are what actually land on disk under that name. Details - zipFile.js:58-83 retains both entries in entryList but overwrites entryTable[name] with only the last one written. - adm-zip.js:83-95,658-663 uses entryTable for getEntry() lookups — returns the last duplicate. - adm-zip.js:769-914 iterates entryList for extraction — writes the first duplicate (sync, default overwrite policy). PoC Reproduced on the pinned commit (2b4d84087d45344643e0183756e19191d52815cc) Impact An…
Recommended action: Upgrade to 0.6.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
adm-zip enforces a maxOutputLength guard against decompression bombs on its synchronous getData() path, but the equivalent asynchronous getDataAsync() path does not enforce it — it accumulates and returns the entire decompressed output regardless of the entry's declared size. An application that checks an entry's declared size before deciding to process it, then reads the entry via getDataAsync() (a completely ordinary, often-recommended choice for I/O in Node.js), gets none of the protection it believes it has. Details - methods/inflater.js:3-10 passes {maxOutputLength: expectedLength} to inflateRawSync, which Node enforces. - methods/inflater.js:12-31 passes the same option to createInflateRaw but never enforces it on the streaming path — it just accumulates every chunk and allocates a final Buffer of whatever size resulted. PoC Impact An application that validates a declared size before reading an entry, then uses the async API, gets no protection against a high-ratio…
Recommended action: Upgrade to 0.6.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Denial of Service in adm-zip's async decompression API allows an unauthenticated attacker to crash the entire Node.js host process by supplying a single malformed ZIP file. Details Affected package: adm-zip Affected versions: at least 0.6.0 (current latest); likely all versions containing the current inflateAsync implementation in methods/inflater.js Patched version: 0.6.1 Root Cause methods/inflater.js:12-32 (inflateAsync) creates a zlib.createInflateRaw(option) stream and feeds it attacker-controlled compressed bytes via tmp.end(inbuf), but never registers an "error" listener on the stream: Per Node.js EventEmitter/stream semantics, an "error" event emitted with zero listeners is rethrown as an uncaught exception on a later tick, originating from the zlib C++ binding. This cannot be caught by a try/catch wrapped around the calling code, because the throw happens asynchronously, outside the synchronous call stack the try/catch covers. This code path is reached from every…
Recommended action: Upgrade to 0.6.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Affected package: adm-zip (npm) Affected version: 0.6.0 Summary The fix shipped for CVE-2026-39244 (methods/inflater.js) caps zlib's decompression output via maxOutputLength: expectedLength, where expectedLength is read directly from the ZIP entry's attacker-controlled "uncompressed size" header field (CENLEN/LOCLEN). This cap is only applied when expectedLength 0: If an attacker sets the declared uncompressed-size field to exactly 0, this condition is false, option becomes {}, and no output cap is passed to zlib at all. Node then falls back to zlib's own internal default limit (several GB), so a small, highly-compressible payload can still be decompressed to a very large size in memory -- the same class of resource-exhaustion issue the original CVE addressed, just triggered differently. Steps to Reproduce 1. Build a ZIP archive containing one DEFLATE-compressed entry whose real content is highly redundant (e.g. several MB of a repeated byte, achieving close to the ~1032:1…
Recommended action: Upgrade to 0.6.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
adm-zip applies the Unix permission bits stored in a zip entry directly to the extracted file via fs.chmodSync() when keepOriginalPermission=true is passed to extractAllTo()/extractEntryTo() — and it never filters the setuid/setgid/sticky bits out of those bits. A zip crafted by an attacker can therefore produce an extracted binary with mode 04755. When extraction runs as root (the default posture in Docker builds, CI runners, and privileged install steps — the exact environments where this flag is used), the resulting root-owned setuid file is executed later by a lesser-privileged user, turning the attacker's code into a root execution. Details The mode a zip entry wants is read back from the external file attributes in the header, and the mask used keeps every special bit: 0xfff is 0o7777 — it preserves setuid (0o4000), setgid (0o2000) and the sticky bit (0o1000) along with the rwx bits. Shifting by 16 is the standard Unix convention for where zip stores the mode; the mask…
Recommended action: Upgrade to 0.6.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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,…
Recommended action: Upgrade to 0.6.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
adm-zip before 0.5.18 is vulnerable to denial of service via a crafted ZIP file with a manipulated uncompressed size header field. In zipEntry.js line 103, Buffer.alloc(centralHeader.size) allocates memory based on the declared uncompressed size from the ZIP central directory header without validating it against the actual compressed data size or imposing any upper bound. The size value is read directly from the binary header at entryHeader.js line 266 with no bounds check. An attacker can craft a ~120-byte ZIP file that declares ~4GB uncompressed size, causing a memory allocation amplification ratio of over 33 million to 1. The allocation occurs before CRC validation, so the malicious payload cannot be rejected early. All extraction and read methods are affected: readFile(), readAsText(), extractEntryTo(), extractAllTo(), extractAllToAsync(), test(), and entry.getData(). Any application accepting untrusted ZIP files via adm-zip is vulnerable to immediate process crash.
Recommended action: Upgrade to 0.6.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Versions of adm-zip before 0.4.9 are vulnerable to arbitrary file write when used to extract a specifically crafted archive that contains path traversal filenames (../../file.txt for example). Recommendation Update to version 0.4.9 or later.
Recommended action: Upgrade to 0.4.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.