CVE-2026-100689
GitPython before 3.1.62 does not validate the `path` field read from an untrusted .gitmodules file…
- Risk score
- 42/100
- CVSS
- 5.9 v3.1
- Exploit chance (30 days)
- 0.4%
- Published
- 26 Sep 2026
Open in the live forecast Today's forecast
What to know
- What it is
- 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 m…
- Affected
- See advisory
- Fix
- Upgrade the product to 3.1.62 or later.
- Exploitation
- No known exploitation
Why it is Yellow
- CVSS 5.9 medium
References
Original 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.
Last activity 26 Sep 2026. Patch Forecast updates every hour.