CVE-2026-102930: virtualenv · Downloaded seed wheels (pip/setuptools) are not integrity-checked before use
Affects pre-commitSource GCVE Database
Not known to be exploited · CVSS 7.7 High : upgrade to 4.6.2_1 or 2.20.0_1 soon.
Data as of 30 Oct 2026, 05:15 UTC
- Patch
- Available – fixed in 4.6.2_1, 2.20.0_1
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 29 Oct 2026.
What to do
Upgrade pre-commit to 4.6.2_1 or 2.20.0_1.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
Homebrewpre-commitpkg:brew/pre-commitOther threats | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
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
References
- github.com/pypa/virtualenv/security/advisories/GHSA-94p9-xgh2-xp45 (opens in a new tab)
- nvd.nist.gov/vuln/detail/CVE-2026-102930 (opens in a new tab)
- github.com/pypa/virtualenv/pull/3251 (opens in a new tab)
- github.com/pypa/virtualenv/commit/a01ed3e2f239d6ab1fce62c5c7664ccf268fff6d (opens in a new tab)
- github.com/pypa/advisory-database/tree/main/vulns/virtualenv/PYSEC-2026-4011.yaml (opens in a new tab)
- github.com/pypa/virtualenv (opens in a new tab)
- github.com/pypa/virtualenv/releases/tag/21.7.12 (opens in a new tab)
- pypi.org/project/virtualenv (opens in a new tab)