Repository navigation
chore(deps): update dependency gitpython to v3.2.1 [security] - #31
Open
dependency-automation-app[bot] wants to merge 1 commit into
Open
dependency-automation-app[bot] wants to merge 1 commit into
dependency-automation-app[bot] wants to merge 1 commit into
Conversation
Contributor
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
3.1.60->3.2.1GitHub Vulnerability Alerts
GHSA-59cr-6r3x-644w
Affected:
GitPython3.1.61 (latest release) andmain—git/objects/submodule/base.py.git diff 3.1.61 origin/main -- git/objects/submodule/is empty, so both are identical here.The gap
The fix for
GHSA-hmq2-w58f-27jcaddedSubmodule._validated_name()and wired it intoupdate()and five siblings, closing the.gitmodulesname →.git/modules/<name>traversal. The other attacker-controlled.gitmodulesfield,path, is read raw:and GitPython's own containment guard is applied in only two of the places that consume it:
update()validates only the name and then uses the path-derived absolute location directly:So
path = ../../../tmp/escapedin an attacker-authored.gitmodulesselects the directory that gets created and, on the clone path, populated from the submodule URL. The same absolute location is whatforce_removehands toshutil.rmtree.The asymmetry is the argument: this is not a missing concept — the project wrote
_to_relative_path()precisely for this, andadd()/move()use it.update()does not.Honest limits (please read before rating)
Repo.clone_from(...)→repo.submodules→sm.update(init=True)re-derivespathfrom a canonical tree lookup, and real git refuses to check out a tree containing a..component, so an evil.gitmodulesnever lands in the working tree in the first place. A reachable trigger therefore requires the victim's code to name a non-HEAD commit (a historical-commit API such assubmodule_update(previous_commit=...)).update(), and the unguardedabspath→os.makedirs()flow at 3.1.61 ==main.Suggested fix
Apply the guard the project already has, wherever the path is consumed:
Better still, validate at the boundary: reject a
.gitmodulesentry whosepathis absolute or contains a..component when the section is first read in_set_cache_()/iter_items(), so no consumer can be added later without the check. A regression test withpath = ../escapedalongside the existingnametest would pin both fields.Prior art checked
GHSA-hmq2-w58f-27jc(this is a residual of its fix, in the sibling field, not a re-report) plus the repository's 30 published advisories — none mentions thepathfield or_to_relative_path. Searched issues and PRs for_to_relative_path,gitmodules pathandsubmodule traversal: no report of this.Credit
kta1kri.
Appendix —
EVIDENCE_gitpython_path_unguarded_20260901.txt(inlined; advisories accept no attachments)CVE-2026-114145
Summary
create_submodule(name, path, url)clones a submodule into the repo's own.gitdirectory before it rejects the path. A
pathof ".git/hooks" is accepted by thepre-clone check, so the submodule is cloned straight into the live hooks directory,
and a file named
post-checkoutin the submodule becomes an executable.git/hooks/post-checkout. On 3.2.0+ the later index check does raiseValueError,but only after the clone already wrote to disk, and it does not remove the planted
hook; on 3.1.x there is no such check and the call succeeds silently. Either way the
hook runs on the next git operation (e.g. checkout), giving code execution.
Details
The checkout path is validated too late, after the clone has already mutated disk.
This breaks the "validate before mutation" invariant that commit 43a43cd8 ("Validate
submodule checkout and metadata paths before mutation") set out to enforce.
Submodule.add() calls the permissive path check before cloning, and the strict check
only reaches the ".git" alias at index time, after _clone_repo has written to disk:
git/objects/submodule/base.py (Submodule.add)
599: path = cls._to_relative_path(repo, path) # accepts ".git/hooks"
673: mrepo = cls._clone_repo(repo, url, path, name, ...) # clones into /.git/hooks
714: index.add([sm], write=True) # strict check only triggers here
git/index/base.py (IndexFile._preprocess_add_items)
732: _validate_repo_path(entry.path) # rejects ".git", too late
_to_relative_path only blocks
../absolute/out-of-tree paths;.gitaliases arerejected only by _validate_repo_path, which was added in 3.2.0 (commit a75aedf3) and
runs at the index boundary. The ValueError it raises at line 732 does not roll back
what _clone_repo already wrote.
Version-dependent behavior:
hook is already on disk and is not removed (incorrect order of validation vs. clone).
not reject
.git; create_submodule(path=".git/hooks", ...) returns with no error atall and the hook is planted silently.
Proof of concept
Setup:
evilsub/ : a git repo whose ROOT contains an executable file named post-checkout (the payload)
victim/ : a git repo with at least 1 commit and a second branch, whose .git/hooks has NO
sample hooks (the state of a minimal/CI checkout, or
git initwith an emptytemplate dir, or GIT_TEMPLATE_DIR/init.templateDir empty)
import git, os.path as osp
try:
git.Repo("victim").create_submodule(name="x", path=".git/hooks", url=osp.abspath("evilsub"))
except ValueError:
pass # 3.2.0+: ".git" is rejected, but only AFTER the clone, so the plant already happened.
# 3.1.x: no exception is raised at all; the call succeeds and still plants the hook.
victim/.git/hooks/post-checkout now exists, mode 0755, attacker-controlled, on every
affected version. Any later checkout runs it:
git -C victim checkout -> the hook runs -> code execution
Verified live:
git/index/base.py:732, yet .git/hooks/post-checkout was present and executable, and
git checkoutexecuted it.and executed by
git checkout.Impact
Arbitrary code execution. A library/app that creates a submodule from an
attacker-influenced
pathends up with an attacker-controlled executable in.git/hooks, which git runs on ordinary later operations. This affects any servicethat derives a submodule checkout path from untrusted data, e.g. one that ingests a
submodule spec (name/path/url) from a user-supplied manifest or API request and feeds
pathinto create_submodule. On 3.2.0+ the library's own validation is the thing thatfails: it correctly rejects the
.gitpath, but only after the submodule has alreadybeen cloned into place, so an app that traps the ValueError reasonably believes the
unsafe path was blocked.
Preconditions (hence AC:H): (1) the app passes an attacker-influenced submodule
path;(2) the target hook name is free in
.git/hooks, true for minimal/CI/containercheckouts and whenever init.templateDir/GIT_TEMPLATE_DIR is empty. With the default
sample hooks present,
git clonerefuses the non-empty destination and no plant occurs.Affected: all tested versions from 3.1.x (3.1.59) through the current tip bda18e08
(3.2.0 + 3 commits). 3.1.x plants silently; 3.2.0+ plants despite raising ValueError.
Configuration
📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Renovate Bot.