---
id: "CVE-2026-114145"
kind: "vulnerability"
aliases: ["CVE-2026-114145", "GHSA-83vg-56qc-22m7"]
title: "GitPython validates a submodule's \".git\" path only after cloning into it (RCE)"
severity: "high"
cvss: 7.5
epss: 0.002630000002682209
exploited: false
status: "open"
category: "package"
products: [{"name": "Gitpython", "fixed": ["3.2.1"], "affected": "<= 3.2.0", "ecosystem": "pypi"}]
ecosystems: ["pypi"]
tags: ["ci", "cwe-696", "gitpython", "package", "python", "self-hosted"]
not_affected_if: ["default-config", "no-untrusted-submodule-paths", "static-export"]
published_at: "2026-10-21T21:17:57+00:00"
first_seen_at: "2026-10-23T19:11:31+00:00"
updated_at: "2026-10-23T21:57:29+00:00"
sources: [{"source": "ghsa", "url": "https://github.com/advisories/GHSA-83vg-56qc-22m7", "first_seen_at": "2026-10-23T19:11:31+00:00"}, {"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-114145", "first_seen_at": "2026-10-23T21:57:29+00:00"}]
---

# GitPython validates a submodule's ".git" path only after cloning into it (RCE)

GitPython's create_submodule clones a submodule into the repo's .git/hooks directory when given a path like .git/hooks before its path check rejects it, so the cloned post-checkout file becomes an executable hook. An attacker who controls the submodule path can get code execution the next time git runs a checkout in that repo.

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

## Affected

- pypi:Gitpython affected <= 3.2.0 fixed 3.2.1

## How to check

Run pip show GitPython and check whether the version is 3.2.0 or lower, or 3.1.x.
Find code that passes a user-supplied or API-supplied value as the path argument to create_submodule or Submodule.add.
Look for an unexpected executable file in .git/hooks, such as post-checkout, in repos that handle submodules.

## Fix

Upgrade GitPython to 3.2.1 or later (pip install -U GitPython).
Do not pass untrusted values as submodule paths until upgraded; the fixed version is listed as 3.2.1 in the sources.

## Timeline

- 2026-10-23T19:11:31+00:00 ghsa https://github.com/advisories/GHSA-83vg-56qc-22m7
- 2026-10-23T21:57:29+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-114145

## From the sources

### Summary


`create_submodule(name, path, url)` clones a submodule into the repo's own `.git`
directory before it rejects the path. A `path` of ".git/hooks" is accepted by the
pre-clone check, so the submodule is cloned straight into the live hooks directory,
and a file named `post-checkout` in the submodule becomes an executable
`.git/hooks/post-checkout`. On 3.2.0+ the later index check does raise `ValueError`,
but only after the clone already wrote to disk, and it does not remove the planted
hook; on 3.1.x there is no such check and the call succeeds silently. Either way the
hook runs on the next git operation (e.g. checkout), giving code execution.

### Details


The checkout path is validated too late, after the clone has already mutated disk.
This breaks the "validate before mutation" invariant that commit 43a43cd8 ("Validate
submodule checkout and metadata paths before mutation") set out to enforce.

Submodule.add() calls the permissive path check before cloning, and the strict check
only reaches the ".git" alias at index time, after _clone_repo has written to disk:

git/objects/submodule/base.py (Submodule.add)
  599: path = cls._to_relative_path(repo, path)           # accepts ".git/hooks"
  673: mrepo = cls._clone_repo(repo, url, path, name, ...) # clones into <worktree>/.git/hooks
  714: index.add([sm], write=True)                         # strict check only triggers here

git/index/base.py (IndexFile._preprocess_add_items)
  732: _validate_repo_path(entry.path)                     # rejects ".git", too late

_to_relative_path only blocks `..`/absolute/out-of-tree paths; `.git` aliases are
rejected only by _validate_repo_path, which was added in 3.2.0 (commit a75aedf3) and
runs at the index boundary. The ValueError it raises at line 732 does not roll back
what _clone_repo already wrote.

Version-dependent behavior:
- 3.2.0 .. tip bda18e08: _validate_repo_path raises ValueError at index.add, but the
  hook is already on disk and is not removed (incorrect order of validation vs. clone).
- 3.1.x (e.g. 3.1.59): _validate_repo_path does not exist and _to_relative_path does
  not reject `.git`; create_submodule(path=".git/hooks", ...) returns with no error at
  all and the hook is planted silently.

### Proof of concept


Setup:
  evilsub/ : a git repo whose ROOT contains an executable file named post-checkout (the payload)
  victim/  : a git repo with at least 1 commit and a second branch, whose .git/hooks has NO
             sample hooks (the state of a minimal/CI checkout, or `git init` with an empty
             template dir, or GIT_TEMPLATE_DIR/init.templateDir empty)

import git, os.path as osp
try:
    git.Repo("victim").create_submodule(name="x", path=".git/hooks", url=osp.abspath("evilsub"))
except ValueError:
    pass   # 3.2.0+: ".git" is rejected, but only AFTER the clone, so the plant already happened.
           # 3.1.x: no exception is raised at all; the call succeeds and still plants the hook.

#### victim/.git/hooks/post-checkout now exists, mode 0755, attacker-controlled, on every
#### affected version. Any later checkout runs it:
####  git -C victim checkout <other-branch>   ->   the hook runs   ->   code execution

Verified live:
- tip bda18e08 (3.2.0 + 3 commits): create_submodule raised ValueError from
  git/index/base.py:732, yet .git/hooks/post-checkout was present and executable, and
  `git checkout` executed it.
- 3.1.59: create_submodule returned with no error; .git/hooks/post-checkout was planted
  and executed by `git checkout`.

### Impact

Arbitrary code execution. A library/app that creates a submodule from an
attacker-influenced `path` ends up with an attacker-controlled executable in
`.git/hooks`, which git runs on ordinary later operations. This affects any service
that derives a submodule checkout path from untrusted data, e.g. one that ingests a
submodule spec (name/path/url) from a user-supplied manifest or API request and feeds
`path` into create_submodule. On 3.2.0+ the library's own validation is the thing that
fails: it correctly rejects the `.git` path, but only after the submodule has already
been cloned into place, so an app that traps the ValueError reasonably believes the
unsafe path was blocked.

Preconditions (hence AC:H): (1) the app passes an attacker-influenced submodule `path`;
(2) the target hook name is free in `.git/hooks`, true for minimal/CI/container
checkouts and whenever init.templateDir/GIT_TEMPLATE_DIR is empty. With the default
sample hooks present, `git clone` refuses the non-empty destination and no plant occurs.

Affected: all tested versions from 3.1.x (3.1.59) through the current tip bda18e08
(3.2.0 + 3 commits). 3.1.x plants silently; 3.2.0+ plants despite raising ValueError.

---

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