CVE-2026-114145

High · 7.5

CVSS

7.5

EPSS

0.4%

Published

Oct 21, 2026

CISA due date

—

Cloudanix analysis

Monitor only SSVC: Track

A flaw in a popular Python library for working with Git repositories lets attackers plant hidden code that runs automatically when developers or build systems later use Git.

Exploitation: Requires User Interaction
Attacker needs: User Interaction
Complexity: High
Impact: Remote Code Execution
Component: Library
Class: Path Traversal
Remediation: Upgrade
Effort: Medium
Patch risk: Low

What it actually does

create_submodule accepts an attacker-controlled path such as .git/hooks, clones into it before validation, and leaves an executable hook on disk that Git will later run.

Why it matters to the business

Attackers can gain code execution inside any application that uses the library to clone repositories containing untrusted submodules, potentially leading to full compromise of developer or CI systems.

How an attack unfolds

An attacker supplies a malicious submodule path pointing at .git/hooks to an application using GitPython. The library clones the attacker-controlled content into that location before rejecting the path, planting a post-checkout hook. A subsequent Git operation executed by the victim triggers the hook and runs attacker code.

How to fix it

Upgrade GitPython to version 3.2.1 or later. Applications that must remain on older releases should avoid passing untrusted submodule paths and should validate destination directories against .git before any clone.

How to confirm the fix worked

Confirm the installed GitPython version is 3.2.1 or newer; re-test create_submodule calls with paths that previously succeeded to verify they now raise an error before writing files.

Typical attack path

Identify an application that accepts untrusted submodule URLs or paths and passes them to GitPython create_submodule
Craft a submodule whose path resolves to .git/hooks (or another writable Git hook directory) and whose repository contains an executable hook
Trigger the vulnerable clone path so the hook is written to disk
Wait for or induce a later Git operation that executes hooks, achieving code execution

How to detect it

Review application logs for create_submodule calls or Git clone operations that target paths containing .git/hooks; inspect cloned repositories for unexpected executable files inside .git/hooks; correlate with subsequent process execution originating from those hook locations.

What your security team should do

Immediately upgrade all GitPython installations to 3.2.1
Inventory code and dependencies that invoke create_submodule or clone with untrusted input
Add runtime checks that reject submodule paths containing .git or other protected directories
Monitor EPSS trend and watch for public exploits given the five-day publication window

The record

GitPython is a python library used to interact with Git repositories. Prior to 3.2.1, create_submodule() in git/objects/submodule/base.py accepts an attacker-influenced submodule path such as .git/hooks and invokes _clone_repo() before safely rejecting the destination. In 3.1.x, _validate_repo_path() does not exist and the call succeeds silently, while in 3.2.0 and later affected revisions the check in git/index/base.py raises ValueError only after the clone has written to disk and does not remove the planted file. An attacker-controlled submodule can therefore place an executable post-checkout hook that a later Git operation executes. Exploitation requires an application to accept an untrusted submodule path and a clone destination such as .git/hooks that is empty enough for Git to clone into it, which commonly means that default sample hooks are absent. This issue is fixed in version 3.2.1.

Affected packages

Ecosystem	Package	Introduced	Fixed