GHSA-wfm5-v35h-vwf4 CVE-2023-40590 PYSEC-2023-161
GitPython untrusted search path on Windows systems leading to arbitrary code execution
- Severity
- 0.0 / 10
- High · CVSS 4.0
- Exploit chance (EPSS)
- 0.51%
- Chance of exploitation in the next 30 days. Higher than 43.44% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-426 Untrusted Search Path
- Fix
3.1.33- Upgrade gitpython to this version or later
Description
Summary
When resolving a program, Python/Windows look for the current working directory, and after that the PATH environment (see big warning in https://docs.python.org/3/library/subprocess.html#popen-constructor). GitPython defaults to use the git command, if a user runs GitPython from a repo has a git.exe or git executable, that program will be run instead of the one in the user's PATH.
Details
This is more of a problem on how Python interacts with Windows systems, Linux and any other OS aren't affected by this. But probably people using GitPython usually run it from the CWD of a repo.
The execution of the git command happens in
And there are other commands executed that should probably be aware of this problem.
PoC
On a Windows system, create a git.exe or git executable in any directory, and import or run GitPython from that directory
python -c "import git"
The git executable from the current directory will be run.
Impact
An attacker can trick a user to download a repository with a malicious git executable, if the user runs/imports GitPython from that directory, it allows the attacker to run any arbitrary commands.
Possible solutions
- Default to an absolute path for the git program on Windows, like
C:\\Program Files\\Git\\cmd\\git.EXE(default git path installation). - Require users to set the
GIT_PYTHON_GIT_EXECUTABLEenvironment variable on Windows systems. - Make this problem prominent in the documentation and advise users to never run GitPython from an untrusted repo, or set the
GIT_PYTHON_GIT_EXECUTABLEenv var to an absolute path. - Resolve the executable manually by only looking into the
PATHenvironment variable (suggested by @Byron)
[!NOTE] This vulnerability was reported via email, and it was decided to publish it here and make it public, so the community is aware of it, and a fix can be provided.
Affected versions
PyPI
| Package | Vulnerable | Fixed in |
|---|---|---|
| gitpython | < 3.1.33 |
3.1.33 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
gitpython PyPI → 3.1.33
- pip
pip install --upgrade "gitpython>=3.1.33"- poetry
poetry add "gitpython>=3.1.33"- uv
uv add "gitpython>=3.1.33"
Severity breakdown
CVSS 4.0 0.0
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
- Attack vector
- Network
- Attack complexity
- Low
- Attack requirements
- None
- Privileges required
- None
- User interaction
- Active
- Confidentiality (vulnerable system)
- High
- Integrity (vulnerable system)
- High
- Availability (vulnerable system)
- High
- Confidentiality (subsequent systems)
- None
- Integrity (subsequent systems)
- None
- Availability (subsequent systems)
- None
CVSS 3.1 7.8
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
- Attack vector
- Local
- Attack complexity
- Low
- Privileges required
- None
- User interaction
- Required
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- High
- Availability
- High
Weakness
CWE-426: Untrusted Search Path
The product searches for critical resources using an externally-supplied search path that can point to resources that are not under the product's direct control.
How to prevent it
- Architecture and Design, Implementation: Hard-code the search path to a set of known-safe values (such as system directories), or only allow them to be specified by the administrator in a configuration file. Do not allow these settings to be modified by an external party. Be careful to avoid related weaknesses such as CWE-426 and CWE-428.
- Implementation: When invoking other programs, specify those programs using fully-qualified pathnames. While this is an effective approach, code that uses fully-qualified pathnames might not be portable to other systems that do not use the same pathnames. The portability can be improved by locating the full-qualified paths in a centralized, easily-modifiable location within the source code, and having the code refer to these paths.
- Implementation: Remove or restrict all environment settings before invoking other programs. This includes the PATH environment variable, LD_LIBRARY_PATH, and other settings that identify the location of code libraries, and any application-specific search paths.
- Implementation: Check your search path before use and remove any elements that are likely to be unsafe, such as the current working directory or a temporary files directory.
- Implementation: Use other functions that require explicit paths. Making use of any of the other readily available functions that require explicit paths is a safe way to avoid this problem. For example, system() in C does not require a full path since the shell can take care of it, while execl() and execv() require a full path.
References
Advisories
Packages
Other links
- github.com/gitpython-developers/GitPython/security/advisories/GHSA-wfm5-v35h-vwf4
- github.com/gitpython-developers/GitPython/issues/1635
- github.com/gitpython-developers/GitPython/pull/1636
- github.com/gitpython-developers/GitPython/commit/8b75434e2c8a082cdeb4971cc6f0ee…
- docs.python.org/3/library/subprocess.html
- github.com/gitpython-developers/GitPython/releases/tag/3.1.33
- github.com/pypa/advisory-database/tree/main/vulns/gitpython/PYSEC-2023-161.yaml
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-83vg-56qc-22m7 GitPython validates a submodule's ".git" path only after cloning into it (RCE) | High | Also affects gitpython |
| GHSA-gq48-pqfc-9p58 GitPython: Submodule.move() follows an attacker-committed intermediate symlink outside the worktree | Medium | Also affects gitpython |
| GHSA-23mf-xhv8-69c2 GitPython: arbitrary file read via attacker-controlled branch name in `Head.checkout()` (incomplete fix of CVE-2026-78679) | High | Also affects gitpython |
| GHSA-f9j4-qggq-h239 GitPython Remote.pull() refspec bypasses the --upload-pack unsafe-option guard, enabling arbitrary command execution | Critical | Also affects gitpython |
| GHSA-w8jc-g24h-crhw GitPython command wrappers omit unsafe protocol and option checks | High | Also affects gitpython |
| GHSA-m64x-33q8-m5h7 GitPython parse_actor_and_date() is vulnerable to quadratic backtracking on malformed identity lines | High | Also affects gitpython |
| GHSA-fx3j-rwgx-fr94 GitPython: separate_git_dir leaks env vars via crafted .gitmodules submodule name | High | Also affects gitpython |
| GHSA-59cr-6r3x-644w GitPython submodule update path traversal can write outside the repository | Medium | Also affects gitpython |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor