CVE-2026-114145: 
Python vulnerability analysis and mitigation

CVE-2026-114145 is a remote code execution vulnerability in GitPython caused by incorrect validation ordering in the create_submodule() function. Affecting all versions prior to 3.2.1, the flaw allows an attacker-controlled submodule path (e.g., .git/hooks) to be cloned to disk before path validation rejects it, enabling a malicious Git hook to be planted and later executed. It was disclosed via GitHub Security Advisory GHSA-83vg-56qc-22m7 on October 14, 2026, and assigned a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, Red Hat CVE).

The root cause is an incorrect behavior order (CWE-696) combined with external control of file name or path (CWE-73). In git/objects/submodule/base.py, Submodule.add() calls _to_relative_path() — which only blocks out-of-tree paths — before invoking _clone_repo(), which writes the submodule to disk. The stricter _validate_repo_path() check in git/index/base.py runs only at index time, after the clone has already mutated the filesystem. In GitPython 3.1.x, _validate_repo_path() does not exist at all, so the call succeeds silently; in 3.2.0, the check raises ValueError but does not remove the already-planted hook file. An attacker supplying a path like .git/hooks can place an executable post-checkout file that Git will run on the next checkout operation (GitHub Advisory, Fix Commit).

Successful exploitation results in arbitrary code execution with the privileges of the process running GitPython, affecting confidentiality, integrity, and availability at a high level. Any service that derives a submodule checkout path from untrusted user input — such as one ingesting a submodule spec from a user-supplied manifest or API request — is at risk. On 3.2.0+, an application that catches the ValueError may incorrectly believe the unsafe path was blocked, while the hook is already planted and will execute on the next Git operation such as git checkout (GitHub Advisory).

No public proof-of-concept exploit code has been published and no in-the-wild exploitation has been reported as of the time of disclosure (Red Hat CVE). The EPSS score is 0.0, reflecting low current exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation requires two preconditions: the application must accept an attacker-influenced submodule path, and the target hook directory (e.g., .git/hooks) must be empty enough for Git to clone into — a condition common in minimal, CI, or container-based checkouts where default sample hooks are absent (GitHub Advisory).

1. Prepare a malicious submodule repository: Create a Git repository (evilsub/) whose root contains an executable file named post-checkout with the attacker's payload (e.g., a reverse shell script).
2. Identify a vulnerable target: Find an application using GitPython < 3.2.1 that accepts user-supplied submodule paths and passes them to create_submodule(). Confirm the target repository's .git/hooks directory is empty (no sample hooks present — typical of CI/container environments or repos initialized with an empty template directory).
3. Supply the malicious submodule path: Trigger the application to call create_submodule(name='x', path='.git/hooks', url='<path_or_URL_to_evilsub>'). On 3.1.x, this succeeds silently; on 3.2.0, a ValueError is raised but the clone has already written to disk.
4. Hook is planted: The file victim/.git/hooks/post-checkout now exists with mode 0755 and attacker-controlled content.
5. Trigger execution: Cause any Git checkout operation on the victim repository (e.g., git -C victim checkout <branch>). Git automatically executes .git/hooks/post-checkout, running the attacker's payload with the privileges of the Git process (GitHub Advisory).

• File System: Unexpected or newly created executable files in .git/hooks/ (e.g., post-checkout, pre-commit, post-merge) that were not placed there by the repository owner; presence of a .git/hooks/post-checkout file with unusual content or a recent modification timestamp coinciding with a submodule operation.
• File System: A new subdirectory cloned into .git/hooks/ containing a .git directory, indicating a Git repository was cloned into the hooks directory.
• Logs: Application logs showing a ValueError raised from git/index/base.py referencing _validate_repo_path during a create_submodule() call with a path containing .git — indicating a blocked but potentially already-executed plant on 3.2.0.
• Process: Unexpected child processes spawned by the Git process (e.g., bash, sh, python, curl, wget) immediately following a git checkout operation on the affected repository.
• Network: Outbound connections from the Git process or its children to unknown external hosts following a checkout operation (GitHub Advisory).

Upgrade GitPython to version 3.2.1 or later, which moves _validate_repo_path() to run before any filesystem mutation in _clone_repo() and _to_relative_path(), enforcing a validate-before-mutate invariant (GitPython Release, Fix Commit). If immediate patching is not possible, restrict applications from accepting untrusted submodule paths and destinations, particularly any path under .git/ directories. Additionally, ensure that hook directories contain the default sample hooks (e.g., by using a non-empty Git template directory), as Git will refuse to clone into a non-empty destination, preventing the hook plant (GitHub Advisory).

The vulnerability was submitted with AI assistance and published by GitPython maintainer Byron via GitHub Security Advisory GHSA-83vg-56qc-22m7 on October 14, 2026. The fix (PR #2264) was reviewed using GitHub Copilot and merged on October 2, 2026, ahead of the public advisory, with the maintainer noting the library's planned replacement with a CLI + Gix approach. Red Hat tracked the issue via Bugzilla (Bug #2558563) and published a CVE advisory (Red Hat CVE, GitHub PR).