
Loading

Loading
We use strictly necessary cookies to run this site, and analytics cookies to understand how it's used. See our Privacy Policy for details.
A GitHub-reviewed security advisory, not necessarily under active exploitation the way our CISA KEV advisories are, but a real, disclosed vulnerability in an open-source dependency.
Affected packages
Vulnerable: >= 3.1.59, < 3.1.60
Patched in 3.1.60
Details
GitPython 3.1.59 blocks a previously available local-file read path through unsafe git diff options such as -O/--orderfile.
However, the high-level diff API still permits --no-index with the default allow_unsafe_options=False.
--no-index changes the semantics of the paths arguments: instead of repository-relative pathspecs, Git interprets them as arbitrary filesystem paths.
When combined with the still-allowed -I/--ignore-matching-lines option, this creates a content-dependent Boolean oracle over a caller-selected local file.
This was reproduced against the published GitPython 3.1.59 wheel.
The original unsafe-option path is blocked in 3.1.59, while this alternate path remains reachable without setting allow_unsafe_options=True.
Confirmed API surface:
repo.index.diff( None, no_index=True, I=pattern, paths=[baseline_path, target_path], create_patch=True, )
The relevant behavior is:
An application that forwards attacker-influenced diff options and paths and exposes the success/error distinction can therefore be queried repeatedly to recover a guessable local single-line secret.
The issue was confirmed with the default allow_unsafe_options=False.
The behavior does not require the caller to explicitly opt into GitPython's unsafe-option mode.
Verified intended security boundary:
This appears to be an alternate route to the same local-file confidentiality property that the 3.1.59 diff option hardening is intended to protect.
A minimal reproducer, controlled extraction demonstrator, proof matrix, and proposed remediation are included in the attached package.
gitpython-3159-maintainer-evidence.zip
The minimal reproducer creates only temporary researcher-controlled files and demonstrates the following predicate:
correct prefix -> normal GitPython return incorrect prefix -> GitCommandError(status=1)
In the controlled extraction test, I generated three independent random single-line values and recovered all three exactly through repeated calls to the GitPython high-level API.
Result: 3/3 recovered.
The extraction harness also installs a Python audit hook that rejects direct Python open() access to the target file during the oracle phase. The content-dependent read is therefore performed by the child git process invoked through GitPython rather than by the reproduction script directly.
Controls were also tested:
Suggested remediation is to classify --no-index as unsafe for the high-level diff API unless the caller explicitly sets allow_unsafe_options=True.
Potential impact is disclosure of local files readable by the process running GitPython.
Exploitation requires an embedding application to allow an attacker to influence:
The demonstrated attack is a blind content oracle rather than a one-request in-band file read. It is particularly applicable to short or structured single-line secrets where the target path and approximate value format are known or guessable.
Confirmed affected release: GitPython 3.1.59.
More pip advisories
Talk to us about this
Find out whether this dependency (or others like it) is actually reachable in your codebase.
Get help patching, or building dependency-scanning into your pipeline going forward.
A secure code review or supply chain review finds this before an advisory does.