GHSA-539m-9xh6-q6rr: Infoleak

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.

python git/repo/base.py:169 unsafegitarchiveoptions = [ # 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|addfile" 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/pocaddfile.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/gpwritten.tar': --output is not allowed, use allowunsafeoptions=True to allow it. [BLOCKED] o='/tmp/gpwritten.tar': -o is not allowed, use allowunsafeoptions=True to allow it. [BLOCKED] exec='touch /tmp/gpexec': --exec is not allowed, use allowunsafeoptions=True to allow it.

-- SIBLING OMITTED FROM THE DENYLIST: --add-file (expect ALLOWED) -- [ALLOWED] addfile='/tmp/gpcanary.txt' -> archive 10240 bytes archive members: ['f.txt', 'gpcanary.txt'] >>> EXFILTRATED gpcanary.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] addvirtualfile='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:

python import io, tarfile from git import Repo

buf = io.BytesIO() Repo("/path/to/repo").archive(buf, format="tar", addfile="/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 transformkwargs 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 unsafegitcloneoptions 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, worktreeattributes, 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 unsafegitcloneoptions. 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 checkunsafeprotocols() to exactly one input:

python cloneurl = Git.polishurl(url, expandvars=False) if not allowunsafeprotocols: Git.checkunsafeprotocols(cloneurl) # 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 unsafegitcloneoptions, so the option guard passes it, and checkunsafeprotocols() never inspects it. A caller-influenced value therefore drives an outbound request from the host:

python Repo.clonefrom(trustedurl, dest, multioptions=["--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: multioptions 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 checkunsafeprotocols(), not only the positional URL. Adding --bundle-uri to unsafegitcloneoptions would be the minimal fix.