CVE-2026-73621

The vulnerability in GitPython's count() method stems from a protection gap that's more architectural than accidental: check_unsafe_options existed in iter_items but was absent from count(), even though both methods forward kwargs to the same git subprocess. This is the invisible attack surface that emerges when security patches are applied method-by-method rather than enforced at the API boundary. A developer using count() with user-adjacent option dicts — exactly the documented use case for this library — had no way to know they were operating in unprotected territory. The guard in iter_items likely arrived as a reactive patch after some prior incident, but no subsequent sweep identified that count() used structurally identical kwargs-passing mechanics without equivalent protection. The EPSS score of 0.00199 suggests low immediate exploitability, but the real exposure is the kwargs-forwarding surface itself: any method in GitPython that accepts **kwargs and passes them to git commands is a potential vector, and counting the methods that got this treatment versus the ones that didn't is an exercise in trust rather than verification. The correct response is not to audit count() alone, but to assume the entire kwargs-passing surface is suspect until proven otherwise. Avoid forwarding user-supplied option dictionaries to any GitPython method without explicit validation. If your codebase passes option dicts from user input to git commands, treat that code path as vulnerable by default and build an explicit whitelist of permitted options at your application boundary — do not rely on the library's internal guards, because those guards are applied unevenly and will decay as maintainers rotate and institutional memory of why they exist evaporates.

Reviewed through automated stages and approved by a human before publication.