---
id: "GHSA-23mf-xhv8-69c2"
kind: "vulnerability"
aliases: ["GHSA-23mf-xhv8-69c2"]
title: "GitPython: arbitrary file read via attacker-controlled branch name in `Head.checkout()` (incomplete fix of CVE-2026-78679)"
severity: "high"
cvss: null
epss: null
exploited: false
status: "open"
category: "package"
products: [{"name": "GitPython", "fixed": ["3.2.0"], "affected": "<= 3.1.62", "ecosystem": "pypi"}]
ecosystems: ["pypi"]
tags: ["ci", "cwe-200", "cwe-73", "cwe-88", "gitpython", "package", "python", "repo-import"]
not_affected_if: ["no-checkout-call", "no-untrusted-clones"]
published_at: "2026-10-27T15:28:03+00:00"
first_seen_at: "2026-10-27T15:28:57+00:00"
updated_at: "2026-10-27T15:29:24+00:00"
sources: [{"source": "ghsa", "url": "https://github.com/advisories/GHSA-23mf-xhv8-69c2", "first_seen_at": "2026-10-27T15:28:57+00:00"}]
---

# GitPython: arbitrary file read via attacker-controlled branch name in `Head.checkout()` (incomplete fix of CVE-2026-78679)

GitPython's Head.checkout() passes the branch name to git checkout without a '--' separator, so a repository whose default branch is named like '--pathspec-from-file=/path' makes the consumer's git call read that file. The file contents come back inside the exception message, which a caller may log or show.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- pypi:GitPython affected <= 3.1.62 fixed 3.2.0

## How to check

- Run `pip show GitPython` and confirm the version is `3.1.62` or older.
- Search application code for `active_branch.checkout(` or `Head.checkout(` on repos cloned from user-supplied URLs.

## Fix

- Upgrade GitPython to `3.2.0`.
- Until upgraded, avoid calling `checkout()` on branches of repositories cloned from untrusted URLs.

## Timeline

- 2026-10-27T15:28:57+00:00 ghsa https://github.com/advisories/GHSA-23mf-xhv8-69c2

## From the sources

> **A note on the referenced files.** This report was submitted through GitHub's private
> vulnerability reporting API, which carries no attachments. Every transcript this report leans
> on is reproduced **inline above**, verbatim. The file names it mentions (`poc.sh`, `poc.log`,
> per-case transcripts, `evidence.md`, `negative-controls.md`, blob-sweep tables) are the local
> evidence bundle those inline excerpts were extracted from, with a checksum manifest. I am happy
> to send the bundle by any channel you prefer, or to open a private fork — just say which. The
> PoC scripts are self-contained and reproduce the result from a clean environment.

---

**Affected:** `<= 3.1.62` — all published releases; also `main` @ `4905b4af`
**Verified at runtime:** GitPython `3.1.62` with git `2.55.0`
**Date:** 2026-09-10
**Reporter:** MAXI8594

---

## Threat model

| | |
|---|---|
| **Attacker** | anyone who can get the application to clone a URL they control. No account, no credential, no privilege in the consuming application. |
| **Pre-need** | a repository they host, with `HEAD` pointing at a branch whose name is the payload. A `git push` to a plain git server is enough — no filesystem access to a server is required (`raw/06`). |
| **Gets** | the contents of any file the application's process can read, returned in band through the exception. `/etc/passwd` recovered 34 of 34 lines. |
| **Real-world likelihood** | **High.** The vulnerable consumer is six lines of ordinary code with no unusual configuration: `Repo.clone_from(user_url)` then `repo.active_branch.checkout()`. `allow_unsafe_options=False` is the default. Cloning user-supplied URLs is the library's central use case — CI systems, repository importers, scanners and bots. |

**On severity relative to the sibling advisories.** GitHub, as CNA, scored the three prior
advisories in this class at 6.5 / `PR:L` (CVE-2026-76217, CVE-2026-78678, CVE-2026-78679). This
report asks for 7.5 / `PR:N`, and the difference is one measured fact: in those three, the
application had to pass an attacker-influenced value into the API. Here it passes nothing — the
clone materialises the hostile branch on its own and `repo.active_branch` returns it
(`raw/02`). If that reading is not accepted, the `PR:L` path via `Repo.create_head()` is also real
and lands at 6.5, matching the siblings.

## Summary

`Head.checkout()` guards its `**kwargs` against unsafe Git options but never inspects its own
positional argument — the branch name — which reaches the `git checkout` argv with no `--`
separator. A repository whose default branch is named `--pathspec-from-file=/etc/passwd` makes a
consumer that merely clones it and checks out the default branch return the entire contents of that
file to the caller.

This is the exact combination of two advisories the project already fixed:

- **CVE-2026-76217** (`GHSA-hh9p-6wh2-4mfc`) — *"Arbitrary file read via `--pathspec-from-file` in
  `IndexFile.remove()` **and `Head.checkout()`**"*. Fixed in 3.1.58 by commit `f2550b65`, which added
  the guard to this exact method — but only for `**kwargs`.
