GitPython computes the on-disk location of a submodule's separate Git directory based on the submodule name from the .gitmodules file without validation. An attacker can craft a malicious repository with a submodule name containing directory traversal sequences (e.g., ../../../../some/path) that cause GitPython to create and initialize a full Git repository outside the intended clone directory when submodules are initialized via sm.update(init=True). This vulnerability arises because GitPython's implementation does not normalize or validate the submodule name, unlike core Git which blocks this attack class (CVE-2018-11235). The vulnerability affects GitPython versions before 3.1.58 and requires the victim to clone and initialize submodules from a malicious repository.

An attacker who controls a repository that a victim clones and initializes submodules for using GitPython can cause arbitrary creation and initialization of Git repositories at attacker-chosen filesystem paths outside the intended working directory. This can lead to unauthorized file system modifications and potential interference with other repositories or system files. The vulnerability does not directly disclose data or escalate privileges but allows integrity impact by creating repositories in unintended locations.

A patch is available in GitPython version 3.1.58 that addresses this vulnerability by validating submodule names to prevent directory traversal. Users should upgrade to GitPython 3.1.58 or later. Until upgraded, avoid cloning and initializing submodules from untrusted repositories using GitPython. Core Git itself is not affected as it already blocks this attack class. No additional mitigations are indicated by the vendor advisory.