Tox: virtualenv writes prompt values into pyvenv.cfg without sanitizing line boundaries, allowing configuration
Affects toxSource GCVE Database
Not known to be exploited · CVSS 5.8 Medium : upgrade to 4.62.0 when convenient.
Data as of 30 Oct 2026, 07:30 UTC
- Patch
- Available – fixed in 4.62.0
CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:P/VC:L/VI:H/VA:L/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 tox to 4.62.0.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
Homebrewtoxpkg:brew/toxOther 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
### Summary `pyvenv.cfg` is a line-based format with no escape syntax. `PyEnvCfg.write()` wrote values verbatim, while `PyEnvCfg._read_values()` parses the file with `str.splitlines()`. A value containing a line boundary therefore became additional configuration lines, and because reading is last-wins, the injected keys replaced any key written earlier in the file. ### Impact The `prompt` value is the reachable input: it is set by `--prompt`, by the `VIRTUALENV_PROMPT` environment variable, or from the config file, and `write()` emits `prompt` before `home`. A crafted prompt can therefore set `home` in the generated `pyvenv.cfg`: ```console $ virtualenv --prompt $'x"\nhome = /attacker/path\nprompt = "z' venv $ grep '^home' venv/pyvenv.cfg home = /attacker/path ``` `home` is what tooling reads to locate the base interpreter, so a consumer that trusts it can be pointed elsewhere. `implementation`, `version_info`, `version`, `executable`, `command` and `virtualenv` are also written before `prompt` and can be replaced the same way. This requires the prompt to come from somewhere other than the person running the command, for example a CI job templating a branch name into it, tooling deriving an environment name from user-supplied data, or an inherited `VIRTUALENV_PROMPT`. Where the operator supplies the prompt directly they already control the command line, and the effect is corruption rather than privilege gain: the value is truncated at the boundary and read back with a dangling quote. ### Details The boundary set is the one `str.splitlines()` recognizes, which is wider than `\n`: `\r`, `\v`, `\f`, the file, group and record separators, `U+0085`, `U+2028` and `U+2029` were all written through unchanged and all split the line when read back. ### Patches `PyEnvCfg.write()` now collapses those boundaries to spaces as it serializes each line, so it cannot emit a structurally invalid file regardless of what a caller places in `content`. ### Workarounds Do not pass externally influenced data as the virtualenv prompt. Strip line boundaries from any value before using it as `--prompt` or `VIRTUALENV_PROMPT`.
References
- github.com/pypa/virtualenv/security/advisories/GHSA-9h9j-4vrj-gf7g (opens in a new tab)
- nvd.nist.gov/vuln/detail/CVE-2026-102938 (opens in a new tab)
- github.com/pypa/virtualenv/pull/3247 (opens in a new tab)
- github.com/pypa/virtualenv/commit/a30f995461043acb6cacbf3a890951563ccf7140 (opens in a new tab)
- github.com/pypa/advisory-database/tree/main/vulns/virtualenv/PYSEC-2026-4012.yaml (opens in a new tab)
- github.com/pypa/virtualenv (opens in a new tab)
- github.com/pypa/virtualenv/releases/tag/21.7.11 (opens in a new tab)
- pypi.org/project/virtualenv (opens in a new tab)