CVE-2026-100689
MediumCVSS 5.9Exploitation Probability (EPSS)
Low risk32th percentile - higher than 32% of all known CVEs
Summary
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 cause directories to be created via os.makedirs() outside the repository working tree, populated from the submodule URL, and removed via shutil.rmtree() when force_remove is used. Fixed in GitPython 3.1.62.
Risk Assessment
Applications that update submodules at a non-HEAD commit (such as a historical-commit API) may allow an attacker to create and remove directories outside the repository. The common clone-then-update flow is not affected because it re-derives the path from a canonical tree lookup.
Recommendation
Upgrade GitPython to version 3.1.62 or later. Avoid updating submodules at non-HEAD commits based on untrusted .gitmodules files.
Other vulnerabilities in GitPython
See all- CVE-2026-44244High
GitPython is a Python library used to interact with Git repositories. In versions prior to 3.1.49, the GitConfigParser.set_value() method did not validate values for newlines, allowing for the injection of malicious paths into Git configuration.
- CVE-2026-44243High
GitPython is a Python library used to interact with Git repositories. Prior to version 3.1.48, a vulnerability allowed attackers to manipulate files outside the repository's .git directory due to insufficient validation of reference paths.
- CVE-2026-42284High
GitPython is a Python library used to interact with Git repositories. In versions prior to 3.1.47, the _clone() function improperly validates multi_options, allowing malicious hooks to be executed during repository cloning.
- CVE-2026-42215High
GitPython is a Python library used to interact with Git repositories. From version 3.1.30 to before version 3.1.47, the library blocks dangerous Git options, but equivalent Python kwargs can bypass that check, leading to arbitrary command execution.
- CVE-2026-78676Critical
GitPython before 3.1.59 fails to safely re-serialize multi-line git-config values during write operations, potentially turning dormant quoted values into active directives like core.hooksPath. Attackers can craft config files with embedded newlines that become live after any GitPython config write, enabling arbitrary code execution.
- CVE-2026-67324Critical
GitPython 3.1.50 fails to recognize joined short-option forms such as -u<value> (the short form of --upload-pack=<value>) when enforcing its default unsafe-option gate. When an application passes attacker-influenced clone options into Repo.clone_from(..., multi_options=..., allow_unsafe_options=False), an attacker can supply -u<helper> to bypass the gate that blocks --upload-pack/-u, causing Git to execute the specified helper command during clone. Fixed in 3.1.51.
- CVE-2023-40267Critical
GitPython before 3.1.32 does not block insecure non-multi options in clone and clone_from. This issue exists because of an incomplete fix for CVE-2022-24439.
- CVE-2026-87819High
GitPython before 3.1.60 contains a regular expression denial of service vulnerability in Actor.name_email_regex that processes commit author and committer fields. Attackers can craft a commit object with a malformed author field containing an unterminated angle bracket to cause quadratic backtracking, exhausting CPU resources for over two minutes per commit access.
- CVE-2026-87818Medium
GitPython 3.1.59 fails to restrict the --no-index option in the high-level diff API, allowing attackers to read arbitrary filesystem paths as repository operands. Attackers can combine --no-index with -I/--ignore-matching-lines to create a content-dependent Boolean oracle, repeatedly querying local files to recover single-line secrets through distinguishable success or error responses.
- CVE-2026-87817High
GitPython before 3.1.60 fails to properly validate the git directory location, allowing attackers to impersonate the git directory using tracked files like gitdir, commondir, and HEAD. Attackers can execute arbitrary code by placing a malicious pre-commit hook in the tracked hooks directory that executes when a victim calls index.commit() on a cloned or opened repository.
Original NVD description (English source)
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.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS