GHSA-x2qx-6953-8485: Argument Injection via Insecure Transformation in GitPython

The GitPython library provides Python bindings to interact with Git repositories. The vulnerability resides within the git/repo/base.py file, specifically inside the _clone() method used to facilitate repository cloning operations. This method accepts a parameter named multi_options, which allows developers to pass a list of strings representing specific Git command-line options.

The security boundary for this function relies on validating the elements within the multi_options list before passing them to the underlying system shell. The validation process aims to identify and block dangerous Git options, such as those invoking external diff tools or altering protocol extensions. If successful, the validation prevents attackers from appending execution directives to the Git command.

The flaw occurs due to an insecure data transformation sequence following the validation step. The application joins the validated list into a single string using spaces, and then re-parses this string using shlex.split(). This transformation creates a structural disparity between what is validated and what is ultimately executed.

An attacker can supply input that passes the initial validation checks but is re-interpreted as a dangerous argument after the shlex.split() operation. This results in Argument Injection (CWE-88), leading to arbitrary command execution on the host system under the privileges of the Python process.

The root cause of this vulnerability is a state discrepancy between the validation phase and the execution phase. The input is evaluated for security constraints in its original list format. However, the input is later flattened into a string and re-tokenized before execution.

During the cloning process, the application iterates through the multi_options list, applying security checks to each string element. The logic expects each element to represent a discrete Git configuration key or parameter. The validator checks the prefix or contents of these elements against an internal blocklist or allowlist.

Following validation, the application executes shlex.split(" ".join(multi_options)). This specific sequence creates a semantic shift in how the arguments are bounded. A single string element containing spaces and nested quotes within the original list is treated as a single, contiguous unit by the validator.

When shlex.split() processes the joined string, it respects shell-quoting rules. It breaks apart the previously contiguous string at the spaces, unless they are enclosed in quotes. An attacker crafts a single list element containing a benign prefix followed by unquoted spaces and a malicious payload. The validator approves the element based on the benign prefix, but the subsequent split operation extracts the malicious payload as an entirely new, standalone argument.

The vulnerability is localized to the _clone function within git/repo/base.py. The code attempts to securely parse multi_options but introduces a critical flow control error in its data handling pipeline.

The vulnerable implementation follows a specific pattern that invalidates the prior security checks:

# Vulnerable Implementation Concept
def _clone(self, ... multi_options=None, ...):
    if multi_options:
        # 1. Validation phase analyzes original list elements
        for opt in multi_options:
            validate_option(opt) 
        
        # 2. Insecure transformation occurs here
        multi = shlex.split(" ".join(multi_options))
        
        # 3. Execution proceeds with the modified 'multi' list
        execute_git_command(multi)

The patch removes the intermediate serialization and deserialization steps. The fix ensures that the structural integrity of the multi_options list remains consistent between the validation routine and the execution call. The validated list is passed directly to the execution context.

# Patched Implementation Concept
def _clone(self, ... multi_options=None, ...):
    if multi_options:
        for opt in multi_options:
            validate_option(opt) 
        
        # 2. Direct assignment preserves structural integrity
        multi = multi_options
        
        execute_git_command(multi)

By eliminating the join and shlex.split sequence, the application guarantees that an element evaluated as a single argument during validation remains a single argument during execution. This prevents the injection of secondary arguments via shell metacharacters.

Exploitation requires the target application to accept user-controlled input and pass it to the multi_options argument of a GitPython clone operation. The attacker must control the content of at least one string element within the list provided to the function.

The attacker constructs a payload utilizing shell-quoting mechanics to exploit the shlex.split behavior. A common attack vector involves injecting the --upload-pack parameter, which instructs Git to execute an external command. The payload is formatted to hide this parameter from the initial validation check.

Consider the following injected list element: ["-c", 'protocol.ext.allow=always " --upload-pack=touch /tmp/pwn"']. The validation engine processes the second element as a single string. It identifies the benign protocol.ext.allow=always prefix and permits the string to pass.

The join operation concatenates the list into the string: -c protocol.ext.allow=always " --upload-pack=touch /tmp/pwn". The shlex.split operation then parses this string into three separate list items: ['-c', 'protocol.ext.allow=always', '--upload-pack=touch /tmp/pwn']. The --upload-pack directive is now active as an independent argument and executes the arbitrary command when Git runs.

Successful exploitation of this vulnerability results in arbitrary command execution on the host operating system. The injected commands execute with the identical permissions and environment variables as the Python application utilizing the GitPython library.

Attackers typically leverage specific Git arguments to achieve code execution. Options such as --upload-pack, --receive-pack, or core.sshCommand are designed to invoke external binaries to support Git protocols. By injecting these parameters, an attacker forces the Git executable to spawn malicious subprocesses.

The CVSS score indicates a high severity, estimated between 7.5 and 8.8. The variance in severity depends entirely on the application's architecture and whether it exposes the multi_options parameter to untrusted users over a network boundary.

The resulting compromise allows for complete control over the application environment. Attackers can exfiltrate sensitive data, read environment variables, modify local repositories, or establish persistent backdoors to facilitate lateral movement within the network infrastructure.

The primary remediation for this vulnerability is updating GitPython to version 3.1.44 or later. This release contains the necessary patch to remove the insecure string transformation, ensuring arguments maintain their structural boundaries throughout the function execution.

Organizations must identify all instances of GitPython usage within their environments. Security teams should perform a code audit searching for usages of Repo.clone_from() or any internal calls to _clone(). Any instance where the multi_options argument is populated using data from untrusted sources must be triaged immediately.

If immediate patching is not possible, developers must implement strict input sanitization. The application must enforce an allowlist of permitted Git configuration keys and values. User-supplied data must never populate the multi_options array directly without passing through this strict allowlist.

Deploy defense-in-depth measures to contain potential exploitation. Run the Python application with least privilege, restricting its read and write access to necessary directories only. Limit the execution environment using containerization, mandatory access controls, and strict egress firewall rules to prevent reverse shells.