Easily map the attack path and prioritize which CVEs are a threat to your organization
Miggo AIGenerate vendor-ready rules for the observed attack patterns, plus reasoning and safe deployment guidance
| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| GitPython | pip | <= 3.1.56 | 3.1.57 |
Miggo AIRoot Cause AnalysisThe vulnerability stems from two methods, IndexFile.checkout and TagReference.create, which accepted and forwarded arbitrary keyword arguments (**kwargs) to underlying git command-line calls without proper sanitization. This allowed attackers to inject dangerous options into the executed commands.
In the case of IndexFile.checkout, the --prefix option could be passed to git checkout-index, leading to an arbitrary file overwrite vulnerability. An attacker could specify any directory on the filesystem as a prefix, causing git to write files outside the repository's working directory.
In the case of TagReference.create, the -F or --file option could be passed to git tag, leading to an arbitrary file read vulnerability. An attacker could specify a path to any file on the filesystem, and the content of that file would be embedded in the created tag's message, which is then returned to the caller.
The patch addresses these issues by introducing an allow_unsafe_options parameter to both methods and implementing a check (Git.check_unsafe_options) to block potentially harmful options like --prefix, --file, and -F by default. This ensures that these dangerous options can only be used if explicitly allowed by the developer, thus mitigating the risk of exploitation.
IndexFile.checkoutgit/index/base.py
TagReference.creategit/refs/tag.py
There is no allow_unsafe_options parameter and no check_unsafe_options() call in the method.
git checkout-index accepts --prefix=<string>, prepended to every output path. It is not confined to the working tree, so an absolute prefix writes tracked file contents anywhere the process can write, and -f overwrites what is already there.
from git import Repo
Repo("/path/to/repo").index.checkout(prefix="/tmp/target_dir/", a=True, f=True)
Observed (poc/poc_checkout_index.py) — no exception raised, files land outside the repository:
[ALLOWED] no UnsafeOptionError raised
files written outside the repo: ['f.txt']
f.txt: 'hi\n'
Overwrite of a pre-existing file (poc/poc_ci_overwrite.py) — the victim file held ORIGINAL-DO-NOT-CLOBBER\n before the call:
[ALLOWED] no exception
victim content now: 'hi\n'
OVERWRITTEN: True
Both halves of the write are attacker-influenced:
prefix kwarg.Commit a file named authorized_keys, .bashrc, config or post-checkout, choose the matching prefix (~/.ssh/, ~/, .git/hooks/), and the write becomes code execution as the service account.
For comparison within this project: GHSA-fjr4-x663-mwxc (arbitrary file overwrite via git diff --output) is rated High, and GHSA-p538-c434-8v24 (arbitrary file truncation via git rev-list --output) is rated Medium. --prefix supplies full content control, so it sits at or above the former.
TagReference.create(): arbitrary file readgit/refs/tag.py:88 forwards **kwargs into git tag with no guard, and the signature advertises the passthrough:
def create(cls, repo, path, reference="HEAD", logmsg=None, force=False, **kwargs):
"""...
:param kwargs:
Additional keyword arguments to be passed to :manpage:`git-tag(1)`.
"""
git tag accepts -F <file> / --file=<file>, which reads the tag message from an arbitrary path. The annotated tag object stores that content and GitPython returns it to the caller via TagReference.tag.message, so the file contents come back in-band.
from git import Repo
from git.refs.tag import TagReference
t = TagReference.create(Repo("/path/to/repo"), "x", force=True, a=True, F="/etc/passwd")
print(t.tag.message)
Observed (poc/poc_tag_F.py), reading a canary file outside the repository:
[ALLOWED] no UnsafeOptionError raised
>>> tag message recovered from arbitrary path: 'TAG-READ-CANARY-98765\nsecond-line-secret'
Impact is a read at the privileges of the process. I am not claiming code execution for this instance. The signing options (-s, -u/--local-user) do invoke gpg from the same unguarded kwargs, but I did not develop that into command execution and make no claim about it.
Reported so the fix can be scoped once rather than per report. poc/sweep.py reproduces this list.
| Call site | git command | Assessment |
|---|---|---|
| IndexFile.from_tree() | read-tree | --index-output=<path> looked reachable but is neutralised: GitPython appends its own --index-output after the caller's kwargs and git honours the last occurrence. Verified — victim file unchanged (poc/poc_readtree.py) |
| IndexFile.remove() | rm | --pathspec-from-file only reads a pathspec; no write or disclosure primitive found |
| IndexFile.move() | mv | same |
| HEAD.reset() | reset | same |
| HEAD.checkout() | checkout | same |
| Head.delete(), RemoteReference.delete() | branch | no path-taking option found |
| Repo.merge_base() | merge-base | no path-taking option found |
| Repo._get_untracked_files() | status | no path-taking option found |
| Remote.set_url(), Remote.create(), Remote.update() | remote | URL handling already addressed by GHSA-94p4-4cq8-9g67 |
Immediate: add allow_unsafe_options: bool = False to both methods and gate Git._option_candidates(args, kwargs) against new lists — unsafe_git_checkout_index_options = ["--prefix"] (consider --temp) and unsafe_git_tag_options = ["--file", "-F"] (consider -s, -u/--local-user, --cleanup) — matching the pattern used in Repo.archive() and Commit.count().
Structural: this defect has now been fixed four times in four places (Repo.archive(), Git.ls_remote(), Commit.count(), and the two here), because the guard is opt-in per method: every new **kwargs-forwarding API starts unguarded and stays that way until someone reports it. Enforcing the check centrally in Git._call_process() — each git invocation consults a per-command unsafe-option table unless the caller opts out — would make new call sites safe by default rather than by review, and would close the remaining sites in the table above at the same time.
Reported privately via GitHub private vulnerability reporting.