TOCTOU in virtualenv CVE-2026-22702 fixed in v20.36.1

A newly disclosed vulnerability in the widely used Python tool virtualenv exposes a classic Time-of-Check–Time-of-Use (TOCTOU) race condition that can be abused by local attackers to perform symlink-based redirection of directory creation and lock-file operations. The issue — tracked as CVE-2026-22702 and patched in virtualenv v20.36.1 — allows an attacker with local filesystem access to influence where virtualenv writes its app data and lock files, with potential consequences ranging from cache poisoning and data exposure to denial-of-service in shared environments. This article explains exactly what went wrong, who is at risk, how the patch fixes the problem, and practical mitigation steps for developers, system administrators, and CI/DevOps engineers.

Background​

virtualenv is one of the most widely used tools in the Python ecosystem for creating isolated environment sandboxes. It frequently runs on developer workstations, build servers, CI runners, multi-user shells, and containers. Because virtualenv creates directories for storing caches, metadata, and lockfiles, it routinely interacts with filesystem locations that may be shared or user-writable.
A TOCTOU bug arises when a program checks some condition (time-of-check) and then acts on the result later (time-of-use) without an atomic guarantee that the condition still holds. If an attacker can change the filesystem state in the gap between check and use — for example by creating a symlink where a directory will be created — the program may end up operating on an attacker-controlled path.
In this case, virtualenv performed an existence check on certain directories, then attempted to create or use those directories, allowing an attacker to win the race and redirect the operation to a symlink target. The project fixed the issue in v20.36.1; the patch is described in the virtualenv changelog as “Fix TOCTOU vulnerabilities in app_data and lock directory creation that could be exploited via symlink attacks.”

---

What the vulnerability is (technical overview)​

The failure mode: a classic check-then-act race​

The vulnerable code sequence followed the familiar pattern:

• Check whether a target path exists or is a directory.
• If the check indicates the path is absent, create a directory at that path.
• Later, create or acquire a lock file under that directory.

If an attacker can create a symbolic link at the target path between step 1 and step 2, subsequent directory creation or lock-file operations will follow the symlink and operate on the link’s target. Because the link can point to any writable filesystem location the attacker controls (or, in some contexts, to privileged system paths), the outcome can be data corruption, cache poisoning, denial of service, or information disclosure.

Why this was exploitable in virtualenv​

• virtualenv creates app_data directories and lock directories that can, in some configurations, be placed under user-writable paths (for example, shared temporary directories).
• When an environment variable like VIRTUALENV_OVERRIDE_APP_DATA is set to an attacker-writable location, that widens the attack surface.
• The operations are performed without atomic creation semantics or robust checks against symlinks, leaving a brief window for a symlink to be introduced.

Conditions for exploitation​

• The attacker needs local access to the filesystem where virtualenv runs (either on the same host or via a compromised local user account on a multi-user system).
• The attacker must be able to create symlinks in the directory where virtualenv expects to create app_data or locks (for example, a world-writable /tmp-like directory).
• The attacker must win the race — create the symlink in the small time window between the check and the create operation. While not trivial, race conditions of this nature are reliably exploitable by a determined attacker using automated loops.

Because these requirements demand local access and a race, this vulnerability is not a remote code execution vector that can be trivially triggered over the network without local privileges. That said, in many shared development and CI environments, local access is effectively granted to multiple untrusted users or processes — making the risk real in those contexts.

---

Affected versions and scope​

• Affected: virtualenv versions prior to and excluding 20.36.1.
• Fixed: virtualenv v20.36.1 (release includes a specific bugfix: “Fix TOCTOU vulnerabilities in app_data and lock directory creation”).
• Impacted deployments:
• Multi-user UNIX-like systems with shared temporary directories (e.g., shared /tmp, shared build workspaces).
• CI/CD runners or containers where multiple jobs or untrusted users can write to the same filesystem paths.
• Any environment where VIRTUALENV_OVERRIDE_APP_DATA points at a directory writable by untrusted users.
• Workstations where multiple local accounts share a common filesystem location used by virtualenv.

Environments where virtualenv writes to per-user, non-shared directories with proper permissions and no symlink-creation privilege for untrusted users present far lower practical risk.

---

Attack scenarios and real-world impact​

Attackers could realistically exploit CVE-2026-22702 in several ways. Below are concrete scenarios and the potential consequences.

1. Cache poisoning and supply-chain manipulation​

