GitPython CVE-2026-73621

The vulnerable application must explicitly forward a user-controlled keyword arguments dictionary to Commit.count() - specifically, the attacker must be able to supply the output= key in that dict. This is not the default usage of GitPython; it requires an application design decision to route external input into **kwargs. The injection does not affect Commit.count() called with no user-controlled arguments, nor does it affect iter_commits() or iter_items(), both of which raise UnsafeOptionError on the same payload. Exploitation is further limited by impact class: attackers gain only 0-byte truncation (no content control), and the set of targetable files is bounded by the OS privilege level of the running process. The application must use self.hexsha internally - ref control is not needed, reducing the precondition to option-key control only.

The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) scores 5.3 (Medium), reflecting network reachability and low complexity once an application routes user input into Commit.count(), but constrained by the PR:L requirement and limited VI:L/VA:L impact (no content control, no confidentiality loss). Real-world risk is tightly conditional: exploitation requires an application to explicitly forward a user-controlled options dict to count(), a pattern previously seen in GHSA-956x-8gvw-wg5v's archive(**kwargs) sink, meaning the attack surface is real but not universal. The raw score may underweight impact in privileged deployments where zero-byte truncation of config files, key material, or database files could cause cascading service failure. No CISA KEV listing is present, and no EPSS signal is available in the provided data to cross-reference exploitation probability - this gap should be monitored. The published proof-of-concept in the GHSA advisory lowers the technical bar for exploitation in vulnerable application patterns. The CVSS AC:L assessment by the reporter contrasts with the application-dependent precondition; defenders should treat this as AC:H in practice unless their codebase is confirmed to forward user options to count().

A CI/CD dashboard or code-review application that accepts user-specified rev-list options and forwards them to Commit.count() - for instance, to support custom commit filtering - would allow an authenticated user to submit output=/etc/app/config.ini as an option. The underlying git rev-list subprocess would truncate that file to zero bytes, corrupting application configuration or destroying key material without the attacker ever needing write access to the filesystem directly. A proof-of-concept demonstrating this exact truncation was verified by the researcher on GitPython tag 3.1.53 and is published in GHSA-p538-c434-8v24.