Description

GitPython before 3.1.62 does not validate the `path` field read from an untrusted .gitmodules file when updating submodules. While a prior fix (GHSA-hmq2-w58f-27jc) added Submodule._validated_name() to constrain the `name` field, and GitPython's own containment guard Submodule._to_relative_path() is applied in add() and move(), Submodule.update() derives the absolute checkout location from the raw `path` value without that guard. A .gitmodules entry containing directory traversal components (e.g., path = ../../../tmp/escaped) can therefore cause directories to be created via os.makedirs() outside the repository working tree, populated from the submodule URL on the clone path, and removed via shutil.rmtree() when force_remove is used. Exploitation requires an application flow that updates submodules at a non-HEAD commit (such as a historical-commit API); the common clone-then-update flow re-derives the path from a canonical tree lookup and is not affected. The issue is fixed in GitPython 3.1.62.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.9",
  "pubDate": "2026-09-26T14:16:53.420Z",
  "pubdate": "2026-09-26T14:16:53.420Z",
  "executiveSummary": "GitPython versions prior to 3.1.62 are susceptible to a directory traversal vulnerability originating from improper validation of the 'path' field within untrusted .gitmodules files.\nThis vulnerability allows an attacker to achieve arbitrary directory creation, population, and deletion outside of the intended repository working tree by crafting malicious submodule paths (e.g., ../../../).\nThe flaw manifests specifically during submodule update operations where the 'path' attribute is processed without the necessary containment guards that are otherwise present in submodule addition or movement routines.\nThe risk is elevated for applications that perform submodule updates at non-HEAD commits, such as those providing historical-commit access via an API.\nSuccessful exploitation could lead to unauthorized file system modifications, including the potential for overwriting critical system files or performing remote code execution through the placement of malicious artifacts.\nThe impact is constrained to the context of the process running GitPython; however, it represents a significant security risk for CI/CD pipelines, build systems, or web services that automate Git repository management.\nUsers are strongly advised to update to GitPython 3.1.62 or later to incorporate the necessary input validation logic.",
  "technicalDetails": "The root cause of this vulnerability lies in the insufficient input sanitization within the Submodule.update() function of GitPython. While previous security patches, such as the one addressing GHSA-hmq2-w58f-27jc, introduced Submodule._validated_name() to restrict the 'name' field, the 'path' field remained inadequately constrained during the update process.\nIn standard operation, GitPython utilizes the Submodule._to_relative_path() method as a containment guard when performing submodule add() or move() operations, ensuring that the target directory remains within the repository boundary. However, Submodule.update() fails to invoke this or an equivalent guard, deriving the absolute checkout location directly from the raw 'path' string provided in the .gitmodules file.\nAn attacker can exploit this by crafting a repository containing a .gitmodules file where the 'path' configuration includes directory traversal sequences. When an application invokes Submodule.update() on such a repository, the underlying os.makedirs() call uses the unsanitized traversal path. Consequently, GitPython attempts to create or populate directories relative to the working directory but outside of the intended sandbox.\nThe exploitation flow specifically requires an application flow that triggers submodule updates at non-HEAD commits, such as historical-commit API endpoints. This is because the standard clone-then-update flow typically re-derives the submodule path from a canonical tree lookup, which mitigates the impact of the raw .gitmodules content. In non-standard update flows, the raw data is trusted implicitly.\nOnce the directory traversal is achieved, the impact is two-fold. First, os.makedirs() allows for the creation of directories at arbitrary locations on the host file system. Second, when the force_remove option is enabled during these update operations, the library may trigger shutil.rmtree() on the manipulated path. An attacker can leverage this primitive to facilitate unauthorized deletion of system files or, alternatively, write attacker-controlled content from the submodule URL into sensitive locations on the disk.\nThe vulnerability affects all versions of GitPython prior to 3.1.62. Since this flaw does not rely on specific authentication or privilege requirements beyond the capability to trigger a submodule update, it poses a direct threat to any automated system that interacts with untrusted Git repositories."
}