Description

GitPython before 3.1.56 contains an argument injection vulnerability in the Commit.count() method, which forwards keyword arguments to 'git rev-list' without the check_unsafe_options guard present in the sibling iter_items method. An attacker who can control options passed to Commit.count (e.g., via an application that forwards a user-supplied options dict) can supply output=<path>, causing 'git rev-list --output=<path>' to open and truncate the target file to zero bytes before revision parsing. This allows destruction/blanking of an arbitrary file at the process's privilege level (no content control, 0-byte truncation).

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.4",
  "pubDate": "2026-08-13T12:17:27.200Z",
  "pubdate": "2026-08-13T12:17:27.200Z",
  "executiveSummary": "GitPython before version 3.1.56 suffers from an argument injection vulnerability within the Commit.count() method.\nThe vulnerability allows an attacker capable of controlling options passed to the Commit.count method to trigger arbitrary file truncation at the process's privilege level.\nThe affected product is GitPython in versions prior to 3.1.56.\nThe risk implication is severe data loss, as critical system or application files can be zero-filled and effectively destroyed.\nThe attacker requires the capability to influence or control keyword arguments or option dictionaries forwarded to the vulnerable method.\nExploitation does not grant content control, resulting strictly in zero-byte truncation of the targeted file path.",
  "technicalDetails": "The root cause of the vulnerability resides in the Commit.count() method of GitPython, which directly forwards keyword arguments to the underlying 'git rev-list' command without incorporating the necessary check_unsafe_options validation guard.\nThis validation guard is present in sibling methods such as iter_items, but its omission in Commit.count() permits arbitrary flag and option injection into the Git subprocess execution.\nAn attacker exploits this behavior by supplying the output=<path> option through an application interface that improperly forwards user-supplied option dictionaries into the Commit.count() invocation.\nThe attack flow proceeds as follows: First, the attacker supplies a crafted parameter containing output=<path>. Second, GitPython constructs and executes the 'git rev-list --output=<path>' command using the injected argument. Third, the underlying git executable processes the --output flag, which immediately opens and truncates the specified target file to zero bytes prior to executing revision parsing.\nThe vulnerable component is the Commit.count() method in GitPython.\nAffected versions include all GitPython releases prior to 3.1.56.\nNo specific authentication requirements are inherently mandated by the vulnerability itself, as exploitability depends entirely on how the host application exposes the vulnerable function to untrusted inputs.\nPrivilege requirements are bound to the operating system permissions of the process executing the Python application, allowing destruction of any file accessible to that security context.\nNetwork exposure is indirect and contingent upon application architecture, typically manifesting when web applications or APIs accept and pass user-controlled parameters into GitPython query functions.\nThe payload behavior is non-interactive and destructive, leveraging Git's native output redirection capabilities to overwrite targeted files with empty contents.\nThe post-exploitation impact is limited to denial of service, file corruption, and data destruction due to the 0-byte truncation constraint."
}