GitPython EUVD-2026-65224

Exploitation requires three concurrent conditions: (1) the target application uses GitPython's Repo.blame() method, (2) user-controlled input is passed as the revision argument without independent sanitization - specifically, the application does not validate that the revision matches a safe format before calling GitPython, and (3) the attacker holds at least low-privilege access to invoke the blame functionality (confirmed by PR:L in the CVSS 4.0 vector). The attacker must be able to supply a string beginning with --contents=<filepath> or -S <filepath> as the revision value. Exploitation is strictly bounded by the PR:L requirement: unauthenticated external attackers cannot exploit this without first obtaining application-level access. Confidentiality impact is high but scoped to files readable by the process user; there is no integrity (VI:N) or availability (VA:N) impact per the CVSS vector. Deployments that do not expose Repo.blame() to user-controlled revision input, or that independently validate revision format, are not exploitable.

The CVSS 4.0 base score of 7.1 (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N) reflects a realistic and constrained threat: network-accessible, low-complexity exploitation requiring only low-privilege application access, yielding high confidentiality impact. The PR:L requirement is the most meaningful limiting factor - an unauthenticated attacker cannot reach Repo.blame() without first obtaining application-level credentials or a session. The vulnerability is not listed in CISA KEV and no public exploit code has been identified, reducing urgency compared to actively-exploited issues. EPSS score data was absent from the provided intelligence, so probability-of-exploitation cannot be precisely quantified. However, the denylist gap is structurally simple to abuse - --contents and -S are standard documented git options that were merely overlooked - meaning that once an attacker has the necessary access, no specialized knowledge or tooling is required. Web applications and CI/CD services that expose git blame to user-supplied revision input represent the highest-risk deployment pattern and should treat this as an upgrade priority rather than a deferred backlog item.

An attacker with authenticated access to a web application that internally calls Repo.blame() with a user-supplied revision string submits a request where the revision is set to --contents=/etc/passwd. GitPython passes this string unsanitized to git blame, which interprets it as an option rather than a commit reference and reads /etc/passwd, returning its contents embedded in the blame output to the application - and ultimately to the attacker. No public exploit code has been identified, but the attack requires only a standard HTTP request with a crafted parameter value.