Summary
GitPython validates a submodule's ".git" path only after cloning into it (RCE)
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 /.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 -> 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, andgit checkoutexecuted it. - 3.1.59: create_submodule returned with no error; .git/hooks/post-checkout was planted
and executed bygit 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 feedspath 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.
CVE-2026-114145 has a CVSS score of 7.5 (High). The vector is network-reachable, no privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (3.2.1); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is CVE-2026-114145? CVE-2026-114145 is a high-severity security vulnerability in Gitpython (pip), affecting versions <= 3.2.0. It is fixed in 3.2.1.
- How severe is CVE-2026-114145? CVE-2026-114145 has a CVSS score of 7.5 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of Gitpython are affected by CVE-2026-114145? Gitpython (pip) versions <= 3.2.0 is affected.
- Is there a fix for CVE-2026-114145? Yes. CVE-2026-114145 is fixed in 3.2.1. Upgrade to this version or later.
- Is CVE-2026-114145 exploitable, and should I be worried? Whether CVE-2026-114145 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-114145 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-114145? Upgrade
Gitpythonto 3.2.1 or later.