GitPython versions before 3.1.59 contain a critical vulnerability where multi-line git-config values are improperly re-serialized during write operations. This flaw corrupts dormant quoted values into active git directives, such as core.hooksPath, enabling attackers to inject arbitrary commands. Exploitation can lead to arbitrary code execution via hook invocation.
GitPython versions before 3.1.59 contain a vulnerability where the merge_includes feature is not disabled when parsing .gitmodules files. This flaw allows attackers to craft malicious .gitmodules files with include directives that reference arbitrary local file paths. When the repository's submodules are accessed, the GitConfigParser raises an exception that leaks the first line of the targeted file in the error message.
GitPython versions before 3.1.58 contain a path traversal vulnerability due to improper validation of submodule names in .gitmodules files. This flaw allows attackers to create Git repositories at arbitrary filesystem paths outside the intended clone directory by using traversal sequences in submodule names. The vulnerability is rated high severity with a CVSS score of 8.4.
GitPython versions before 3.1.58 contain a config-name injection vulnerability that allows attackers to inject malicious git-config directives by including special characters in option names. This can lead to arbitrary command execution via configuration options like core.sshCommand or core.hooksPath during subsequent git operations.
GitPython versions before 3.1.58 contain a command execution vulnerability due to improper neutralization of argument delimiters in command construction. This flaw allows attackers to bypass the check_unsafe_options guard by combining a single-character keyword argument with split_single_char_options set to false. Exploitation can lead to arbitrary OS command execution when using guarded methods such as clone_from with default allow_unsafe_options set to false.
GitPython versions before 3.1.58 have an arbitrary file overwrite vulnerability due to improper neutralization of argument delimiters in certain methods. This allows attackers to inject the --index-output option into git commands, enabling overwriting of arbitrary files with git-index blobs at writable paths controlled by the attacker.
GitPython versions before 3.1.58 contain a remote code execution vulnerability in the Repo.init function. This flaw arises because unsafe git options are forwarded without validation, allowing attackers to supply a malicious template parameter. The malicious template can point to a directory containing git hooks that execute arbitrary code during git operations on the initialized repository. The vulnerability has a high severity score of 7.7 CVSS 4.0 and requires low privileges but high attack complexity.
GitPython versions before 3.1.58 contain a vulnerability where options passed to git rm and git checkout commands in IndexFile.remove() and Head.checkout() are not properly validated. This allows attackers to supply parameters that can read arbitrary files accessible to the process, with file contents exposed in error messages.
GitPython versions before 3.1.54 contain a remote code execution vulnerability in the check_unsafe_options guard that can be bypassed by smuggling git options inside single-character kwarg values. Attackers can supply crafted option dictionaries to clone_from, fetch, pull, push, ls_remote, iter_commits, blame, or archive methods to execute arbitrary OS commands via the --upload-pack parameter.
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.
GitPython before 3.1.54 contains an incomplete denylist in unsafe_git_clone_options that omits --template, allowing attackers to achieve arbitrary command execution during clone operations. Attackers can supply --template pointing to a directory containing malicious post-checkout hooks that execute when git clones the repository.
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.
GitPython before 3.1.56 contains an argument injection vulnerability in the Commit.count() method, which forwards keyword arguments to 'git rev-list' without the check_unsafe_options guard present in the sibling iter_items method. An attacker who can control options passed to Commit.count (e.g., via an application that forwards a user-supplied options dict) can supply output=<path>, causing 'git rev-list --output=<path>' to open and truncate the target file to zero bytes before revision parsing. This allows destruction/blanking of an arbitrary file at the process's privilege level (no content control, 0-byte truncation).
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.
GitPython before 3.1.57 contains an incomplete denylist in the unsafe_git_archive_options guard that omits --add-file and --add-virtual-file options. Attackers can supply these options to Repo.archive() to read arbitrary files from the filesystem and include them in the returned archive.
GitPython versions up to 3.1.57 contain a vulnerability where the unsafe git option guard can be bypassed by using the split_single_char_options=False flag combined with a single-character keyword argument. This allows an attacker to smuggle a short option token that leads to arbitrary OS command execution via the git --upload-pack option. The vulnerability affects all guarded methods that forward kwargs and occurs despite the default allow_unsafe_options=False setting. A patch is available to fix this issue.
GitPython versions up to 3.1.57 contain a vulnerability in the config option name validation that allows injection of arbitrary git configuration directives. This occurs because the validator does not reject characters such as '=', '#', or whitespace in option names, enabling attackers to forge directives like core.sshCommand or core.hooksPath. Exploitation can lead to remote code execution on subsequent git operations. A patch is available to address this issue.
GitPython versions prior to 3.1.58 contain a vulnerability where an attacker-controlled submodule name in a cloned repository's .gitmodules file can cause GitPython to create and initialize a Git repository outside the intended working directory. This occurs because GitPython does not validate the submodule name, allowing directory traversal sequences that lead to repository creation at arbitrary filesystem paths during submodule initialization.
GitPython versions prior to 3.1.58 contain a vulnerability in the IndexFile.remove() and Head.checkout() methods. These methods forward arbitrary keyword arguments into git rm and git checkout commands without proper validation. When used with the --pathspec-from-file and --pathspec-file-nul options, this allows an attacker to cause Git to treat the entire contents of a chosen file as a pathspec, leading to the file's contents being leaked in error messages. This results in an arbitrary file read vulnerability disclosed through GitCommandError.stderr.
GitPython versions up to 3.1.57 have a vulnerability in the Repo.init() method where unsafe git options are forwarded without validation. Specifically, the --template option can be exploited by an attacker to plant malicious git hooks that execute arbitrary code during subsequent git operations. This occurs because Repo.init() directly passes kwargs to git init without checking for unsafe options, unlike the clone path which has protections. Exploitation requires the attacker to control the template directory and stage executable hooks. A fix is available that adds unsafe option checks to Repo.init().