GitPython CVE-2026-114145

Requires an application that passes an attacker-influenced submodule path (e.g. .git/hooks) into GitPython's create_submodule(), AND a clone destination empty enough for Git to clone into it - in practice meaning the default sample hooks are absent from .git/hooks. Exploitation further requires a later Git operation to perform a checkout so the planted post-checkout hook executes (UI:R). Limiting factors: the attack is gated by this non-default application behavior (accepting untrusted submodule paths) and the empty-hooks state, making it unsuitable against applications that validate submodule paths or against repos with standard sample hooks present; it is network-reachable and needs no attacker authentication (PR:N) against affected versions 3.1.x through 3.2.0-affected revisions, fixed in 3.2.1.

The CVSS 3.1 base score of 7.5 (HIGH) is driven by AV:N, PR:N and full C:H/I:H/A:H impact reflecting arbitrary code execution via a planted Git hook, but two metrics materially temper real-world risk: AC:H (the destination such as .git/hooks must be empty enough for Git to clone into it, which requires default sample hooks to be absent) and UI:R (a later Git operation must run to trigger the post-checkout hook). No EPSS score, KEV listing, or POC indicator was provided in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation - exploitation status is unproven, not disproven. SSVC-style reading: exploitation=none observed, technical impact=total (code execution), but automatable=likely NO because the attack depends on an application deliberately feeding untrusted submodule paths into create_submodule() plus a specific empty-hooks precondition. Net assessment: this is a legitimately serious code-execution bug in a popular library, but it is a conditional, usage-dependent issue rather than a broadly wormable internet-facing flaw - prioritize for applications that process untrusted repositories/submodules, de-prioritize elsewhere. The 'Information Disclosure' tag conflicts with the actual impact (code execution via hook), and the absence of EPSS/KEV/POC signals should be read as missing data, not as confirmation of low risk.

An attacker publishes or submits a malicious repository whose submodule configuration points the submodule path at .git/hooks, then induces a victim application that uses GitPython's create_submodule() to process it. Because _clone_repo() runs before the destination is safely rejected, Git clones attacker content into the hooks directory, planting an executable post-checkout hook that runs the next time a Git operation performs a checkout - yielding code execution in the victim's context. No public exploit was identified at time of analysis, and the high attack complexity (an empty .git/hooks with default sample hooks absent) plus required follow-on Git operation limit reliable exploitation.