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

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

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

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:

@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:

        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