CVE-2026-22702

What it actually does

This is a local time-of-check-time-of-use race condition in virtualenv before 20.36.1. During app_data and lock-file directory handling, virtualenv checks whether a path exists and later creates or uses it without safely binding the operation to the checked object. A local low-privileged attacker who can manipulate filesystem paths at the right time can replace an expected directory with a symbolic link, causing virtualenv operations to occur in an attacker-chosen location. Successful exploitation can result in limited unauthorized file creation, modification, redirection of lock/app-data behavior, or disruption of virtualenv execution under the privileges of the user or process running virtualenv.

Why it matters to the business

The main risk is local privilege-bound tampering in developer workstations, build systems, CI workers, shared Linux hosts, and packaging environments where untrusted local users or jobs can race filesystem operations. The vulnerability is not remotely exploitable on its own, has high exploitation complexity, is not in the CISA KEV catalog, is not known to be used in ransomware campaigns, and currently has very low EPSS likelihood, so it should generally be treated as a hygiene and hardening update rather than an emergency internet-facing incident. However, because virtualenv is widely used in Python development and build workflows, compromise of shared build infrastructure could undermine package integrity, cause unreliable builds, or allow limited tampering with files owned by the account running virtualenv.

How an attack unfolds

An attacker first needs local access to the same system where vulnerable virtualenv operations will be performed, typically as a low-privileged user or through an untrusted job on a shared build host. The attacker identifies or predicts virtualenv app_data or lock-file paths used by the victim process. They then monitor the target filesystem and repeatedly attempt to win the race between virtualenv's path existence check and the later directory creation or lock operation. At the critical moment, the attacker swaps the checked path for a symbolic link pointing to a location they control or to a sensitive location writable by the victim account. If the race succeeds, virtualenv follows or interacts with the attacker-controlled path, enabling limited file redirection, tampering, or denial of service within the permissions of the virtualenv-running user. Exploitation requires precise timing and local filesystem access, making opportunistic exploitation less likely but feasible in multi-user or multi-tenant build environments.

How to fix it

Upgrade virtualenv to version 20.36.1 or later. For source-based deployments using pypa/virtualenv, ensure the fix including commit d0ad11d1146e81ea74d2461be9653f1da9cf3fd1 is present. For Debian packages listed as affected, update python-pyramid on Debian 13 or Debian 14 to 2.0.2+dfsg-1 or later where applicable. Rebuild containers, CI runner images, developer workstation images, and build toolchains that vendor or pin older virtualenv versions. Where immediate upgrading is not possible, reduce exposure by running builds in isolated single-user workspaces, preventing untrusted users or jobs from sharing writable directories with trusted virtualenv processes, using private temporary/cache directories with restrictive permissions, and clearing any world-writable or shared virtualenv app_data locations.

How to confirm the fix worked

Confirm the installed virtualenv version reports 20.36.1 or later using package manager inventory or `python -m virtualenv --version` where applicable. For Python package environments, inspect pinned requirements, lock files, vendored dependencies, base container images, and CI runner images for virtualenv versions earlier than 20.36.1. For Debian systems, verify the installed python-pyramid package version is 2.0.2+dfsg-1 or later on affected releases. Validate filesystem hardening by confirming virtualenv cache/app-data directories are owned by the invoking user, are not world-writable, and do not contain unexpected symbolic links. In build systems, run a clean virtualenv creation test after upgrade and confirm no errors occur and app_data/lock files are created as normal directories/files rather than symlink targets.

Typical attack path

1. Obtain local low-privileged access to a host where vulnerable virtualenv is installed or where an affected Debian package invokes the vulnerable behavior.
2. Identify predictable virtualenv app_data or lock-file paths used during environment creation or package/build workflows.
3. Prepare attacker-controlled directories and symbolic links that redirect the target path to an attacker-chosen destination.
4. Continuously monitor or race the target path while a victim process invokes virtualenv.
5. Replace the expected directory with a symbolic link between the existence check and the subsequent create/use operation.
6. Cause virtualenv to create, modify, lock, or otherwise interact with files through the symbolic link under the victim process privileges.
7. Use the resulting file redirection for limited tampering, information exposure, or disruption of the virtualenv/build process.

How to detect it

Look for evidence of local filesystem race exploitation rather than network indicators. Relevant sources include Linux auditd or eBPF file telemetry, endpoint detection logs, shell history, CI runner logs, build logs, file integrity monitoring, and package manager inventories. Focus on virtualenv executions followed closely by symlink creation, deletion, or rename activity in virtualenv app-data, cache, temporary, or lock-file paths. Investigate unexpected symbolic links inside virtualenv cache/app_data directories, lock paths that resolve outside the expected user-owned directory tree, world-writable directories used for virtualenv app_data, and build failures involving lock files or unexpected permission errors. In CI or shared hosts, correlate suspicious symlink activity with untrusted jobs, local user sessions, or processes such as `ln`, `mv`, `rm`, shell loops, Python scripts, or inotify-based watchers running concurrently with virtualenv creation. There are no public threat actors or ransomware campaigns associated with this issue in the provided intelligence, and no remote network indicators are expected.

• virtualenv<20.36.1
• python -m virtualenv
• virtualenv --version
• ~/.local/share/virtualenv
• ~/Library/Application Support/virtualenv
• %LOCALAPPDATA%\pypa\virtualenv
• /tmp/virtualenv
• /var/tmp/virtualenv
• .lock
• ln -s
• File exists
• Too many levels of symbolic links
• Permission denied

What your security team should do

• Inventory virtualenv usage across developer endpoints, build servers, CI runners, container base images, and packaging systems; prioritize shared or multi-user systems first.
• Upgrade virtualenv to 20.36.1 or later and update Debian python-pyramid packages to 2.0.2+dfsg-1 or later where applicable.
• Rebuild and redeploy CI/build images that contain pinned or vendored copies of vulnerable virtualenv versions.
• Harden build hosts so untrusted jobs do not share writable cache, temporary, or app_data directories with trusted jobs or privileged build accounts.
• Review virtualenv app_data and lock directories for unexpected symbolic links, unusual ownership, or modifications around build failures or suspicious local activity.
• Treat evidence of successful exploitation as a local compromise of the account running virtualenv and review downstream build outputs for tampering.
• Do not prioritize as an emergency internet-facing exposure unless vulnerable virtualenv is used in a shared environment where attackers can run local code or untrusted jobs.