GitPython versions prior to 1.2.0.post0_12 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 and transmitted to attacker-controlled hosts during fetch or pull operations.
GitPython versions up to 3.1.53 contain a vulnerability in the Commit.count() method where unguarded forwarding of keyword arguments to git rev-list allows arbitrary file truncation. Specifically, using the output argument causes git rev-list to open and truncate the specified file to zero bytes before processing, enabling destruction of arbitrary files with the process's privileges. This vulnerability has a medium severity impact due to the integrity and availability loss but limited reachability and no content control over the truncation.
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 repository cloning. The vulnerability arises because git copies and executes hooks from the specified template directory during clone operations, and the default configuration does not block this option.
GitPython versions before 1.2.0.post0_13 contain unguarded forwarding of git command options in 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 writable by the process using the --prefix option. The tag creation method forwards unsafe options to git tag, allowing reading arbitrary files via the -F/--file option. Both issues arise from missing safety checks on forwarded kwargs. A fix is available in version 1.2.0.post0_13.
GitPython's Repo.archive() method uses a denylist to block unsafe git archive options that could lead to arbitrary command execution or file writes. However, the denylist is incomplete and omits the --add-file and --add-virtual-file options, which allow reading arbitrary files from the filesystem and injecting attacker-controlled content into archives. This flaw enables an attacker who can influence the options passed to Repo.archive() to read arbitrary files on the host with the privileges of the running process. The issue is fixed in GitPython version 1.2.0.post0_13.
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.
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.
CVE-2024-22190 is a high-severity vulnerability in the Legit tool related to GitPython's handling of untrusted search paths on Windows. It allows arbitrary code execution if GitPython runs git commands through a shell or executes bash.exe to interpret hooks, potentially running malicious executables from untrusted repository directories. This vulnerability is a result of incomplete mitigation of a previous issue (CVE-2023-40590).
GitPython version 3.1.50 contains a vulnerability where the default unsafe option gate intended to block dangerous git clone options can be bypassed using joined short-option forms such as '-u<helper>'. This allows execution of local commands via Git's upload-pack option even when unsafe options are supposed to be blocked. The issue arises because the option canonicalization does not recognize joined short options correctly, leading to a residual security bypass.
GitPython versions prior to 1.2.0.post0_11 contain command injection vulnerabilities in the Repo.archive(), git.ls_remote(), and other arbitrary git command invocations. These flaws allow untrusted input to inject and execute arbitrary commands via unsafe handling of Git options such as --exec and upload-pack. Additionally, certain Git commands can truncate arbitrary files if malicious revision strings are passed. These issues were fixed in version 1.2.0.post0_11.
GitPython versions up to 3.1.50 contain a vulnerability where the Repo.clone_from() method passes the clone URL through os.path.expandvars(), causing environment variables in the URL to be expanded server-side. This can lead to exfiltration of sensitive environment variables such as AWS_SECRET_ACCESS_KEY or GITHUB_TOKEN to an attacker-controlled host. The issue arises because polish_url() applies environment variable expansion indiscriminately to URLs, without scheme checks or opt-outs. The vulnerability is fixed in version 1.2.0.post0_11.
GitPython versions prior to 1.2.0.post0_9 contain a vulnerability in config_writer().set_value() where newline characters in values are not properly validated. This allows injection of a malicious core.hooksPath configuration, enabling remote code execution via Git hooks. The flaw arises because GitPython converts embedded newlines into indented continuation lines, which Git still interprets as valid section headers, activating attacker-controlled hooks. This can lead to persistent repository config poisoning, especially in multi-user or hosted environments where untrusted input is passed to set_value().
GitPython versions from 1.2.0.post0_3 up to but not including 1.2.0.post0_9 contain a command injection vulnerability. This occurs because unsafe Git options like --upload-pack and --receive-pack are blocked when passed as hyphenated kwargs, but the equivalent underscore-form kwargs bypass the safety checks and allow arbitrary command execution. This affects API methods such as Repo.clone_from(), Remote.fetch(), Remote.pull(), and Remote.push(). A fix is available in version 1.2.0.post0_9.
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 like core.sshCommand, which can lead to remote code execution on the victim's next git operation. The vulnerability is fixed in version 1.2.0.post0_11.
GitPython versions from 0.1.0 up to but not including 1.2.0.post0_11 contain a command injection vulnerability (CVE-2026-67325) due to incomplete blocking of unsafe git options. The vulnerability arises because the fix for a previous issue (CVE-2026-42215) only blocks exact matches of dangerous git options but does not account for git's acceptance of unambiguous long-option prefix abbreviations. This allows attackers controlling keyword argument keys to bypass the blocklist and execute arbitrary commands during clone, fetch, pull, or push operations. A patch is available in version 1.2.0.post0_11.
GitPython versions up to 3.1.46 and the current main branch (3.1.47 locally) contain a path traversal vulnerability in their reference APIs. This flaw allows attackers who can supply crafted reference paths to write, overwrite, move, or delete files outside the repository's .git directory due to insufficient validation of reference paths during write, rename, and delete operations. The vulnerability requires local access to influence reference names passed to GitPython APIs. It can lead to high integrity and availability impacts by corrupting or deleting arbitrary files accessible by the process.