GitPython Repo.archive() Arbitrary File Read via Incomplete Denylist

Vulnerability Overview Title: Incomplete unsafe_git_archive_options denylist omits --add-file / --add-virtual-file, enabling arbitrary file read via Repo.archive() Description: Target: Tested Versions: HEAD 07a89555 (2026-07-25), latest release 3.1.55, git version 2.50.1 Severity: Medium - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N (6.5) Summary: invokes option guards, so this is not a report of a missing guard. The guard exists and functions correctly; however, its denylist is incomplete. The comment indicates that is a protected class because it writes to a path chosen by the caller. is blocked because it writes to a path chosen by the caller. also accepts and (both validated in the current git, version 2.50.1). reads a path chosen by the caller—including absolute paths outside the repository—and injects bytes into the archive received by the caller. Neither of these options is in the list, nor are there other references to them. Proof of Concept (Verified at Sink): The POC creates its own out-of-tree canary, so it runs on a clean machine. The three blocked lines serve as controls: 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 was never triggered. Minimal Reproduction: Direct Precedent: GHSA-6p8h-3wp5-97gf (High, published 2026-07-22) is the same defect on a sibling list: “Incomplete unsafe_git_clone_options denylist omits --template” — an option present in these denylists, accepted under the same caller-controlled-options precondition, and fixed by adding it to git log. See the archive list itself has already been extended reactively once in 785ce32f (fix: Guard unsafe git command options, GHSA-956q-8gwp-wp6u), and the --template omission was then fixed separately in ff0cd359. --add-virtual-file is another path to the same issue: allows the caller to inject attacker-chosen content under an attacker-chosen name, which archive downstream consumers will reasonably consider repository-derived. I have demonstrated that this option is accepted (see POC output above). I have not developed a downstream trust exploitation, nor do I claim ownership of one. It falls under the same category. Scope of Impact Impact: Arbitrary file read, at process privileges. No code execution—I do not make such a claim. Preconditions: Requires the embedding application to forward caller-influenced kwargs to . This is the same precondition as for , , and , which the project has already treated as reportable. Undemonstrated: I have not demonstrated archive bytes reaching an unauthenticated participant without the caller choosing the return path, nor disclosure to whom the archive is received. Remediation Suggested Fixes: 1. Preferred — : There is a small surface of legitimate options ( , , , , ). Accepting those and rejecting the rest means future git releases cannot add another path-selection option that silently bypasses this. 2. Minimal — Extend the list with and , and make the membership rule “options accepting filesystem paths or URLs” rather than “options executing commands.” The existing comment implies this rule for ; applying it consistently is the intent of this class. Disclosure: Reported privately via GitHub Private Vulnerability Reporting. Willing to test candidate patches against the POC. No public disclosure until you send the fix and are ready. Appendix (2026-07-25) — Related observations regarding the same membership issue, submitted here rather than separately: While auditing the archive denylist, I found the same class of gap in . I do not request a second bounty—it is of lower severity, and I prefer to fix the above issue rather than consume a separate bounty. Recorded here so you have the whole picture in one place. treats the protocol of the URL as a security boundary and applies to exactly one input: accepts a second URL via , which git dereferences before the main transport runs. This option is missing from , so the option guard skips it, and never checks it. Caller-influenced values therefore derive outbound requests from the host: Confirmed against local listener—the request leaves the process: is similarly accepted without error. Note this is not tokenization bypass: is split by before checking (see GHSA-x2qp-9553-8465), so the full token is checked and passes legitimately because the option is not in the list. Scope limitations, stated clearly: - Blind SSRF Only: I confirmed requests reach the caller-chosen host, port, and path. I did not demonstrate response content returning to the caller; non-bundle responses cause git to warn and continue. - No Command Execution: I tested remote helper syntax ( ) and git rejected it (option 129). No marker files were created. I do not claim RCE. - Same Preconditions: As above: application forwarding caller-influenced options. - Why it belongs to this report: Both are membership issues rather than matching logic failures—is the set of blocked options doing guard checks per URL? Structural pro

Goal Reached Thanks to every supporter — we hit 100%!

GitPython Repo.archive() Arbitrary File Read via Incomplete Denylist

More from this source