CWE-732
Allowed-with-ReviewIncorrect Permission Assignment for Critical Resource
Abstraction: Class · Status: Draft
The product specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors.
2232 vulnerabilities reference this CWE, most recent first.
GHSA-J3R9-59J3-HQ29
Vulnerability from github – Published: 2023-05-20 15:30 – Updated: 2024-04-04 04:15The window management module lacks permission verification.Successful exploitation of this vulnerability may affect confidentiality.
{
"affected": [],
"aliases": [
"CVE-2023-1692"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-05-20T15:15:08Z",
"severity": "HIGH"
},
"details": "The window management module lacks permission verification.Successful exploitation of this vulnerability may affect confidentiality.",
"id": "GHSA-j3r9-59j3-hq29",
"modified": "2024-04-04T04:15:39Z",
"published": "2023-05-20T15:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1692"
},
{
"type": "WEB",
"url": "https://consumer.huawei.com/en/support/bulletin/2023/4"
},
{
"type": "WEB",
"url": "https://device.harmonyos.com/en/docs/security/update/security-bulletins-202304-0000001506528486"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-J3RF-GQ9Q-V8HX
Vulnerability from github – Published: 2022-07-01 00:01 – Updated: 2022-07-13 00:01PingID Windows Login prior to 2.8 does not properly set permissions on the Windows Registry entries used to store sensitive API keys under some circumstances.
{
"affected": [],
"aliases": [
"CVE-2022-23725"
],
"database_specific": {
"cwe_ids": [
"CWE-287",
"CWE-288",
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-06-30T20:15:00Z",
"severity": "MODERATE"
},
"details": "PingID Windows Login prior to 2.8 does not properly set permissions on the Windows Registry entries used to store sensitive API keys under some circumstances.",
"id": "GHSA-j3rf-gq9q-v8hx",
"modified": "2022-07-13T00:01:52Z",
"published": "2022-07-01T00:01:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-23725"
},
{
"type": "WEB",
"url": "https://docs.pingidentity.com/bundle/pingid/page/zhy1653552428545.html"
},
{
"type": "WEB",
"url": "https://www.pingidentity.com/en/resources/downloads/pingid.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-J3XP-WFR4-HX87
Vulnerability from github – Published: 2023-08-03 16:30 – Updated: 2023-08-03 16:30The Rust Security Response WG was notified that Cargo did not respect the umask when extracting crate archives on UNIX-like systems. If the user downloaded a crate containing files writeable by any local user, another local user could exploit this to change the source code compiled and executed by the current user.
This vulnerability has been assigned CVE-2023-38497.
Overview
In UNIX-like systems, each file has three sets of permissions: for the user owning the file, for the group owning the file, and for all other local users. The "umask" is configured on most systems to limit those permissions during file creation, removing dangerous ones. For example, the default umask on macOS and most Linux distributions only allow the user owning a file to write to it, preventing the group owning it or other local users from doing the same.
When a dependency is downloaded by Cargo, its source code has to be extracted on disk to allow the Rust compiler to read as part of the build. To improve performance, this extraction only happens the first time a dependency is used, caching the pre-extracted files for future invocations.
Unfortunately, it was discovered that Cargo did not respect the umask during extraction, and propagated the permissions stored in the crate archive as-is. If an archive contained files writeable by any user on the system (and the system configuration didn't prevent writes through other security measures), another local user on the system could replace or tweak the source code of a dependency, potentially achieving code execution the next time the project is compiled.
Affected Versions
All Rust versions before 1.71.1 on UNIX-like systems (like macOS and Linux) are affected. Note that additional system-dependent security measures configured on the local system might prevent the vulnerability from being exploited.
Users on Windows and other non-UNIX-like systems are not affected.
Mitigations
We recommend all users to update to Rust 1.71.1, which will be released later today, as it fixes the vulnerability by respecting the umask when extracting crate archives. If you build your own toolchain, patches for 1.71.0 source tarballs are available here.
To prevent existing cached extractions from being exploitable, the Cargo binary included in Rust 1.71.1 or later will purge the caches it tries to access if they were generated by older Cargo versions.
If you cannot update to Rust 1.71.1, we recommend configuring your system to prevent other local users from accessing the Cargo directory, usually located in ~/.cargo:
chmod go= ~/.cargo
Acknowledgments
We want to thank Addison Crump for responsibly disclosing this to us according to the Rust security policy.
We also want to thank the members of the Rust project who helped us disclose the vulnerability: Weihang Lo for developing the fix; Eric Huss for reviewing the fix; Pietro Albini for writing this advisory; Pietro Albini, Manish Goregaokar and Josh Stone for coordinating this disclosure; Josh Triplett, Arlo Siemen, Scott Schafer, and Jacob Finkelman for advising during the disclosure.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.72.1"
},
"package": {
"ecosystem": "crates.io",
"name": "cargo"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.72.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2023-38497"
],
"database_specific": {
"cwe_ids": [
"CWE-278",
"CWE-732"
],
"github_reviewed": true,
"github_reviewed_at": "2023-08-03T16:30:52Z",
"nvd_published_at": "2023-08-04T16:15:10Z",
"severity": "HIGH"
},
"details": "The Rust Security Response WG was notified that Cargo did not respect the umask when extracting crate archives on UNIX-like systems. If the user downloaded a crate containing files writeable by any local user, another local user could exploit this to change the source code compiled and executed by the current user.\n\nThis vulnerability has been assigned CVE-2023-38497.\n\n## Overview\n\nIn UNIX-like systems, each file has three sets of permissions: for the user owning the file, for the group owning the file, and for all other local users. The \"[umask][1]\" is configured on most systems to limit those permissions during file creation, removing dangerous ones. For example, the default umask on macOS and most Linux distributions only allow the user owning a file to write to it, preventing the group owning it or other local users from doing the same.\n\nWhen a dependency is downloaded by Cargo, its source code has to be extracted on disk to allow the Rust compiler to read as part of the build. To improve performance, this extraction only happens the first time a dependency is used, caching the pre-extracted files for future invocations.\n\nUnfortunately, it was discovered that Cargo did not respect the umask during extraction, and propagated the permissions stored in the crate archive as-is. If an archive contained files writeable by any user on the system (and the system configuration didn\u0027t prevent writes through other security measures), another local user on the system could replace or tweak the source code of a dependency, potentially achieving code execution the next time the project is compiled.\n\n## Affected Versions\n\nAll Rust versions before 1.71.1 on UNIX-like systems (like macOS and Linux) are affected. Note that additional system-dependent security measures configured on the local system might prevent the vulnerability from being exploited.\n\nUsers on Windows and other non-UNIX-like systems are not affected.\n\n## Mitigations\n\nWe recommend all users to update to Rust 1.71.1, which will be released later today, as it fixes the vulnerability by respecting the umask when extracting crate archives. If you build your own toolchain, patches for 1.71.0 source tarballs are [available here][2].\n\nTo prevent existing cached extractions from being exploitable, the Cargo binary included in Rust 1.71.1 or later will purge the caches it tries to access if they were generated by older Cargo versions.\n\nIf you cannot update to Rust 1.71.1, we recommend configuring your system to prevent other local users from accessing the Cargo directory, usually located in `~/.cargo`:\n\n```\nchmod go= ~/.cargo\n```\n\n## Acknowledgments\n\nWe want to thank Addison Crump for responsibly disclosing this to us according to the [Rust security policy][3].\n\nWe also want to thank the members of the Rust project who helped us disclose the vulnerability: Weihang Lo for developing the fix; Eric Huss for reviewing the fix; Pietro Albini for writing this advisory; Pietro Albini, Manish Goregaokar and Josh Stone for coordinating this disclosure; Josh Triplett, Arlo Siemen, Scott Schafer, and Jacob Finkelman for advising during the disclosure.\n\n[1]: https://en.wikipedia.org/wiki/Umask\n[2]: https://github.com/rust-lang/wg-security-response/tree/main/patches/CVE-2023-38497\n[3]: https://www.rust-lang.org/policies/security",
"id": "GHSA-j3xp-wfr4-hx87",
"modified": "2023-08-03T16:30:52Z",
"published": "2023-08-03T16:30:52Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/rust-lang/cargo/security/advisories/GHSA-j3xp-wfr4-hx87"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38497"
},
{
"type": "WEB",
"url": "https://github.com/rust-lang/cargo/pull/12443"
},
{
"type": "WEB",
"url": "https://github.com/rust-lang/cargo/commit/d78bbf4bde3c6b95caca7512f537c6f9721426ff"
},
{
"type": "WEB",
"url": "https://en.wikipedia.org/wiki/Umask"
},
{
"type": "PACKAGE",
"url": "https://github.com/rust-lang/cargo"
},
{
"type": "WEB",
"url": "https://github.com/rust-lang/wg-security-response/tree/main/patches/CVE-2023-38497"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/QGKE6PGM4HIQUHPJRBQAHMELINSGN4H4"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/QMEXGUGPW5OBSQA6URTBNDSU3RAEFOZ4"
},
{
"type": "WEB",
"url": "https://www.rust-lang.org/policies/security"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Cargo not respecting umask when extracting crate archives"
}
GHSA-J47X-5R4F-5MPX
Vulnerability from github – Published: 2022-05-24 17:18 – Updated: 2022-05-24 17:18An issue was discovered in the "Ultimate Addons for Elementor" plugin before 1.24.2 for WordPress, as exploited in the wild in May 2020 in conjunction with CVE-2020-13126. Unauthenticated attackers can create users with the Subscriber role even if registration is disabled.
{
"affected": [],
"aliases": [
"CVE-2020-13125"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-05-17T01:15:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in the \"Ultimate Addons for Elementor\" plugin before 1.24.2 for WordPress, as exploited in the wild in May 2020 in conjunction with CVE-2020-13126. Unauthenticated attackers can create users with the Subscriber role even if registration is disabled.",
"id": "GHSA-j47x-5r4f-5mpx",
"modified": "2022-05-24T17:18:00Z",
"published": "2022-05-24T17:18:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-13125"
},
{
"type": "WEB",
"url": "https://wpvulndb.com/vulnerabilities/10214"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/blog/2020/05/combined-attack-on-elementor-pro-and-ultimate-addons-for-elementor-puts-1-million-sites-at-risk"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-J4F7-GJ7Q-XG9M
Vulnerability from github – Published: 2025-10-14 00:31 – Updated: 2025-10-15 19:21Liferay Portal 7.3.0 through 7.4.3.119, and Liferay DXP 2023.Q3.1 through 2023.Q3.8, 2023.Q4.0 through 2023.Q4.5, 7.4 GA through update 92 and 7.3 GA though update 36 shows content to users who do not have permission to view it via the Menu Display Widget. This security flaw could result in sensitive information being exposed to unauthorized users.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "com.liferay:com.liferay.site.navigation.menu.item.asset.vocabulary"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.0.23"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-62251"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": true,
"github_reviewed_at": "2025-10-15T19:21:09Z",
"nvd_published_at": "2025-10-13T22:15:32Z",
"severity": "MODERATE"
},
"details": "Liferay Portal 7.3.0 through 7.4.3.119, and Liferay DXP 2023.Q3.1 through 2023.Q3.8, 2023.Q4.0 through 2023.Q4.5, 7.4 GA through update 92 and 7.3 GA though update 36 shows content to users who do not have permission to view it via the Menu Display Widget. This security flaw could result in sensitive information being exposed to unauthorized users.",
"id": "GHSA-j4f7-gj7q-xg9m",
"modified": "2025-10-15T19:21:09Z",
"published": "2025-10-14T00:31:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-62251"
},
{
"type": "WEB",
"url": "https://github.com/liferay/liferay-portal/commit/12bec829da315c21fbc96492ffbdda4c7a2e59cb"
},
{
"type": "PACKAGE",
"url": "https://github.com/liferay/liferay-portal"
},
{
"type": "WEB",
"url": "https://liferay.atlassian.net/browse/LPE-18236"
},
{
"type": "WEB",
"url": "https://liferay.dev/portal/security/known-vulnerabilities/-/asset_publisher/jekt/content/CVE-2025-62251"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:P/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Liferay has Incorrect Permission Assignment for Critical Resource"
}
GHSA-J4HW-WHRX-6W7F
Vulnerability from github – Published: 2022-05-13 01:49 – Updated: 2022-05-13 01:49Incorrect Permission Assignment on the /var/www/xms/cleanzip.sh shell script run periodically in Dialogic PowerMedia XMS through 3.5 allows local users to execute code as the root user.
{
"affected": [],
"aliases": [
"CVE-2018-11642"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-07-03T17:29:00Z",
"severity": "HIGH"
},
"details": "Incorrect Permission Assignment on the /var/www/xms/cleanzip.sh shell script run periodically in Dialogic PowerMedia XMS through 3.5 allows local users to execute code as the root user.",
"id": "GHSA-j4hw-whrx-6w7f",
"modified": "2022-05-13T01:49:18Z",
"published": "2022-05-13T01:49:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-11642"
},
{
"type": "WEB",
"url": "https://d3adend.org/blog/?p=1398"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-J4M3-HC23-H6HF
Vulnerability from github – Published: 2022-05-24 17:21 – Updated: 2022-05-24 17:21An issue was discovered in Mattermost Server before 5.9.0, 5.8.1, 5.7.3, and 4.10.8. It allows a password reset to proceed while an e-mail address is being changed.
{
"affected": [],
"aliases": [
"CVE-2019-20875"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-06-19T17:15:00Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in Mattermost Server before 5.9.0, 5.8.1, 5.7.3, and 4.10.8. It allows a password reset to proceed while an e-mail address is being changed.",
"id": "GHSA-j4m3-hc23-h6hf",
"modified": "2022-05-24T17:21:13Z",
"published": "2022-05-24T17:21:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-20875"
},
{
"type": "WEB",
"url": "https://mattermost.com/security-updates"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-J526-59C3-4QC6
Vulnerability from github – Published: 2025-10-04 03:32 – Updated: 2025-12-22 21:30MacForge contains an insecure XPC service that allows local, unprivileged users to escalate their privileges to root.This issue affects MacForge: 1.2.0 Beta 1.
{
"affected": [],
"aliases": [
"CVE-2025-10751"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-10-04T01:15:29Z",
"severity": "HIGH"
},
"details": "MacForge contains an insecure XPC service that allows local, unprivileged users to escalate their privileges to root.This issue affects MacForge: 1.2.0 Beta 1.",
"id": "GHSA-j526-59c3-4qc6",
"modified": "2025-12-22T21:30:32Z",
"published": "2025-10-04T03:32:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-10751"
},
{
"type": "WEB",
"url": "https://fluidattacks.com/advisories/m83"
},
{
"type": "WEB",
"url": "https://github.com/MacEnhance/MacForge"
},
{
"type": "WEB",
"url": "https://www.macenhance.com/macforge"
}
],
"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:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-J5CH-JJPM-QQ89
Vulnerability from github – Published: 2024-11-23 03:31 – Updated: 2024-11-23 03:31Foxit PDF Reader Update Service Incorrect Permission Assignment Local Privilege Escalation Vulnerability. This vulnerability allows local attackers to escalate privileges on affected installations of Foxit PDF Reader. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability.
The specific flaw exists within the handling of the configuration files used by the Foxit Reader Update Service. The issue results from incorrect permissions set on a resource used by the service. An attacker can leverage this vulnerability to escalate privileges and execute code in the context of SYSTEM. Was ZDI-CAN-23966.
{
"affected": [],
"aliases": [
"CVE-2024-9245"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-11-22T22:15:20Z",
"severity": "HIGH"
},
"details": "Foxit PDF Reader Update Service Incorrect Permission Assignment Local Privilege Escalation Vulnerability. This vulnerability allows local attackers to escalate privileges on affected installations of Foxit PDF Reader. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability.\n\nThe specific flaw exists within the handling of the configuration files used by the Foxit Reader Update Service. The issue results from incorrect permissions set on a resource used by the service. An attacker can leverage this vulnerability to escalate privileges and execute code in the context of SYSTEM. Was ZDI-CAN-23966.",
"id": "GHSA-j5ch-jjpm-qq89",
"modified": "2024-11-23T03:31:59Z",
"published": "2024-11-23T03:31:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-9245"
},
{
"type": "WEB",
"url": "https://www.foxit.com/support/security-bulletins.html"
},
{
"type": "WEB",
"url": "https://www.zerodayinitiative.com/advisories/ZDI-24-1297"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-J5F4-CC29-5X44
Vulnerability from github – Published: 2026-09-29 18:24 – Updated: 2026-09-29 18:24Summary
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;
}
{
"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"
}
Mitigation
When using a critical resource such as a configuration file, check to see if the resource has insecure permissions (such as being modifiable by any regular user) [REF-62], and generate an error or even exit the software if there is a possibility that the resource could have been modified by an unauthorized party.
Mitigation
Divide the software into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully defining distinct user groups, privileges, and/or roles. Map these against data, functionality, and the related resources. Then set the permissions accordingly. This will allow you to maintain more fine-grained control over your resources. [REF-207]
Mitigation MIT-22
Strategy: Sandbox or Jail
- Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.
- OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.
- This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.
- Be careful to avoid CWE-243 and other weaknesses related to jails.
Mitigation
During program startup, explicitly set the default permissions or umask to the most restrictive setting possible. Also set the appropriate permissions during program installation. This will prevent you from inheriting insecure permissions from any user who installs or runs the program.
Mitigation
For all configuration files, executables, and libraries, make sure that they are only readable and writable by the software's administrator.
Mitigation
Do not suggest insecure configuration changes in documentation, especially if those configurations can extend to resources and other programs that are outside the scope of the application.
Mitigation
Do not assume that a system administrator will manually change the configuration to the settings that are recommended in the software's manual.
Mitigation MIT-37
Strategy: Environment Hardening
Ensure that the software runs properly under the United States Government Configuration Baseline (USGCB) [REF-199] or an equivalent hardening configuration guide, which many organizations use to limit the attack surface and potential risk of deployed software.
Mitigation
When storing data in the cloud (e.g., S3 buckets, Azure blobs, Google Cloud Storage, etc.), use the provider's controls to disable public access.
CAPEC-1: Accessing Functionality Not Properly Constrained by ACLs
In applications, particularly web applications, access to functionality is mitigated by an authorization framework. This framework maps Access Control Lists (ACLs) to elements of the application's functionality; particularly URL's for web apps. In the case that the administrator failed to specify an ACL for a particular element, an attacker may be able to access it with impunity. An attacker with the ability to access functionality not properly constrained by ACLs can obtain sensitive information and possibly compromise the entire application. Such an attacker can access resources that must be available only to users at a higher privilege level, can access management sections of the application, or can run queries for data that they otherwise not supposed to.
CAPEC-122: Privilege Abuse
An adversary is able to exploit features of the target that should be reserved for privileged users or administrators but are exposed to use by lower or non-privileged accounts. Access to sensitive information and functionality must be controlled to ensure that only authorized users are able to access these resources.
CAPEC-127: Directory Indexing
An adversary crafts a request to a target that results in the target listing/indexing the content of a directory as output. One common method of triggering directory contents as output is to construct a request containing a path that terminates in a directory name rather than a file name since many applications are configured to provide a list of the directory's contents when such a request is received. An adversary can use this to explore the directory tree on a target as well as learn the names of files. This can often end up revealing test files, backup files, temporary files, hidden files, configuration files, user accounts, script contents, as well as naming conventions, all of which can be used by an attacker to mount additional attacks.
CAPEC-17: Using Malicious Files
An attack of this type exploits a system's configuration that allows an adversary to either directly access an executable file, for example through shell access; or in a possible worst case allows an adversary to upload a file and then execute it. Web servers, ftp servers, and message oriented middleware systems which have many integration points are particularly vulnerable, because both the programmers and the administrators must be in synch regarding the interfaces and the correct privileges for each interface.
CAPEC-180: Exploiting Incorrectly Configured Access Control Security Levels
An attacker exploits a weakness in the configuration of access controls and is able to bypass the intended protection that these measures guard against and thereby obtain unauthorized access to the system or network. Sensitive functionality should always be protected with access controls. However configuring all but the most trivial access control systems can be very complicated and there are many opportunities for mistakes. If an attacker can learn of incorrectly configured access security settings, they may be able to exploit this in an attack.
CAPEC-206: Signing Malicious Code
The adversary extracts credentials used for code signing from a production environment and then uses these credentials to sign malicious content with the developer's key. Many developers use signing keys to sign code or hashes of code. When users or applications verify the signatures are accurate they are led to believe that the code came from the owner of the signing key and that the code has not been modified since the signature was applied. If the adversary has extracted the signing credentials then they can use those credentials to sign their own code bundles. Users or tools that verify the signatures attached to the code will likely assume the code came from the legitimate developer and install or run the code, effectively allowing the adversary to execute arbitrary code on the victim's computer. This differs from CAPEC-673, because the adversary is performing the code signing.
CAPEC-234: Hijacking a privileged process
An adversary gains control of a process that is assigned elevated privileges in order to execute arbitrary code with those privileges. Some processes are assigned elevated privileges on an operating system, usually through association with a particular user, group, or role. If an attacker can hijack this process, they will be able to assume its level of privilege in order to execute their own code.
CAPEC-60: Reusing Session IDs (aka Session Replay)
This attack targets the reuse of valid session ID to spoof the target system in order to gain privileges. The attacker tries to reuse a stolen session ID used previously during a transaction to perform spoofing and session hijacking. Another name for this type of attack is Session Replay.
CAPEC-61: Session Fixation
The attacker induces a client to establish a session with the target software using a session identifier provided by the attacker. Once the user successfully authenticates to the target software, the attacker uses the (now privileged) session identifier in their own transactions. This attack leverages the fact that the target software either relies on client-generated session identifiers or maintains the same session identifiers after privilege elevation.
CAPEC-62: Cross Site Request Forgery
An attacker crafts malicious web links and distributes them (via web pages, email, etc.), typically in a targeted manner, hoping to induce users to click on the link and execute the malicious action against some third-party application. If successful, the action embedded in the malicious link will be processed and accepted by the targeted application with the users' privilege level. This type of attack leverages the persistence and implicit trust placed in user session cookies by many web applications today. In such an architecture, once the user authenticates to an application and a session cookie is created on the user's system, all following transactions for that session are authenticated using that cookie including potential actions initiated by an attacker and simply "riding" the existing session cookie.
CAPEC-642: Replace Binaries
Adversaries know that certain binaries will be regularly executed as part of normal processing. If these binaries are not protected with the appropriate file system permissions, it could be possible to replace them with malware. This malware might be executed at higher system permission levels. A variation of this pattern is to discover self-extracting installation packages that unpack binaries to directories with weak file permissions which it does not clean up appropriately. These binaries can be replaced by malware, which can then be executed.