CVE-2023-40590
HighCVSS 7.8Exploitation Probability (EPSS)
Low risk37th percentile - higher than 37% of all known CVEs
Summary
CVE-2023-40590 affects the GitPython library, which can execute a malicious `git` program from a local repository if the user runs GitPython from that directory. This issue primarily occurs on Windows systems where Python improperly resolves paths to executables.
Risk Assessment
An attacker can trick a user into downloading a repository with a malicious `git` file, allowing arbitrary command execution. The lack of current fixes for Windows users increases the risk.
Recommendation
It is recommended to set an absolute path for the `git` program on Windows systems and to inform users to avoid running GitPython from untrusted repositories.
Other vulnerabilities in GitPython
See all- CVE-2026-73624High
GitPython versions before 3.1.54 contain an arbitrary file overwrite vulnerability in the Diffable.diff method that fails to validate git options passed through kwargs. Attackers can supply the --output argument via the other parameter or output kwarg to write patch content to attacker-chosen file paths at process privilege level.
- CVE-2026-73622High
GitPython before 3.1.55 fails to disable environment variable expansion in Remote.create() and Submodule.add() URL handling, allowing attackers to exfiltrate secrets by supplying URLs containing variable references. Attackers can craft URLs with environment variable tokens that are expanded into .git/config and .gitmodules, then transmitted to attacker-controlled hosts during fetch or pull operations.
- CVE-2026-73620High
GitPython before 3.1.57 fails to guard git option forwarding in IndexFile.checkout() and TagReference.create(), allowing attackers to pass unsafe options via kwargs. Attackers can use --prefix to overwrite arbitrary files with repository content or -F to read arbitrary files returned in-band.
- CVE-2026-44244High
GitPython is a Python library used to interact with Git repositories. In versions prior to 3.1.49, the GitConfigParser.set_value() method did not validate values for newlines, allowing for the injection of malicious paths into Git configuration.
- CVE-2026-44243High
GitPython is a Python library used to interact with Git repositories. Prior to version 3.1.48, a vulnerability allowed attackers to manipulate files outside the repository's .git directory due to insufficient validation of reference paths.
- CVE-2026-42284High
GitPython is a Python library used to interact with Git repositories. In versions prior to 3.1.47, the _clone() function improperly validates multi_options, allowing malicious hooks to be executed during repository cloning.
- CVE-2026-42215High
GitPython is a Python library used to interact with Git repositories. From version 3.1.30 to before version 3.1.47, the library blocks dangerous Git options, but equivalent Python kwargs can bypass that check, leading to arbitrary command execution.
- CVE-2026-78676Critical
GitPython before 3.1.59 fails to safely re-serialize multi-line git-config values during write operations, potentially turning dormant quoted values into active directives like core.hooksPath. Attackers can craft config files with embedded newlines that become live after any GitPython config write, enabling arbitrary code execution.
- CVE-2026-67324Critical
GitPython 3.1.50 fails to recognize joined short-option forms such as -u<value> (the short form of --upload-pack=<value>) when enforcing its default unsafe-option gate. When an application passes attacker-influenced clone options into Repo.clone_from(..., multi_options=..., allow_unsafe_options=False), an attacker can supply -u<helper> to bypass the gate that blocks --upload-pack/-u, causing Git to execute the specified helper command during clone. Fixed in 3.1.51.
- CVE-2023-40267Critical
GitPython before 3.1.32 does not block insecure non-multi options in clone and clone_from. This issue exists because of an incomplete fix for CVE-2022-24439.
Original NVD description (English source)
GitPython is a python library used to interact with Git repositories. When resolving a program, Python/Windows look for the current working directory, and after that the PATH environment. 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`. 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. 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. There is no fix currently available for windows users, however there are a few mitigations. 1: Default to an absolute path for the git program on Windows, like `C:\\Program Files\\Git\\cmd\\git.EXE` (default git path installation). 2: Require users to set the `GIT_PYTHON_GIT_EXECUTABLE` environment variable on Windows systems. 3: Make this problem prominent in the documentation and advise users to never run GitPython from an untrusted repo, or set the `GIT_PYTHON_GIT_EXECUTABLE` env var to an absolute path. 4: Resolve the executable manually by only looking into the `PATH` environment variable.