fix(deps): update dependency gitpython to v3.1.57 [security]

[renovate]

This PR contains the following updates:

Package	Type	Update	Change	OpenSSF
gitpython	project.dependencies	patch	==3.1.55 → ==3.1.57

---

GitPython: Unguarded git option forwarding in IndexFile.checkout() and TagReference.create() enables arbitrary file overwrite and arbitrary file read

GHSA-3f7w-8rr8-f37f

More information

Details

Target: gitpython-developers/GitPython
Tested: HEAD 07e80555 (2026-07-25), latest release 3.1.55, git version 2.50.1
Reported instances: 2 exploitable, from a sweep of 14 unguarded call sites

Summary

GitPython blocks dangerous git options through Git.check_unsafe_options(), gated per method by an allow_unsafe_options parameter. That guard is applied per call site, so any API that forwards **kwargs into a git command without calling it passes caller-controlled options straight to git.

A mechanical sweep of every method that forwards **kwargs into a .git.<command>(...) call found 14 sites with no guard. Two reach a git option that takes a filesystem path:

#	Call site	git option	Impact
1	IndexFile.checkout() → git checkout-index	--prefix=<path>	arbitrary file overwrite with repository-controlled content
2	TagReference.create() → git tag	-F <file> / --file=<file>	arbitrary file read, returned in-band

This is the same defect class already fixed in Commit.count() (GHSA-p538-c434-8v24), Repo.archive() and Git.ls_remote() (GHSA-956x-8gvw-wg5v). Both instances below are still present at HEAD.

---

Instance 1 — IndexFile.checkout(): arbitrary file overwrite

git/index/base.py:1210 accepts **kwargs and forwards them with no guard:

def checkout(self, paths=None, force=False, fprogress=lambda *args: None, **kwargs):
    ...
    proc = self.repo.git.checkout_index(*args, **kwargs)   # line 1331
    ...
    proc = self.repo.git.checkout_index(args, **kwargs)    # line 1349

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.

Reproduction

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

Why this rates High

Both halves of the write are attacker-influenced:

• Destination — the prefix kwarg.
• Content — the bytes written are repository blobs, so anyone who can land a file in the repository (a pull-request branch, a mirrored or untrusted repository, an agent-cloned repository) controls exactly what is written.

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.

---

Instance 2 — TagReference.create(): arbitrary file read

git/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.

Reproduction

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.

---

Sweep results — the other 12 sites

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

Suggested remediation

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.

Disclosure

Reported privately via GitHub private vulnerability reporting.

Severity

• CVSS Score: 8.1 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H

References

• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-3f7w-8rr8-f37f
• https://github.com/gitpython-developers/GitPython/pull/2193
• https://github.com/gitpython-developers/GitPython/commit/3af0c2516c5e18c829da30338614688f6b69b49c
• https://github.com/gitpython-developers/GitPython/releases/tag/3.1.57
• https://github.com/advisories/GHSA-3f7w-8rr8-f37f

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

GitPython: Incomplete unsafe_git_archive_options denylist omits --add-file / --add-virtual-file, enabling arbitrary file read via Repo.archive()

GHSA-539m-9xh6-q6rr

More information

Details

Target: gitpython-developers/GitPython
Tested: HEAD 07e80555 (2026-07-25), latest release 3.1.55, git version 2.50.1

Summary

Repo.archive() does call the option guard, so this is not a missing-guard report. The guard is present and working; the denylist it consults is incomplete.

##### git/repo/base.py:169
unsafe_git_archive_options = [
    # Allows arbitrary command execution through the remote git-upload-archive command.
    "--exec",
    # Writes output to a caller-controlled filesystem path.
    "--output",
    "-o",
]

The comment on --output states the protected class in the project's own words: an option that lets the caller name a filesystem path is unsafe. --output is blocked because it writes to a caller-chosen path.

git archive also accepts --add-file=<path> and --add-virtual-file=<path:content> (both present in current git; verified against git version 2.50.1). --add-file reads a caller-chosen path — including an absolute path outside the repository — and places the bytes into the archive the caller receives. Neither option is in the list, and no other layer references them:

