CVE-2026-76222 in GitPython
Summary
by MITRE • 08/19/2026
GitPython before 3.1.58 fails to validate submodule names from .gitmodules files, allowing attackers to create Git repositories at arbitrary filesystem paths outside the intended clone directory. Attackers can craft malicious repositories with traversal sequences in submodule names that GitPython processes during submodule initialization, creating attacker-controlled Git repositories at escaped filesystem locations.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/19/2026
The vulnerability identified in versions of GitPython prior to 3.1.58 represents a critical path traversal and arbitrary file write flaw rooted in the insufficient validation of input data derived from .gitmodules configuration files. When GitPython processes a repository containing submodules, it reads the submodule definitions which specify URLs and paths for nested repositories. The core technical failure lies in the library's handling of these path specifications during the initialization phase. Specifically, the software fails to sanitize or validate the submodule name field against directory traversal sequences such as dot-dot-slash patterns. This oversight allows an attacker who controls a remote repository to embed maliciously crafted submodule entries that reference filesystem paths outside the intended clone root directory.
During the operational execution of GitPython commands like clone or update, the library attempts to initialize these submodules by creating local directories and initializing git repositories at the specified locations. Because the path validation is absent, the underlying file system operations interpret relative traversal sequences literally rather than restricting them to the project's working tree. Consequently, if a malicious repository specifies a submodule with a name like ../../etc or similar deep traversal strings, GitPython will create a new .git directory and associated metadata files at that arbitrary location on the host machine. This effectively results in an unauthorized creation of git repositories outside the sandboxed environment of the cloned project, bypassing standard security boundaries designed to keep repository data contained within its designated root.
The operational impact of this vulnerability is severe, particularly for applications or automated systems that process untrusted source code repositories. An attacker can leverage this flaw to write files into sensitive system directories if the execution context possesses sufficient permissions. This could lead to privilege escalation, persistence mechanisms through the placement of malicious scripts in standard startup locations, or corruption of critical configuration files located outside the application's working directory. Furthermore, because git repository structures contain metadata that can influence subsequent operations, an attacker might manipulate how other tools interpret these rogue repositories if they are later accessed by legitimate processes with higher trust levels. This constitutes a significant risk to system integrity and confidentiality, as it allows for arbitrary file creation which is often a precursor to more complex exploitation chains such as remote code execution or denial of service through resource exhaustion in critical paths.
From a classification perspective, this vulnerability aligns closely with CWE-22 Improper Limitation of a Pathname to a Restricted Directory, commonly known as path traversal. It also relates to CWE-78 Improper Neutralization of Special Elements used in an OS Command if the subsequent operations involve shell execution, though the primary issue is file system manipulation. In terms of adversary tactics, this behavior maps to ATT&CK technique T1564 Hidden Files and Directories, as it allows for the creation of files outside expected locations that may evade standard directory listings or security monitoring focused on specific application roots. It also touches upon T1037 Command Line Interface which could be leveraged if the created repositories are used to execute further commands via git hooks or similar mechanisms depending on system configuration.
To mitigate this vulnerability, organizations must immediately upgrade GitPython to version 3.1.58 or later where these validation checks have been implemented and hardened. For environments that cannot update immediately due to dependency constraints, it is crucial to implement strict input sanitization at the application layer before passing any submodule configurations to the library. This includes validating all path strings against a whitelist of allowed characters and ensuring they do not contain traversal sequences or absolute paths outside the expected base directory. Additionally, running applications with minimal file system privileges can reduce the impact by preventing writes to sensitive system directories even if the traversal succeeds. Security teams should also audit existing codebases for direct usage of GitPython submodule features involving untrusted sources and apply defensive programming practices that assume all external input is malicious until proven otherwise through rigorous validation routines.