GHSA-P538-C434-8V24: Arbitrary File Truncation via Argument Injection in GitPython Commit.count

GitPython is an open-source Python library used to interact with Git repositories by programmatically wrapping the Git command-line binary. The library abstracts Git CLI commands into high-level Python objects, facilitating repository management, commit inspection, and history traversal.

Within this architecture, the Commit.count method is designed to count the number of commits reachable from a specific reference. To provide flexibility, the method dynamically forwards arbitrary keyword arguments to the underlying Git command execution layer.

This implementation exposes an argument injection attack surface. If an application forwards untrusted user input directly as keyword arguments into Commit.count, an attacker can inject arbitrary command-line parameters. Specifically, injecting the --output option instructs the Git binary to write command output to a specified target file, causing the system to truncate that file immediately.

The root cause of GHSA-P538-C434-8V24 is improper input validation (CWE-20) combined with argument injection (CWE-88) in git/objects/commit.py. The Commit.count method accepted raw keyword arguments (**kwargs) and forwarded them directly to the underlying execution process without validation.

When GitPython translates Python keyword arguments to Git CLI arguments, a key-value pair such as {"output": "/path/to/file"} is converted into --output=/path/to/file. While sibling APIs in GitPython implemented safety checks via Git.check_unsafe_options to filter out dangerous flags, the Commit.count method was left entirely unguarded.

When the underlying binary executes git rev-list --output=/path/to/file, the Git process immediately initiates a file write handle on the target path. As part of this standard file system operation, the target file is truncated to zero bytes before any commit logic is processed. This behavior is native to the Git binary and occurs regardless of the validity of the rest of the command execution.

The vulnerability exists in the count method of the Commit class in git/objects/commit.py. Below is the vulnerable implementation where **kwargs are forwarded to the Git command execution without any filtering:

# Vulnerable implementation in git/objects/commit.py
def count(self, paths: Union[PathLike, Sequence[PathLike]] = "", **kwargs: Any) -> int:
    # Raw kwargs are directly forwarded without validation
    # ...

The security patch introduced in version 3.1.56 remediates this vulnerability by validating input options against a known blacklist of unsafe parameters. The following diff highlights the remediation steps implemented by the maintainers:

@@ -269,13 +269,21 @@ def summary(self) -> Union[str, bytes]:
         else:
             return self.message.split(b"\n", 1)[0]
 
-    def count(self, paths: Union[PathLike, Sequence[PathLike]] = "", **kwargs: Any) -> int:
+    def count(
+        self,
+        paths: Union[PathLike, Sequence[PathLike]] = "",
+        allow_unsafe_options: bool = False,
+        **kwargs: Any,
+    ) -> int:
         """Count the number of commits reachable from this commit.
 
         :param paths:
             An optional path or a list of paths restricting the return value to commits
             actually containing the paths.
 
+        :param allow_unsafe_options:
+            Allow unsafe options, like ``--output``.
+
         :param kwargs:
             Additional options to be passed to :manpage:`git-rev-list(1)`.
         """
+        if not allow_unsafe_options:
+            Git.check_unsafe_options(
+                options=Git._option_candidates([], kwargs), unsafe_options=self.unsafe_git_rev_options
+            )
+
         if paths:

This modification adds a default-false allow_unsafe_options parameter. When false, the method extracts command candidates and validates them against the self.unsafe_git_rev_options collection, effectively blocking dangerous options such as --output.

An attack requires that an application dynamically accepts user-controlled inputs and translates them into keyword arguments unpacked within the Commit.count method. The threat model typically involves an application exposing a web API that permits query parameter customization.

During exploitation, the attacker supplies a key-value pair where the key is set to output and the value is the path of a sensitive system or application file. The application unpacks these arguments directly into the method call.

Upon invocation, the library spawns the git rev-list command with the --output parameter. The operating system's file system handler, driven by the Git binary's initialization process, immediately empties the content of the target file to prepare it for writing. This sequence completes before any verification or commit counting occurs.

The security impact of GHSA-P538-C434-8V24 is high regarding integrity and availability, while maintaining low confidentiality impact. By exploiting this flaw, an unauthenticated attacker can disable services, corrupt configurations, or clear critical log archives on the hosting environment.

If the application process runs with elevated privileges, such as root or Administrator, the attacker can truncate system-critical files like /etc/hosts, systemd service files, or application binaries. This results in immediate denial of service or system instability.

In containerized environments or CI/CD pipelines, this vulnerability can be leveraged to corrupt build states or clear environment variables. Because GitPython is commonly integrated into automation frameworks, the potential radius of impact spans multiple connected systems.

The definitive remediation is upgrading GitPython to version 3.1.56 or higher. This update enables the default option validation, raising an UnsafeOptionError if an unsafe parameter is supplied.

If immediate upgrade is not feasible, implement strict input sanitization on all dynamically generated keyword arguments before they are passed to GitPython. Applications must sanitize and filter input dictionaries to ensure no blacklisted keys, such as output, are allowed.

Additionally, developers must evaluate whether downstream parameters can bypass validation. For instance, passing malicious inputs through positional array parameters like paths could still result in option injection if the command builder fails to cleanly separate arguments using double dashes. Ensuring strict parameter isolation is vital for complete defense.