$ grep -rniE "add.file|add_file" git/
git/index/base.py:771:   R"""Add files from the working tree, ...      # unrelated docstring

Net effect: the guard blocks arbitrary file write at this sink while permitting arbitrary file read at the same sink.

Reachability proof (verified at the sink)

poc/poc_addfile.py at HEAD 07e80555. The PoC creates its own out-of-tree canary, so it runs from a clean machine:

-- CONTROL: options the denylist covers (expect BLOCKED) --
  [BLOCKED] output='/tmp/gp_written.tar': --output is not allowed, use `allow_unsafe_options=True` to allow it.
  [BLOCKED] o='/tmp/gp_written.tar': -o is not allowed, use `allow_unsafe_options=True` to allow it.
  [BLOCKED] exec='touch /tmp/gp_exec': --exec is not allowed, use `allow_unsafe_options=True` to allow it.

-- SIBLING OMITTED FROM THE DENYLIST: --add-file (expect ALLOWED) --
  [ALLOWED] add_file='/tmp/gp_canary.txt'  -> archive 10240 bytes
  archive members: ['f.txt', 'gp_canary.txt']
  >>> EXFILTRATED gp_canary.txt: 'secret-canary-12345'
  >>> byte-for-byte match with the out-of-tree file: CONFIRMED

-- also: --add-virtual-file (attacker-chosen name AND content) --
  [ALLOWED] add_virtual_file='pwn.txt:hello'  -> archive 10240 bytes

The three blocked lines are the control: they prove the guard is active on this call path, so the fourth result is a gap in list membership rather than a guard that never ran.

Minimal reproduction:

import io, tarfile
from git import Repo

buf = io.BytesIO()
Repo("/path/to/repo").archive(buf, format="tar", add_file="/etc/passwd")
print(tarfile.open(fileobj=io.BytesIO(buf.getvalue())).getnames())

##### ['<repo files>', 'passwd']   <- contents readable by whoever receives the archive

The canary is untracked and lives outside the repository; its contents are recovered from the returned archive and asserted byte-for-byte against the on-disk file. The option is rendered by transform_kwargs into --add-file=<path> and reaches git archive unmodified.

Direct precedent

GHSA-6p8h-3wgx-97gf (High, published 2026-07-22) is the same defect on the sibling list: "Incomplete unsafe_git_clone_options denylist omits --template" — an option absent from one of these denylists, reachable under the same caller-controlled-options precondition, accepted and fixed by adding it. git log shows the archive list itself has already been extended reactively once, in 701ce32f (fix: Guard unsafe git command options, GHSA-956x-8gvw-wg5v), and the --template omission was then fixed separately in ffcb5359.

--add-virtual-file is the same gap pointing the other way

--add-virtual-file=<path:content> lets the caller inject attacker-chosen content under an attacker-chosen name into an archive that downstream consumers will reasonably treat as repository-derived.

Suggested remediation

1. Preferred — allowlist. Repo.archive() has a small legitimate option surface (format, prefix, worktree_attributes, remote, compression level, plus paths). Accepting those and rejecting the rest means a future git release cannot add another path-taking option that silently reopens this.
2. Minimum — extend the list with --add-file and --add-virtual-file, and make the membership rule "the option takes a filesystem path or URL" rather than "the option executes a command". The existing comment on --output already implies that rule; applying it consistently is what closes the class instead of this instance.

Scope limits

• Impact is arbitrary file read at the privileges of the process. Not code execution — I make no such claim here.
• It requires the embedding application to forward caller-influenced kwargs into Repo.archive(). That is the identical precondition to --output, --exec and --template, all of which this project has treated as reportable.

Disclosure

Reported privately via GitHub private vulnerability reporting. Happy to test a candidate patch against the PoC. No public disclosure until you have shipped a fix and are ready.

Addendum (2026-07-25) — related observation on the same membership question, filed here rather than separately

While auditing the archive denylist, the same class of gap was identified in unsafe_git_clone_options. A second advisory is not being requested, as the issue is lower severity and should inform the fix for the issue above rather than require separate triage. Recording it here to provide the complete picture in one place.

Repo._clone() treats a URL's protocol as a security boundary and applies check_unsafe_protocols() to exactly one input:

clone_url = Git.polish_url(url, expand_vars=False)
if not allow_unsafe_protocols:
    Git.check_unsafe_protocols(clone_url)      # the positional url only

git clone accepts a second URL via --bundle-uri=<uri>, which git dereferences before the main transport runs. That option is absent from unsafe_git_clone_options, so the option guard passes it, and check_unsafe_protocols() never inspects it. A caller-influenced value therefore drives an outbound request from the host:

Repo.clone_from(trusted_url, dest,
                multi_options=["--bundle-uri=http://169.254.169.254/latest/meta-data/"])

##### no UnsafeProtocolError, no UnsafeOptionError

Confirmed against a local listener — the request leaves the process:

127.0.0.1 - - [24/Jul/2026 23:07:41] "GET /internal-metadata HTTP/1.1" 404 -

file:///path is likewise accepted without error. Note this is not a tokenisation bypass: multi_options is shlex.split before the check (per c9a26789 / GHSA-x2qx-6953-8485), so the fully-split --bundle-uri=... token is checked and legitimately passes because the option is not on the list.

Why it belongs with this report: both are the membership question rather than the matching logic — is the set of blocked options complete, and does the protocol guard inspect every URL git will dereference? The structural remediation proposed above covers both if extended slightly: prefer an allowlist per command, and route every URL-bearing option through check_unsafe_protocols(), not only the positional URL. Adding --bundle-uri to unsafe_git_clone_options would be the minimal fix.

Severity

• CVSS Score: 6.5 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

References

• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-539m-9xh6-q6rr
• https://github.com/gitpython-developers/GitPython/pull/2193
• https://github.com/gitpython-developers/GitPython/commit/7a4f5dcb7bf3cbcbf6e438017efcdfe0bc0d36ca
• https://github.com/gitpython-developers/GitPython/releases/tag/3.1.57
• https://github.com/advisories/GHSA-539m-9xh6-q6rr

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

GitPython: Arbitrary file truncation via git rev-list --output argument injection in unguarded Commit.count

GHSA-p538-c434-8v24

More information

Details

Summary

Commit.count() forwards **kwargs into rev_list with no check_unsafe_options guard (the guard exists only in the sibling iter_items, commit.py:341). git rev-list --output=<path> opens and truncates the target file to 0 bytes before revision parsing, so count(output='/victim') destroys/blanks an arbitrary file.

Root Cause

commit.py:290-291 calls self.repo.git.rev_list(self.hexsha, **kwargs) with no check_unsafe_options and no allow_unsafe_options parameter. The sibling iter_items (commit.py:341) is guarded; count is not. This is a distinct, uncovered sink — GHSA-956x-8gvw-wg5v fixed iter_commits/blame, not count.

Impact

Destroy/blank an arbitrary file at process privilege (integrity/availability). Reachability is key-control only (count uses self.hexsha, not a user ref), and the write is a 0-byte truncation (no content control), so MEDIUM.

Proof of Concept

commit.count(output='/path/to/victim')   # victim truncated to 0 bytes (verified)

##### control: commit.iter_commits(output=...) raises UnsafeOptionError

Attack Chain

1. Entry: app forwards user options -> commit.count(output='/victim'). Guard: none. Bypass proof: iter_commits(output=) raises UnsafeOptionError; count(output=) does not — verified side-by-side.
2. Sink: git rev-list <sha> --output=/victim -> file truncated to 0 bytes. Impact: destroy/blank arbitrary file.

Bypass Evidence

Live-verified on HEAD (tag 3.1.53): count(output=<victim>) truncated a pre-existing file to 0 bytes; guarded iter_commits(output=) raised UnsafeOptionError. Same CNA-accepted "app forwards user options dict" model as GHSA-956x-8gvw-wg5v's archive(**kwargs). Uncovered sink, not a duplicate.

Affected Versions

<= 3.1.53

Suggested Fix

Add check_unsafe_options to Commit.count (mirroring iter_items).

---

Reported by zx (Jace) — GitHub: @​manus-use

Severity

• CVSS Score: 5.4 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L

References

• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-p538-c434-8v24
• https://github.com/gitpython-developers/GitPython/pull/2184
• https://github.com/gitpython-developers/GitPython/commit/38553b6fddc7f6a667cdb45a6762343a08fc72b2
• https://github.com/gitpython-developers/GitPython/releases/tag/3.1.56
• https://github.com/advisories/GHSA-p538-c434-8v24

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

Release Notes

gitpython-developers/GitPython (gitpython)

v3.1.57: - Security and Fixes

Compare Source

What's Changed

• Merge gitdb and smmap into the GitPython repository by @​Byron in #​2179
• build(deps): bump actions/setup-python from 6 to 7 by @​dependabot[bot] in #​2185
• build(deps): bump the pre-commit group with 2 updates by @​dependabot[bot] in #​2186
• Bump Vampire/setup-wsl from 6.0.0 to 7.0.0 by @​dependabot[bot] in #​2124
• Render protected Traversable methods in the reference by @​pick7 in #​2192
• Use standard prefixes for parsed patch diffs by @​pick7 in #​2191
• Honor kill_after_timeout with output streams by @​pick7 in #​2189
• Redact Authorization extra headers from command errors by @​pick7 in #​2188
• Improve RemoteProgress parse return typing by @​pick7 in #​2187
• Adopt basedpyright with a legacy baseline by @​Byron in #​2194
• Block unsafe Git file and URL options by @​Byron in #​2193

New Contributors

• @​pick7 made their first contribution in #​2192

Full Changelog: gitpython-developers/GitPython@3.1.56...3.1.57

v3.1.56: - SECURITY

Compare Source

What's Changed

• Add support for Python 3.15 by @​hugovk in #​2183
• fix: reject unsafe output options in Commit.count by @​Byron in #​2184

Full Changelog: gitpython-developers/GitPython@3.1.55...3.1.56

---

Configuration

📅 Schedule: (in timezone Europe/Berlin)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.