GitPython CVE-2026-76217

Exploitation requires that an attacker can influence the **kwargs argument passed to either IndexFile.remove() or Head.checkout() in a GitPython-consuming application - specifically, supplying the pathspec_from_file key (mapping to --pathspec-from-file) pointing to an attacker-chosen file path, combined with pathspec_file_nul=True (mapping to --pathspec-file-nul). The --pathspec-file-nul flag is the critical amplifier: without it, only the first line of the target file is disclosed; with it, the entire file contents are returned. The CVSS 4.0 PR:L indicates low-privilege authenticated access to the application is required. Exploitation is bounded by the OS-level file permissions of the process running GitPython - only files readable by that user account can be exfiltrated. Applications that validate or restrict kwargs before passing them to these methods, or that do not expose these methods to external or user-supplied input, are not exploitable remotely. Non-default configuration is NOT required - the vulnerability exists in default GitPython installations whenever these methods accept unvalidated kwargs.

The CVSS 4.0 score of 7.1 (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N) reflects a network-reachable, low-complexity flaw with low-privilege prerequisites and high confidentiality impact. Real-world exploitability is strongly gated on whether attacker-controlled data can reach the **kwargs of the two vulnerable methods - a pattern that is common in web-based Git management panels, CI/CD APIs, and code review platforms, but not guaranteed. The public proof of concept in the GHSA advisory significantly lowers exploitation effort for targeted abuse. EPSS data was not provided in this dataset; without it, probabilistic exploitation likelihood cannot be quantified, but the requirement for controlled kwargs input suggests targeted rather than opportunistic mass exploitation. Active exploitation is not confirmed - this CVE is not in CISA KEV. The absence of scope change (SC:N/SI:N/SA:N) limits impact to files readable by the GitPython process, but in server-side contexts this routinely encompasses SSH private keys, application secrets, database credentials, and /etc/passwd. Overall, this is a real priority for any internet-facing application that passes user-supplied parameters into GitPython's remove() or checkout() interfaces; it is lower priority for tightly controlled internal tooling that restricts kwargs.

An attacker with low-privilege access to a web application that offers Git repository management via GitPython submits a crafted API request supplying pathspec_from_file='/etc/passwd' and pathspec_file_nul=True as parameters, which the application forwards without validation to repo.index.remove() or repo.heads[0].checkout(). GitPython passes these as --pathspec-from-file and --pathspec-file-nul to the underlying git subprocess; Git returns the file contents verbatim in an unmatched-pathspec error, which GitPython surfaces via GitCommandError.stderr. A complete proof of concept demonstrating this exact technique - including the Repo(), index.remove(), and stderr extraction pattern - is published in the vendor GHSA advisory GHSA-hh9p-6wh2-4mfc.