chore(deps): update dependency adm-zip to v0.6.1 [security]

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
adm-zip	0.6.0 → 0.6.1

---

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

---

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

• 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/releases/tag/v0.6.1
• https://github.com/advisories/GHSA-7q85-xj36-vmfc

This data is provided by 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')
"

2. 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)

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:

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

• 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/releases/tag/v0.6.1
• https://github.com/advisories/GHSA-j5f4-cc29-5x44

This data is provided by 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

• 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/releases/tag/v0.6.1
• https://github.com/advisories/GHSA-p634-w6r4-rjp2

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

---

Release Notes

cthackers/adm-zip (adm-zip)

v0.6.1

Compare Source

Full Changelog: cthackers/adm-zip@v0.6.0...v0.6.1

• Updated dev dependencies
• Fixed uncaught crash in async decompression on malformed DEFLATE data
• Fixed addLocalFolder following symlinks out of the archived folder
• Stripped setuid/setgid/sticky bits from extracted file permissions
• Enforced the decompression size cap on the async path and for size 0
• Rejected archives with duplicate entry names
• Blocked extraction from writing through symlinks inside the target
• Routed malformed-header parse errors through the async callback
• Rejected zip entries whose declared data extent runs past the buffer
• Fixed addLocalFolderPromise hanging on empty folders and swallowing errors
• Fixed addLocalFolderAsync2 mangling local paths on Windows

---

Configuration

📅 Schedule: (in timezone Europe/Berlin)

• 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 was generated by Mend Renovate. View the repository job log.