CVE-2026-102930: pypa virtualenv · Download of Code Without Integrity Check
Affects pypa virtualenvSource CVE Database V5
Not known to be exploited · CVSS 7.7 High : upgrade to 21.7.12 soon.
Data as of 12 Nov 2026, 23:24 UTC
- EPSS
- 0.1% chance of exploitation in 30 days – higher than 9% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 21.7.12
CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:NExploitation evidence
Disclosed: evidence found.
CVE published 29 Sep 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 13 Nov 2026.
What to do
Upgrade pypa virtualenv to 21.7.12.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| pypavirtualenv | Affected
| Fixed in
|
PyPIvirtualenvpkg:pypi/virtualenvOther threats | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
Upgrade virtualenv to version 21.7.12 or later, where this vulnerability is fixed by implementing integrity checks against authoritative digests for downloaded wheels. Until upgraded, avoid using untrusted or custom package indexes that do not provide integrity verification, and prefer the default PyPI index which enforces these checks. No other specific mitigations are indicated.
Description
`download_wheel()` runs `pip download` and hands the result straight to the seeder, with nothing checking the bytes it gets back. The embedded pip and setuptools wheels carry a `BUNDLE_SHA256` that virtualenv checks on every load, but a wheel fetched over the network for the periodic-update feature or the `--download` flag had no equivalent verification. A compromised index, a stale mirror, or a MITM'd download (when TLS is intercepted, e.g. via a misconfigured or malicious CA) could substitute a different wheel under the same distribution/version/filename, and virtualenv would cache and seed it into every environment created afterward with no warning. Fixed by computing the downloaded wheel's sha256 and comparing it against the digest PyPI's public JSON API reports for that exact release, independent of which index actually served the file. The check is skipped, not treated as failure, when a custom index (`PIP_INDEX_URL`, `PIP_EXTRA_INDEX_URL`, `PIP_INDEX`) is configured, since a private index can legitimately serve a different, intentionally rebuilt wheel. Fix: https://github.com/pypa/virtualenv/pull/3251