• virtualenv writes wheels and package metadata into caches under app_data. If an attacker can redirect those writes to a location they control, they can insert or corrupt cached packages.
• Impact: build artifacts or developer environments may later consume corrupted packages, leading to subtle failures, backdoored installs, or the inclusion of malicious code in otherwise trusted builds.

2. Lock manipulation to cause denial-of-service (DoS)​

• virtualenv uses lock files to coordinate concurrent operations. By redirecting or controlling the lock location, an attacker can cause locks to be acquired or starved, breaking parallel environment creation on a build host.
• Impact: Slowdowns, aborted builds, and flakey CI behavior.

3. Information disclosure​

• If the redirected path points to an attacker-controlled directory that can later be read by local processes, sensitive virtualenv metadata or cached information could be exposed.
• Impact: Leakage of package names, versions, or local path metadata that may help further attacks.

4. Arbitrary file corruption or overwrite​

• Symlink redirection could cause virtualenv to write into paths the attacker chooses (subject to filesystem permissions), potentially corrupting important files if the attacker points the symlink at a privileged target they can influence.
• Impact: Data corruption, release process sabotage, or targeted destruction of files used by other processes.

Caveats on exploitation​

• Remote exploitation without local privileges is not feasible. The threat requires local write/symlink capability and a race win.
• On Windows, symlink creation typically requires elevated privileges or Developer Mode; this reduces risk on default Windows installs but not in developer-enabled environments or where symlink creation is permitted.
• The attack complexity is non-trivial; however, it is well within the capabilities of determined attackers with local access and automation.

---

How the upstream patch fixes the problem​

The virtualenv project addressed the issue in v20.36.1. The changelog entry states the commit repaired TOCTOU vulnerabilities in app_data and lock directory creation. In practice, fixes for this class of bug typically adopt one or more of the following safe patterns:

• Use atomic operations where possible (e.g., use OS primitives that can create directories atomically or fail when a symlink is present).
• Avoid separate “exists-then-create” sequences; instead, attempt the create-with-fail-if-exists pattern (e.g., mkdir with O_EXCL-like semantics, or use rename-on-success techniques).
• Explicitly detect symlinks and refuse to follow them when creating directories, or validate the final target after creation.
• Acquire an unambiguous lock over the parent directory before creation to prevent races.

virtualenv’s patch authors indicated they fixed the app_data and lock directory creation paths to prevent symlink attacks; those code paths are now hardened against a symlink being inserted during directory creation. The changelog also credits the reporter and the developer who implemented the fix, reflecting responsible disclosure and a prompt upstream response.

---

Detection and forensics: how to tell if you were targeted​

Because exploitation involves local filesystem operations, detection requires focusing on local logs and cache integrity checks. Practical steps for detection include:

• Audit file ownership, permissions, and inode types for your virtualenv app_data and lock directories. Look for unexpected symbolic links where directories should be.
• Check modification timelines and creation timestamps for cache files and lock files. Rapid creation/deletion patterns in shared directories may indicate automated race attempts.
• Verify package checksums in caches against known-good digests. Unexpected checksum mismatches in wheels or metadata should be investigated.
• Review CI logs for spurious virtualenv failures, lock acquisition timeouts, or unusual cache behavior that correlates with job timing.
• On systems with audit logging (e.g., Linux auditd), search for frequent symlink creation in shared directories coinciding with virtualenv runs.

If you suspect compromise and have evidence of redirected writes, preserve filesystem snapshots and capture inodes for post-incident analysis.

---

Mitigation and remediation guidance​

The single most effective remediation is to upgrade virtualenv to v20.36.1 or later across every environment where it is used. Beyond that, adopt layered mitigations to reduce the chance of exploitation.

Immediate steps (urgent)​

• Upgrade virtualenv:
• pip install --upgrade virtualenv
• If you manage virtualenv via OS packages, apply vendor or distro-provided updates as they are released.
• If immediate upgrade is impossible, set VIRTUALENV_OVERRIDE_APP_DATA to a directory that is:
• Owned by the current user,
• Not world-writable, and
• Not shared between untrusted users.
  This reduces the attack surface by ensuring app data is written to a safe location.

System-level hardening​

