Vulnerabilities

GitPython's GitConfigParser contains a configuration-injection flaw (CWE-88/CWE-94) in its read-then-write round trip: multi-line values parsed from an on-disk config file using git's standard backslash-continuation syntax are decoded into Python strings with embedded newlines, and when the parser later rewrites the file, write_section() serializes them as a bare, unquoted newline-plus-tab continuation that real git parses as separate top-level config lines. The recently added UNSAFE_CONFIG_CHARS_RE safety guard only applies to values passed directly to set()/set_value()/add_value()/add_section(), never to values loaded from disk via _read(), so any unrelated write can turn a dormant value into a live directive such as core.hooksPath = <attacker-controlled path>. An attacker who can plant such a value in a config file that a GitPython-based application later rewrites gains arbitrary code execution, because git will execute the attacker's hook programs with the privileges of the user running GitPython. Developers, CI/CD systems, and pip-packaged tools that embed GitPython and rewrite git config files are affected, with GitPython 3.1.58 at HEAD confirmed vulnerable. No public PoC exists, it is not in CISA KEV, and EPSS assigns only a 0.4% probability of exploitation within 30 days, so no exploitation is currently known.

Do: Monitor GitPython for a patched release beyond 3.1.58/commit 9729ed3b (no fixed version is identified in the available data) and upgrade as soon as one is published. In the interim, avoid letting GitConfigParser rewrite config files that may contain multi-line (backslash-continuation) values, audit managed .git/config and related files for values with embedded newlines or unexpected trailing fragments like hooksPath, and restrict write access to those files to trusted principals.

GitPython before 3.1.58 contains a flaw (CWE-88) in its check_unsafe_options guard, which is meant to block unsafe git options while allow_unsafe_options is set to its default value of False. The guard can be bypassed by combining a single-character keyword argument with split_single_char_options=False, causing GitPython to emit a joined token that git itself parses as an --upload-pack option. An attacker who can influence the kwargs passed to guarded methods such as clone_from can therefore inject --upload-pack and achieve arbitrary OS command execution, despite the library's default safe configuration. Any Python application, service, or pipeline built on the pip-installed GitPython library that passes attacker-controlled or remotely influenced arguments into its git wrapper methods is affected. A public proof-of-concept reference exists via the project's GitHub security advisory (GHSA-wvpp-8hx9-p66j); there is no evidence of in-the-wild exploitation yet, and EPSS puts 30-day exploitation probability at roughly 0.6%.

Do: Upgrade to GitPython 3.1.58 or later via pip as soon as possible. Audit application code paths where user or remote input flows into kwargs of guarded GitPython methods (e.g., clone_from), and avoid combining split_single_char_options=False with single-character keyword arguments until patched. No in-the-wild exploitation is confirmed, but given the public advisory, prioritize updates for internet-facing services that wrap git operations.

GitPython versions before 3.1.54 contain an OS command injection flaw (CWE-78) in which the check_unsafe_options guard intended to block dangerous git options can be bypassed by smuggling git options inside single-character kwarg values. An attacker who can influence the option dictionaries passed to commonly used methods — clone_from, fetch, pull, push, ls_remote, iter_commits, blame, or archive — can inject the --upload-pack parameter to execute arbitrary OS commands on the host. Successful exploitation yields remote code execution with the privileges of the Python process running GitPython (CVSS 4.0: 8.7, high). Any Python application, service, or CI/automation tooling built on affected GitPython versions where attacker-controlled data reaches these git option arguments is affected. No confirmed in-the-wild exploitation yet (not in CISA KEV, EPSS ~0.7%), but a public advisory and proof-of-concept reference exist, so weaponization is straightforward.

Do: Upgrade to GitPython 3.1.54 or later. Interim mitigation: audit all code paths that pass user- or attacker-controlled arguments or option dictionaries into clone_from, fetch, pull, push, ls_remote, iter_commits, blame, or archive, and validate that option values (especially short/single-character kwargs) cannot smuggle extra git options such as --upload-pack. Review web applications and automation that invoke git via GitPython to confirm whether untrusted input reaches these parameters.

GitPython 3.1.50 contains a command-injection flaw (CWE-78) in which the library's default unsafe-option gate fails to recognize joined short-option forms such as -u, the short form of --upload-pack=. The flaw is triggered when an application passes attacker-influenced options into Repo.clone_from(..., multi_options=..., allow_unsafe_options=False): the attacker supplies -u with a value of their choosing, bypassing the gate that is supposed to block --upload-pack/-u. During the clone, Git then executes the helper command named by the -u option, giving the attacker arbitrary command execution on the host running GitPython, in the context of the cloning process. Any application built on GitPython 3.1.50 that forwards untrusted, user-controlled clone options is affected; deployments that do not pass attacker-influenced options are not exposed. There is one public proof-of-concept reference (the project's GitHub security advisory GHSA-v396-v7q4-x2qj); the flaw is not in CISA KEV, EPSS is 0.4%, and no in-the-wild exploitation is currently reported.

Do: Upgrade to GitPython 3.1.51 or later, which recognizes joined short-option forms in the unsafe-option gate. Until patched, do not pass attacker-controlled arguments to Repo.clone_from via multi_options, and audit applications that let users supply clone options (including short options like -u) for this pattern.

GitPython is a python library used to interact with Git repositories. Prior to version 3.1.47, _clone() validates multi_options as the original list, then executes shlex.split(" ".join(multi_options)). A string like "--branch main --config core.hooksPath=/x" passes validation (starts with --branch), but after split becomes ["--branch", "main", "--config", "core.hooksPath=/x"]. Git applies the config and executes attacker hooks during clone. This issue has been patched in version 3.1.47.

GitPython is a python library used to interact with Git repositories. There is an incomplete fix for CVE-2023-40590. On Windows, GitPython uses an untrusted search path if it uses a shell to run `git`, as well as when it runs `bash.exe` to interpret hooks. If either of those features are used on Windows, a malicious `git.exe` or `bash.exe` may be run from an untrusted repository. This issue has been patched in version 3.1.41.

GitPython is a python library used to interact with Git repositories. In order to resolve some git references, GitPython reads files from the `.git` directory, in some places the name of the file being read is provided by the user, GitPython doesn't check if this file is located outside the `.git` directory. This allows an attacker to make GitPython read any file from the system. This vulnerability is present in https://github.com/gitpython-developers/GitPython/blob/1c8310d7cae144f74a671cbe17e51f63a830adbf/git/refs/symbolic.py#L174-L175. That code joins the base directory with a user given string without checking if the final path is located outside the base directory. This vulnerability cannot be used to read the contents of files but could in theory be used to trigger a denial of service for the program. This issue has been addressed in version 3.1.37.

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.

GitPython before 3.1.32 does not block insecure non-multi options in clone and clone_from. NOTE: this issue exists because of an incomplete fix for CVE-2022-24439.

All versions of package gitpython are vulnerable to Remote Code Execution (RCE) due to improper user input validation, which makes it possible to inject a maliciously crafted remote URL into the clone command. Exploiting this vulnerability is possible because the library makes external calls to git without sufficient sanitization of input arguments.