CVE-2026-114145 in GitPython
Summary
by MITRE • 10/21/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/21/2026
GitPython serves as a widely adopted Python library facilitating programmatic interaction with Git repositories, enabling developers to automate version control tasks such as cloning, committing, and managing submodules within their applications. The vulnerability identified affects the create_submodule() function located in the git/objects/submodule/base.py module of versions prior to 3.2.1. This specific flaw arises from an improper validation sequence where the library accepts user-supplied submodule paths without sufficient sanitization before initiating repository operations. Specifically, when a developer provides a path that targets sensitive Git internal directories, such as .git/hooks, the library proceeds to invoke _clone_repo() immediately. In earlier versions like 3.1.x, this operation succeeds silently because the validation function _validate_repo_path is absent entirely. Even in later affected revisions including version 3.2.0 and subsequent updates up to but not including 3.2.1, while a check exists within git/index/base.py that eventually raises a ValueError upon detecting an invalid destination, this error occurs only after the clone operation has already written files to disk. Crucially, the library fails to perform any cleanup or removal of these planted files when the validation failure is triggered, leaving malicious artifacts on the filesystem despite the exception being raised.
The operational impact of this vulnerability centers on the potential for arbitrary code execution through Git hooks. By exploiting the race condition between file creation and validation, an attacker can force the library to clone a repository into a directory that serves as a hook location within another target repository. If the destination directory is empty or lacks default sample hooks, Git allows the cloning process to complete successfully from its perspective. Once the malicious submodule is cloned, it contains executable scripts in the post-checkout hook path. When any subsequent Git operation triggers these hooks on the affected system, such as a checkout command, the attacker-controlled code executes with the privileges of the user running the application. This effectively transforms a library function intended for legitimate repository management into an arbitrary code execution vector, allowing attackers to compromise the integrity and confidentiality of the host environment where the vulnerable Python application is deployed.
This vulnerability aligns with CWE-94 Improper Control of Generation of Code or Script Injection, as it involves injecting executable content via file system manipulation rather than direct input parsing. Furthermore, from a threat modeling perspective consistent with MITRE ATT&CK techniques, this behavior facilitates Command and Control execution through legitimate system utilities like Git hooks, allowing attackers to maintain persistence or escalate privileges without deploying traditional malware binaries that might trigger security alerts. The exploitation requires specific conditions: the application must accept untrusted submodule paths as input, and the target clone destination must be a directory where Git permits cloning into an empty space, typically meaning default hook samples are missing. This scenario is common in development environments or automated build systems where repositories are initialized fresh without standard boilerplate files.
Mitigation for this vulnerability requires immediate upgrading to version 3.2.1 of the GitPython library, which corrects the validation logic to ensure that dangerous paths are rejected before any file system operations occur and ensures proper cleanup if an error is detected during earlier stages. Applications relying on older versions should implement strict input validation at the application layer, ensuring that submodule paths do not contain sequences like .git/hooks or other sensitive Git internal directories. Additionally, developers should avoid using dynamic path construction for critical repository locations and instead rely on absolute, whitelisted paths where possible. Regular auditing of dependencies is essential to ensure that libraries interacting with version control systems are kept up-to-date against known vulnerabilities in their parsing and file handling routines.