- **CVE-2026-78679** (`GHSA-3wxw-xv34-2frg`) — *"`TagReference.create` positional reference
  bypasses kwargs-only `--file` guard, enabling arbitrary file read (incomplete fix of 3af0c251)"*. Fixed in 3.1.59 by commit `1b0d2d9b`, which applied the
  positional check to `git/refs/tag.py`, `git/diff.py`, `git/index/base.py` and `git/repo/base.py` —
  but not to `git/refs/head.py:286`.

`f2550b65` states in its own commit message that the audit found the positional variant and applied
it to `HEAD.reset` — 185 lines above `Head.checkout`, in the same file, in the same commit:

> "The audit also found that **reset's positional commit could carry the option before its argument
> separator**. […] **Check reset's positional commit as well as keyword options**"

`HEAD.reset` got the fix. `Head.checkout` did not, and `1b0d2d9b` did not come back for it.

## Affected Asset

| | |
|---|---|
| Package | `GitPython` (PyPI) |
| Affected versions | **`<= 3.1.62`** — all published releases |
| Latest release tested | `3.1.62` |
| Also present on | `main` @ `4905b4af` |
| Vulnerable file | `git/refs/head.py` |
| Guard | line 286 — `Git._option_candidates([], kwargs)` |
| Sink | line 293 — `self.repo.git.checkout(self, **kwargs)` |
| CWE | CWE-88 (Argument Injection), CWE-73 (External Control of File Name or Path), CWE-200 (Exposure of Sensitive Information) |
| CVSS 3.1 | `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N` → **7.5 High** |

The version range was established by **blob hash against every tag**, not by dates: the sink line
`self.repo.git.checkout(self, **kwargs)` — with no `--` separator — is present in `git/refs/head.py`
in every tag from `0.3.1-beta2` through `3.1.62`. The `3.1.62` blob is byte-identical to `main`:
`7f563374ef9e018b3d5f95054498e8591e112ce2`. Full sweep in `raw/07-blob-version-sweep.txt`.

The kwargs-only guard first appears in **3.1.58**, so `3.1.58`–`3.1.62` is where "incomplete fix"
applies; earlier releases have the same sink with no guard at all.

## Vulnerability Details

### Root cause

`git/cmd.py:1045` — `_option_candidates()` only inspects the positionals it is handed:

```python
@classmethod
def _option_candidates(cls, args: Sequence[Any] = (), kwargs: Optional[Mapping[str, Any]] = None) -> List[str]:
    """Collect possible option spellings before command-line transformation."""
    options = [
        option for option in cls._unpack_args([arg for arg in args if arg is not None]) if option.startswith("-")
    ]
```

So `_option_candidates([], kwargs)` means: *check the keyword arguments, never check the positional
arguments this method puts on the command line.* That is fine when the method has no
attacker-influenced positional, or when it separates them with `--`.

`git/refs/head.py:283-293` — `Head.checkout()` has neither:

```python
        if not allow_unsafe_options:
            Git.check_unsafe_options(
                options=Git._option_candidates([], kwargs),
                unsafe_options=Git.unsafe_git_pathspec_from_file_options,
            )
        kwargs["f"] = force
        if kwargs["f"] is False:
            kwargs.pop("f")

        self.repo.git.checkout(self, **kwargs)
```

`self` is the only positional. It serialises to the branch name, lands in the `git checkout` argv,
and is not in the list the guard inspects. `_call_process` builds `args_list = opt_args + ext_args`,
so keyword-derived options precede positionals — which is why the rest of the library puts `"--"`
first (`Remote.fetch/pull/push`, `Repo._clone`, `Repo.archive`, `IndexFile.remove`, `Commit.count`
all do). `Head.checkout` does not.

### Why the branch name is attacker-controlled

Git accepts a refname whose branch component begins with `-` and contains `/`
(`raw/02-refname-accepted-and-cloned.txt`):

```
>>> git check-ref-format 'refs/heads/--pathspec-from-file=/etc/passwd'
    exit=0  stderr=''
    => un refname que empieza con '-' y lleva '/' es VALIDO para git

>>> git -C <bare> update-ref 'refs/heads/--pathspec-from-file=/etc/passwd' beea87239099
    exit=0  stderr=''
>>> git -C <bare> symbolic-ref HEAD 'refs/heads/--pathspec-from-file=/etc/passwd'
    exit=0
    HEAD del bare = refs/heads/--pathspec-from-file=/etc/passwd
    ref en disco como arbol jerarquico: True

>>> Repo.clone_from('file://<bare>', <victim>)   # la app solo clona
    ramas LOCALES creadas por el clone, sin que nadie las pida:
      refs/heads/--pathspec-from-file=/etc/passwd
    repo.active_branch.name = '--pathspec-from-file=/etc/passwd'
    coincide con el nombre hostil: True
```

The transcript above also shows the second half: `git clone` **materialises that branch locally on
its own** when the remote `HEAD` points at it — the consuming application never asks for it.

A plain git server accepts the refname over `receive-pack`, with no `--force` and no special config
(`raw/06-push-accepts-refname.txt`), so the attacker does no

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_