The Commit.count() method in GitPython forwards keyword arguments directly to git rev-list without checking for unsafe options, unlike the sibling iter_items method which has such a guard. Specifically, passing an output parameter to count() results in git rev-list executing with --output=<path>, which truncates the specified file to zero bytes before processing revisions. This allows an attacker with the ability to influence the output argument to destroy or blank arbitrary files at the process privilege level. The vulnerability affects GitPython versions up to 3.1.53 and was confirmed by proof-of-concept truncation of files. The issue is distinct from previously fixed vulnerabilities in iter_commits and blame methods. The recommended fix is to add check_unsafe_options to Commit.count(), mirroring the protection in iter_items.

An attacker able to control the output argument passed to Commit.count() can cause arbitrary files to be truncated to zero bytes, resulting in loss of file integrity and availability. The truncation occurs with the privileges of the running process. There is no content injection or confidentiality impact. The reachability is limited to contexts where the output argument can be influenced, and the impact is limited to file destruction (zero-byte truncation).

A patch is available that adds unsafe option checks to Commit.count(), preventing injection of the --output argument. Users should upgrade to GitPython versions 3.1.56 or later where this fix is applied. Until patched, avoid passing untrusted input to Commit.count() keyword arguments, especially the output parameter.