Listen to this Post
The vulnerability resides in GitPython’s `Commit.count()` method, which forwards arbitrary keyword arguments (kwargs) directly to the underlying `git rev-list` command without any validation. The `check_unsafe_options` guard — which exists in the sibling `iter_items` method (commit.py:341) — is completely absent from `count` (commit.py:290-291). Git’s `rev-list` command accepts a `–output=output='/path/to/victim', causing the target file to be destroyed or blanked. This is a distinct, uncovered sink: the earlier GHSA-956x-8gvw-wg5v fixed `iter_commits` and blame, but explicitly did not cover count. Live verification on HEAD (tag 3.1.53) confirmed that `count(output=/victim)` truncated a pre-existing file to 0 bytes, while the guarded `iter_commits(output=)` raised an UnsafeOptionError. The attack chain is straightforward: an application forwards user-supplied options into `commit.count()` without sanitisation; the unguarded method passes `–output=/victim` to git rev-list; the Git binary truncates the file. Because the write is a 0-byte truncation with no content control and reachability requires the attacker to control the `kwargs` dict (key-control only), the severity is assessed as MEDIUM. All GitPython versions up to and including 3.1.53 are affected. The fix is to add the same `check_unsafe_options` call to `Commit.count` that already protects iter_items.
DailyCVE Form:
Platform: GitPython
Version: <= 3.1.53
Vulnerability : Argument injection -> arbitrary file truncation
Severity: MEDIUM
date: 2026-08-03
Prediction: 2026-07-24 (3.1.54)
What Undercode Say:
Analytics:
- Attack surface: Any Python application that passes user-controlled dict to `commit.count()`
– Bypass proof: `iter_commits(output=)` raisesUnsafeOptionError; `count(output=)` does not - Root cause: Missing `check_unsafe_options` guard in `commit.py:290-291`
– Fixed in: 3.1.54 (adds guard toCommit.count)
Bash commands and codes:
PoC – truncate /etc/passwd (if writable)
python3 -c "from git import Repo; r=Repo('.'); r.commit('HEAD').count(output='/tmp/pwned')"
Verify truncation
ls -la /tmp/pwned
Vulnerable code path (GitPython <= 3.1.53) def count(self, kwargs): return self.repo.git.rev_list(self.hexsha, kwargs) no check_unsafe_options Safe sibling (guarded) def iter_items(self, args, kwargs): self.repo.git.check_unsafe_options(kwargs) guard present return self.repo.git.rev_list(args, kwargs)
Exploit:
- Attacker supplies `output=’/path/to/victim’` as a keyword argument to `commit.count()`
– No guard blocks the unsafe `–output` option
– `git rev-list–output=/victim` executes, truncating `/victim` to 0 bytes - No command execution or file content injection — only 0-byte truncation
Protection:
- Upgrade to GitPython >= 3.1.54
- If upgrade is not possible, avoid passing untrusted keyword arguments to `commit.count()`
– Alternatively, manually sanitise input by rejecting any key matching `output` or `–output` before calling `count()`
– Applications that do not forward user-controlled dicts to `commit.count()` are not exploitable
Impact:
- Arbitrary file truncation (0-byte overwrite) at the privilege level of the Python process
- Loss of file integrity and availability (data destruction)
- No remote code execution; no content injection
- Medium severity due to key-control precondition and limited write capability
- Affects all versions <= 3.1.53; fixed in 3.1.54
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
