Skip to main content
VulnerabilityPublished Updated

CVE-2026-102930: virtualenv · Downloaded seed wheels (pip/setuptools) are not integrity-checked before use

Affects toxSource GCVE Database

0
Compare
Authoritative record:CVE-2026-102930· High 7.7

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

Data as of 30 Oct 2026, 07:30 UTC

CVSS 4.0 base score
7.7High
How severe the flaw is on the 0–10 CVSS scale.
Patch
Available – fixed in 4.62.0
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 29 Oct 2026.

What to do

Upgrade tox to 4.62.0.

Affected software

ProductAffectedFixed in
Homebrewtoxpkg:brew/toxOther threatsAffected
  • >=3.14.5_1 <4.62.0
Fixed in
  • 4.62.0

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

Community reviews

Loading reviews…