GitPython versions from 3.4.1 up to but not including 3.27.0 have a vulnerability where the clone_from() and clone() methods do not block the --separate-git-dir option by default. This omission allows an attacker to specify an arbitrary filesystem path for the Git metadata directory during a clone operation, potentially creating files and directories outside the intended clone destination. The vulnerability arises because the denylist for unsafe clone options is incomplete and does not include --separate-git-dir, despite documentation stating it should be blocked unless explicitly allowed.
GitPython's Repo.blame() and Repo.blame_incremental() methods have an incomplete denylist for unsafe git revision options, omitting the --contents and -S options. This omission allows an attacker to cause arbitrary local file reads by passing these options, which echo file contents into the blame result. The vulnerability affects GitPython versions up to 3.1.58. A patch is available to address this issue by expanding the denylist to include these options.
GitPython versions up to 3.1.57 contain a vulnerability where the unsafe git option guard can be bypassed by using the parameter split_single_char_options=False combined with a single-character keyword argument. This bypass allows arbitrary OS command execution via the git --upload-pack option, despite the default allow_unsafe_options=False setting. The flaw stems from incomplete filtering of joined short-option tokens, enabling command injection in methods like clone, fetch, pull, and push. A fix is available in version 3.25.0.
CVE-2026-76217 is a vulnerability in GitPython versions from 3.4.1 up to but not including 3.25.0. It allows an attacker with limited privileges to read arbitrary files on the system by exploiting how `IndexFile.remove()` and `Head.checkout()` forward unsafe options to underlying git commands. Specifically, using the `--pathspec-from-file` option together with `--pathspec-file-nul` causes git to treat the entire file as a single pathspec, and when the pathspec does not match, the error message includes the full contents of the file. This disclosure of file contents is returned in the error output, enabling arbitrary file read. A fix is available in version 3.25.0.
GitPython's Repo.init method forwards keyword arguments directly to git init without guarding unsafe options like --template. This allows an attacker who can control the template argument and stage a malicious hooks directory to plant executable hooks in the new repository. These hooks execute on the next git operation, resulting in arbitrary code execution at the host process privilege level. The vulnerability affects GitPython versions up to 3.1.57 and was fixed in version 3.25.0.
GitPython versions prior to 3.25.0 contain a vulnerability in the IndexFile.from_tree, reset, and merge_tree methods where unguarded forwarding of positional treeish arguments to git read-tree allows an attacker to overwrite arbitrary files with a valid git-index blob. This occurs because the methods do not check or block unsafe options such as --index-output, enabling an attacker to specify an arbitrary output path. The vulnerability allows arbitrary file overwrite with the privileges of the host process, potentially corrupting or destroying important files.
GitPython versions up to 3.1.57 contain a vulnerability in the config-name validator that fails to properly sanitize option names. This allows injection of arbitrary git configuration directives, such as core.sshCommand, enabling remote code execution on subsequent git operations. The issue arises because the validator only restricts certain characters for section names, not option names, allowing characters like '=', '#', and whitespace to bypass validation. A fix is available in version 3.25.0.
GitPython versions >=3.4.1 and <3.25.0 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 escape the working tree. The vulnerability is fixed in version 3.25.0.
GitPython versions up to 3.1.53 contain a vulnerability in the check_unsafe_options guard that can be bypassed by smuggling an option token inside the value of a single-character keyword argument. This bypass allows arbitrary OS command execution via the --upload-pack git option in all guarded methods such as clone, fetch, pull, and others. The vulnerability arises because the guard only inspects keyword argument keys, not values, allowing malicious tokens in values to be executed by git. A fix is available in version 3.24.0.
GitPython's Repo.archive() method uses a denylist to block unsafe git archive options, but this denylist is incomplete. Specifically, the options --add-file and --add-virtual-file, which allow reading arbitrary files from the filesystem and injecting attacker-controlled content into archives, are not blocked. This omission enables an attacker who can influence Repo.archive() options to read arbitrary files with the privileges of the running process. The vulnerability does not allow code execution but exposes sensitive file contents. A fix is available in GitPython version 3.24.0.
GitPython contains unguarded forwarding of git command options in the methods IndexFile.checkout() and TagReference.create(), allowing arbitrary file overwrite and arbitrary file read respectively. The checkout() method forwards unsafe options to git checkout-index, enabling an attacker to overwrite files anywhere on the filesystem with repository-controlled content via the --prefix option. The TagReference.create() method forwards unsafe options to git tag, allowing an attacker to read arbitrary files on the filesystem via the -F/--file option. Both issues are present in versions from 3.4.1 up to but not including 3.24.0 and have been fixed in version 3.24.0. The CVSS score is 8.1 (high severity).
GitPython's Commit.count() method improperly forwards unguarded keyword arguments to git rev-list, allowing an attacker to specify the --output option. This causes git rev-list to truncate an arbitrary file to zero bytes, resulting in file destruction. The vulnerability affects versions up to 3.1.53 and was fixed in version 3.24.0. The impact is medium severity due to the ability to destroy files but limited control over content and requiring process-level privileges.
GitPython versions prior to 3.24.0 contain a vulnerability where environment variables in URLs passed to Repo.create_remote() or Remote.add() are expanded and embedded into the repository configuration. This can lead to sensitive environment variables being written into .git/config or .gitmodules and subsequently transmitted to an attacker-controlled server during fetch or pull operations.
GitPython versions up to 3.1.53 have an incomplete denylist for unsafe git clone options that omits the --template option. This omission allows an attacker who can influence clone options and stage a malicious post-checkout hook in a directory to achieve arbitrary OS command execution during a git clone operation. The vulnerability requires the attacker to have write access to a directory containing executable hooks, which git copies and executes during the clone process. A fix is available in version 3.24.0.
GitPython version 3.1.50 contains a vulnerability where the default unsafe option gate intended to block dangerous git clone options does not recognize joined short-option forms like '-u<helper>'. This allows an attacker controlling clone options to bypass the safety check and execute local commands via Git's upload-pack option. The issue arises because the option canonicalization treats '-u<value>' as a different option name, failing to block it. The vulnerability affects the snowflake-cli package versions >=3.18.0 and <3.24.0, with a fix available in version 3.24.0.
A path traversal vulnerability in GitPython used by snowflake-cli allows attackers who can supply crafted reference paths to write, overwrite, move, or delete files outside the repository's .git directory. This occurs due to insufficient validation of reference paths during write, rename, and delete operations. The vulnerability affects snowflake-cli versions from 3.4.1 up to but not including 3.18.0. A fix is available in version 3.18.0.
GitPython versions from 3.4.1 up to but not including 3.24.0 contain command injection vulnerabilities via unguarded Git options in methods such as Repo.archive(), git.ls_remote(), and arbitrary file operations in Repo.iter_commits and Repo.blame. These flaws allow an attacker to execute arbitrary commands or cause file truncation by injecting malicious options. The issue arises because certain Git command options are not properly checked or sanitized outside of fetch, pull, push, and clone_from operations. A fix is available in version 3.24.0.
Kimi CLI's GitPython integration contains a vulnerability (CVE-2026-67326) where newline injection in the config_writer() section parameter bypasses prior patch CVE-2026-42215. This allows an attacker controlling the section argument to inject newlines into .git/config, creating forged sections such as [core] with a malicious hooksPath. This leads to remote code execution (RCE) when git hooks are triggered. The vulnerability affects multiple version ranges of kimi-cli. A patch is available.
GitPython versions up to 3.1.52 contain a vulnerability where attacker-controlled submodule names can inject arbitrary configuration directives into the .git/config file. This occurs because section names are insufficiently sanitized, allowing injection of directives such as core.sshCommand, which can lead to remote code execution during subsequent git operations. The flaw arises from improper escaping of special characters in section headers, enabling same-line section breaks. This vulnerability is fixed in GitPython 3.24.0.
A vulnerability in Kimi CLI's GitPython integration (CVE-2026-42284) allows unsafe command-line options to bypass validation due to improper checking before shell splitting. Specifically, multi_options passed to clone operations are validated as original strings but executed after splitting, enabling injection of malicious git config options that execute attacker-controlled hooks during cloning or submodule updates.