GHSA-3f7w-8rr8-f37f: Arbitrary File Overwrite and Read via Unguarded Argument Forwarding in GitPython

GitPython is a Python library used to interact with Git repositories by abstracting command-line operations into Pythonic APIs. The library provides high-level classes such as IndexFile and TagReference to manage git indexes and reference tags respectively. When these classes perform actions, they serialize programmatic options and dispatch execution to the local system's git binary.

The attack surface exists within any API wrapper that passes developer-controlled keyword arguments directly to the underlying shell command execution. By default, GitPython features an opt-in parameter validation system called Git.check_unsafe_options(). However, because this verification is not enforced globally at the execution dispatcher layer, any API wrapper that omits the validation remains completely unguarded.

Two critical wrapper methods are vulnerable to this design pattern. The IndexFile.checkout() method forwards arguments to git checkout-index, which accepts the --prefix option to redirect file creation outside the workspace. The TagReference.create() method forwards arguments to git tag, which accepts the -F or --file options to read local system files and return them in-band. This leads to arbitrary file write (integrity and availability compromise) and arbitrary file read (confidentiality compromise).

The root cause of this vulnerability lies in improper validation of command-line arguments, classified under CWE-88 (Argument Injection) and CWE-20 (Improper Input Validation). GitPython relies on individual, opt-in implementations of Git.check_unsafe_options() inside wrapper functions to maintain security. If a wrapper accepts **kwargs and passes them directly to the git command execution without sanitization, an attacker who controls the arguments can inject system flags.

In IndexFile.checkout(), the python method forwards arguments to git checkout-index. The --prefix=<path> command-line option specifies a prefix directory to prepend to checked-out paths. Because there is no check preventing the use of --prefix, an attacker can specify absolute directories or directory traversal sequences. This allows the application to write files from the repository to arbitrary paths on the local filesystem, overwriting existing files if run with appropriate permissions.

In TagReference.create(), the method maps to the git tag command. The command-line utility supports the -F <file> and --file=<file> options to import a tag message from a target file. Because GitPython does not filter these options, an attacker can specify a sensitive system file as the source. GitPython subsequently reads this file, associates it with the created tag object, and exposes its raw contents when the application accesses the TagReference.tag.message property.

Before the patch, git/index/base.py contained the following unsafe forwarding mechanism:

def checkout(self, paths=None, force=False, fprogress=lambda *args: None, **kwargs):
    # Unsanitized kwargs are passed directly to checkout_index
    proc = self.repo.git.checkout_index(*args, **kwargs)

Because there is no invocation of Git.check_unsafe_options() or defined blocked option list, any keys in kwargs are converted directly into command-line arguments. For example, passing prefix='/tmp/' evaluates to --prefix=/tmp/ in the shell execution.

Similarly, git/refs/tag.py contained the following definition:

def create(cls, repo, path, reference="HEAD", logmsg=None, force=False, **kwargs):
    # Forwarded directly to the underlying git wrapper without verification
    # kwargs can contain 'F' or 'file' keys

To address this, the patch introduces class-level variables specifying banned options and updates the method signatures to accept allow_unsafe_options: bool = False. Inside the methods, an explicit check validates the passed arguments against the blocklist unless allow_unsafe_options is set to True:

# Inside IndexFile
unsafe_git_checkout_index_options = ["--prefix"]
 
# Validation check added to checkout()
if not allow_unsafe_options:
    Git.check_unsafe_options(
        options=Git._option_candidates([], kwargs),
        unsafe_options=self.unsafe_git_checkout_index_options,
    )

Exploitation requires the attacker to be able to supply or influence the keyword arguments (**kwargs) passed to either of the vulnerable methods. This scenario typically occurs in web applications, automated CI/CD pipelines, or repository management dashboards that accept custom execution configurations from users.

To perform an arbitrary file overwrite, an attacker invokes index.checkout() with a custom prefix argument pointing to a system target. The following proof-of-concept demonstrates how the exploit redirects repository files to write directly into /tmp/target_dir/ instead of the local repository workspace:

from git import Repo
import os
 
repo = Repo("/path/to/repo")
# Executes 'git checkout-index -a -f --prefix=/tmp/target_dir/'
repo.index.checkout(prefix="/tmp/target_dir/", a=True, f=True)

To perform an arbitrary file read, the attacker targets TagReference.create() by specifying the -F parameter with the target file path. When GitPython spawns the process, it reads the target file and records its content as the tag message. The application can then read the sensitive file content in-band:

from git import Repo
from git.refs.tag import TagReference
 
repo = Repo("/path/to/repo")
# Executes 'git tag -a -f -F /etc/passwd leak_tag'
tag_ref = TagReference.create(repo, "leak_tag", force=True, a=True, F="/etc/passwd")
leaked_data = tag_ref.tag.message
print(leaked_data)

The impact of these two primitives is high. The arbitrary file overwrite primitive enables attackers to compromise system integrity. If the application runs with root privileges or within a user directory, an attacker can overwrite critical files such as .bashrc, .ssh/authorized_keys, or configuration files, potentially escalating privileges or achieving remote code execution.

The arbitrary file read primitive directly breaks confidentiality. In automated environments, this allows attackers to leak configuration properties, local environment variables, system user information (such as /etc/passwd), or application source code. The data is returned directly to the calling context, which may output it to web interfaces or log collectors.

Because the underlying vulnerability pattern (opt-in security checks) relies on manual application on a per-wrapper basis, additional undocumented wrappers may still expose similar argument injection vectors. The CVSS score of 8.1 reflects high integrity and availability impact, though configuration-dependent confidentiality impacts are also severe.