GHSA-597g-3phw-6986 is a medium-severity (CVSS 4.5) CWE-59 vulnerability in virtualenv. A fix is available for virtualenv — see the affected versions and patch details below.
virtualenv Has TOCTOU Vulnerabilities in Directory Creation
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-597g-3phw-6986.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-597g-3phw-6986 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 377,166 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
virtualenvReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
Impact
TOCTOU (Time-of-Check-Time-of-Use) vulnerabilities in virtualenv allow local attackers to perform symlink-based attacks on directory creation operations. An attacker with local access can exploit a race condition between directory existence checks and creation to redirect virtualenv's app_data and lock file operations to attacker-controlled locations.
Affected versions: All versions up to and including 20.36.1
Affected users: Any user running virtualenv on multi-user systems where untrusted local users have filesystem access to shared temporary directories or where VIRTUALENV_OVERRIDE_APP_DATA points to a user-writable location.
Attack scenarios:
- Cache poisoning: Attacker corrupts wheels or Python metadata in the cache
- Information disclosure: Attacker reads sensitive cached data or metadata
- Lock bypass: Attacker controls lock file semantics to cause concurrent access violations
- Denial of service: Lock starvation preventing virtualenv operations
Patches
The vulnerability has been patched by replacing check-then-act patterns with atomic os.makedirs(..., exist_ok=True) operations.
Fixed in: PR #3013
Versions with the fix: 20.36.2 and later
Users should upgrade to version 20.36.2 or later.
Workarounds
If you cannot upgrade immediately:
- Ensure
VIRTUALENV_OVERRIDE_APP_DATApoints to a directory owned by the current user with restricted permissions (mode 0700) - Avoid running
virtualenvin shared temporary directories where other users have write access - Use separate user accounts for different projects to isolate app_data directories
References
- GitHub PR: https://github.com/pypa/virtualenv/pull/3013
- Vulnerability reported by: @tsigouris007
- CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization (TOCTOU)
- CWE-59: Improper Link Resolution Before File Access
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | virtualenv | all versions | 20.36.1pip install --upgrade 'virtualenv==20.36.1' |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for virtualenv, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update virtualenv to 20.36.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-597g-3phw-6986 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-597g-3phw-6986 can be triaged on real exposure rather than presence alone.
Tailored to GHSA-597g-3phw-6986. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-597g-3phw-6986 in your dependencies?
O3 Security finds GHSA-597g-3phw-6986 across PyPI dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.