Skip to main content
VulnerabilityPublished

CVE-2026-102930: pypa virtualenv · Download of Code Without Integrity Check

Affects pypa virtualenvSource CVE Database V5

0
Compare

Not known to be exploited · CVSS 7.7 High : upgrade to 21.7.12 soon.

Data as of 12 Nov 2026, 23:24 UTC

CVSS 4.0 base score
7.7High
How severe the flaw is on the 0–10 CVSS scale.
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:N

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 29 Sep 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponized: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq 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

ProductAffectedFixed in
pypavirtualenvAffected
  • <21.7.12
Fixed in
  • 21.7.12
PyPIvirtualenvpkg:pypi/virtualenvOther threatsAffected
  • <21.7.12
Fixed in
  • 21.7.12

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

References

Community reviews

Loading reviews…