Skip to main content
CVE-2026-102938VulnerabilityPublished Updated

Pipenv: virtualenv writes prompt values into pyvenv.cfg without sanitizing line boundaries, allowing configuration

Affects pipenvSource GCVE Database

0
Compare
Authoritative record:CVE-2026-102938· Medium 5.8

Not known to be exploited · CVSS 5.8 Medium : upgrade to 2026.8.0_1 when convenient.

Data as of 30 Oct 2026, 07:30 UTC

CVSS 4.0 base score
5.8Medium
How severe the flaw is on the 0–10 CVSS scale.
Patch
Available – fixed in 2026.8.0_1
CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:P/VC:L/VI:H/VA:L/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 pipenv to 2026.8.0_1.

Affected software

ProductAffectedFixed in
Homebrewpipenvpkg:brew/pipenvOther threatsAffected
  • >=2018.11.26_4 <2026.8.0_1
Fixed in
  • 2026.8.0_1

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

Community reviews

Loading reviews…