pyenv CVE-2026-68939

Exploitation requires three simultaneous local conditions: (1) the attacker must control the content of a .python-version file or the PYENV_VERSION environment variable and be able to insert shell glob metacharacters (*, ?, [, ]) into the version string; (2) a file matching that glob pattern must exist in the current working directory at the time any affected pyenv command runs; (3) pyenv must be running a version earlier than 2.8.0. The attack is limited to local access only (AV:L) - remote unauthenticated exploitation is not possible. Exploitation further requires that a matching installed Python version actually exists under PYENV_ROOT/versions, or the glob expansion resolves to a string that happens to match one. The silent-selection behavior is the hazard; if no installed version matches the expanded string, pyenv will error out visibly rather than silently misbehave.

The CVSS 4.0 score of 2.0 with vector AV:L/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:L accurately represents a low-severity finding. The AT:P (Attack Requirements: Present) metric captures the critical constraint: the attack requires both a .python-version or PYENV_VERSION value containing glob metacharacters AND a matching file to exist in the current working directory - a coincidence unlikely in most environments unless specifically arranged by an attacker. There is no CISA KEV entry and no public exploit code identified at time of analysis. The CIA impact is uniformly Low: an attacker can at most redirect pyenv to select a different already-installed Python interpreter, which could affect build reproducibility or subtly alter which packages are available, but cannot directly execute code or achieve privilege escalation through this vulnerability alone. This is a real correctness and supply-chain hygiene issue for CI/CD pipelines and shared developer environments where untrusted .python-version files might be committed, but it is not a priority remediation for typical production deployments. EPSS data was not provided in the input.

A developer clones a repository that contains a maliciously crafted .python-version file with the value [1-9].?* and a committed file named 1.1 in the project root. When pyenv resolves the Python version for any pyenv command, the shell glob expands [1-9].?* against the working directory, matches the file 1.1, and silently selects Python 1.1 - or whichever installed interpreter corresponds to the expanded string - instead of the intended version. In a CI/CD context where the build environment has multiple Python versions installed and the repository is untrusted, this could redirect the build to use an interpreter with a different set of installed packages.