• Avoid sharing world-writable directories (like /tmp) across untrusted users, or ensure sticky bits are set appropriately to prevent symlink races from unprivileged users.
• Enforce least privilege: prevent untrusted users from creating symlinks into directories used by build agents or development tools.
• Use filesystem namespaces or containerization to isolate build jobs. For CI runners, ensure each job runs in an exclusive workspace that other untrusted jobs cannot access.
• Restrict symlink creation on Windows where feasible, or avoid running virtualenv in contexts that grant broad symlink privileges.

CI/CD recommendations​

• Ensure runners do not share caches or lock directories between different tenants/jobs unless isolation is guaranteed.
• Use per-job caches or signed caches with verification to reduce the impact of cache poisoning.
• Consider running virtualenv inside ephemeral containers or sandboxed VMs where local users cannot influence the host filesystem.

For packagers and distro maintainers​

• Backport the upstream fix to packaged virtualenv builds and publish advisories to users.
• Where virtualenv is embedded within language images (e.g., container base images), rebuild images to include the patched version and communicate updates to downstream consumers.

---

Practical checklist for administrators and developers​

• Check your virtualenv version (run virtualenv --version) across:
• Developer workstations
• CI runners
• Build servers
• Container base images and language images
• If version < 20.36.1, plan and execute an upgrade window.
• Audit environment variables: search for VIRTUALENV_OVERRIDE_APP_DATA usage and ensure its target is secure.
• Ensure file permissions for app data and lock directories are not world-writable and are not shared across untrusted accounts.
• For critical pipelines, add integrity checks on cached wheels and package metadata.

---

Why TOCTOU keeps appearing — the bigger picture​

TOCTOU vulnerabilities are a recurring class of bugs because many APIs are not atomic and programmers naturally write check-then-act code. As systems grow more concurrent and shared, these races become exploitable in new environments (shared CI runners, container hosts with many tenants, multi-user workstations). This vulnerability is conceptually similar to other recent symlink-based TOCTOU issues in Python ecosystem libraries that handle locks or caches; those incidents underline a systemic challenge:

• Libraries must assume attackers can manipulate shared writable paths.
• APIs that create files or directories must use atomic patterns or harden against symlinks and other filesystem redirections.
• Packaging and build systems should avoid global shared caches without integrity verification.

Developers of foundational tooling like virtualenv now must bake in anti-race design patterns because the downstream impact is wide: compromised caches or lock manipulation can affect supply chain integrity, CI reliability, and developer productivity.

---

Risk assessment and prioritization​

• Risk level: Medium overall for most organizations; Higher for tenants using shared or multi-tenant infrastructure where untrusted local users can write to the same filesystem.
• CVE severity: The vulnerability received a medium score in public trackers, reflecting local-only access and the need to win a race.
• Exploitability: Not trivial, but practical. Attack complexity is increased by the race requirement, yet automation can make the race reliable in many environments.
• Business impact: Depends on the environment. For public services that use shared build hosts, the impact could escalate to supply-chain contamination or build failures; in single-user locked-down workstations, practical impact is minimal.

Prioritize remediation for:

• Shared CI/CD infrastructure
• Multi-user development or build hosts
• Container images used widely in pipelines
• Vendor or distro packaging layers that distribute older virtualenv versions

Lower priority: isolated single-user machines with no untrusted local accounts and proper directory permissions.

---

Final recommendations​

• Upgrade every virtualenv instance to v20.36.1 or later as the first and highest-priority action.
• Harden shared filesystem usage by isolating caches and lock directories per-user or per-job.
• For environments that cannot immediately upgrade, set VIRTUALENV_OVERRIDE_APP_DATA to a secure per-user directory and avoid shared world-writable paths.
• Add integrity verification to caches — e.g., check wheel hashes before use — to reduce damage from potential cache poisoning.
• For CI administrators: enforce ephemeral, isolated workspaces, and do not reuse a shared virtualenv app_data across untrusted jobs.
• Monitor for anomalous symlink creation in directories used by build tools; add audit rules if possible.

---

Conclusion​

CVE-2026-22702 is a reminder that even mature, ubiquitous tools like virtualenv remain susceptible to well-known classes of filesystem races. The practical attack requires local access and a successful race, but in shared development and CI environments those prerequisites are often present. The fix in virtualenv v20.36.1 addresses the root check-then-act behavior for app_data and lock directory creation; the fastest path to safety is to upgrade. Beyond the immediate patch, organizations should treat shared build environments and caches as high-risk and apply isolation, permissions hardening, and cache verification to reduce their attack surface against TOCTOU-style manipulations.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center