GHSA-w8jc-g24h-crhw CVE-2026-110857

GitPython command wrappers omit unsafe protocol and option checks

High PyPI

Severity: 7.7 / 10; High · CVSS 4.0
Exploit chance (EPSS): 0.42%; Chance of exploitation in the next 30 days. Higher than 35.98% of scored vulnerabilities.
Known exploited: No; Not in CISA's catalog
Weakness: CWE-1287 Improper Validation of Specified Type of Input
Fix: 3.2.0; Upgrade gitpython to this version or later

Description

Summary

GitPython has spent 2022-2026 rolling out two reusable guards method-by-method: Git.check_unsafe_protocols(url) (raises UnsafeProtocolError for <transport>:: remote-helper URLs - CVE-2022-24439) and Git.check_unsafe_options(...) (raises UnsafeOptionError for denylisted option spellings - CVE-2023-40267, CVE-2026-42215, CVE-2026-67323). Three wrapper methods that build a git argv from caller-controlled values still have neither:

Git.ls_remote (git/cmd.py:1128-1143) - checks options (:1139-1141) but forwards the URL positional unchecked; no allow_unsafe_protocols parameter exists. The same URL through clone_from raises UnsafeProtocolError.
Repo.merge_base (git/repo/base.py:895-936) - forwards **kwargs/*rev to self.git.merge_base with no guard; guarded sibling iter_commits sits 12 lines up. Its exception handler additionally swallows every non-128 GitCommandError into [], masking the injection.
IndexFile.move (git/index/base.py:1092-1168) - forwards **kwargs to git mv twice (:1147, :1167); guarded sibling remove() is 23 lines above.

Verified unfixed on main @ a54d159 (2026-09-21), post-dating latest release 3.1.62 (2026-09-07) - all three sites re-verified today.

Impact

Site 1 (ls_remote) - RCE conditional on the victim git transport policy. The common 'probe first, then clone' pattern (Git(...).ls_remote(attacker_url)) with an ext::sh -c ... URL executes arbitrary commands when the victim git permits the ext transport: dynamically verified with protocol.ext.allow=always (marker executed). git >= 2.38.1 stock config refuses the transport (fatal: transport 'ext' not allowed, rc 128) - GitPython adds no defense-in-depth and surfaces a bare GitCommandError. Environments on git < 2.38.1 are exposed with stock config - the exact population CVE-2022-24439 was scored against.

Sites 2/3 - latent argument-injection surface: caller kwargs flow 1:1 into the git argv before operands and -- (cmd.py:1850 opt_args + ext_args), and execute_kwargs (incl. shell=True/env - the CVE-2023-40267 Windows mechanism) passes through unguarded. Today git merge-base/git mv expose no exec option, so we claim the missing-guard class (vendor-settled by CVE-2026-67323, which bundled archive/ls_remote/iter_commits/blame in one advisory), not direct RCE.

Dynamic verification (today; GitPython main @ a54d159, git 2.55.0, Linux)

#	Call	Result
T1	`repo.git.ls_remote('ext::/tmp/gp_touch.sh')`, stock config	git refuses (rc 128); no `UnsafeProtocolError` from GitPython
T1b	same + victim config `protocol.ext.allow=always`	marker created - arbitrary command executed
T2	`repo.git.ls_remote('.', upload_pack=...)`	blocked by cmd.py:1141 (options-side fixed - protocol-side is the residual gap)
T3	`repo.merge_base('main','side', upload_pack=...)`	not blocked; argv `git merge-base --upload-pack=... main side`; rc 129 silently converted to `[]`
T4	`repo.index.move(['f1','f2'], output=...)`	not blocked; option reaches `git mv` (rc 129)

Coverage matrix (main @ a54d159)

check_unsafe_protocols: 7 call sites (_clone, archive, set_url, create, fetch, pull, push) - none on ls_remote. check_unsafe_options: 24 call sites incl. ls_remote, iter_commits, IndexFile.remove - absent on merge_base and move.

Precedents (same repo, same guard family)

CVE-2022-24439 / GHSA-hcpj-qp55-gfph (critical): check_unsafe_protocols on the clone path - Site 1 is the same ext:: primitive on a sibling API.
CVE-2023-40267 / GHSA-pr76-5cm5-w9cj (critical, 'incomplete fix for CVE-2022-24439'): check_unsafe_options - unguarded kwargs to argv treated as RCE (shell=True on Windows).
CVE-2026-42215 / GHSA-rpm5-65cw-6hj4 (high, fixed 3.1.47): underscored-spelling bypass - rollout still active in 2026.
CVE-2026-67323 / GHSA-956x-8gvw-wg5v (high, 8.4, fixed 3.1.51): added check_unsafe_options to archive/ls_remote/iter_commits/blame; its PoC is literally repo.git.ls_remote('.', upload_pack=...). Establishes that a wrapper missing the check is itself a vulnerability. This report is the residual gap of that rollout: ls_remote got options but not protocols; merge_base/move got neither.

Recommended fix (existing helpers, 1-3 lines per site)

Git.ls_remote: if not allow_unsafe_protocols: self.check_unsafe_protocols(args[0]) + new allow_unsafe_protocols: bool = False (the _clone pattern, base.py:1536-1538).
Repo.merge_base: check_unsafe_options(Git._option_candidates(list(rev), kwargs), unsafe_options=self.unsafe_git_revision_options) (the iter_commits pattern); stop masking non-128 statuses.
IndexFile.move: the remove() pattern with unsafe_git_pathspec_from_file_options.

One advisory, three affected methods, severity anchored on Site 1 - mirroring CVE-2026-67323's bundling.

Affected versions

PyPI

Package	Vulnerable	Fixed in
gitpython	`< 3.2.0`	`3.2.0`

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

gitpython PyPI → `3.2.0`

pip

pip install --upgrade "gitpython>=3.2.0"

poetry

poetry add "gitpython>=3.2.0"

uv

uv add "gitpython>=3.2.0"

Severity breakdown

CVSS 4.0 7.7

CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Attack vector: Network
Attack complexity: High
Attack requirements: Present
Privileges required: None
User interaction: Passive
Confidentiality (vulnerable system): High
Integrity (vulnerable system): High
Availability (vulnerable system): High
Confidentiality (subsequent systems): None
Integrity (subsequent systems): None
Availability (subsequent systems): None
Exploit maturity: Not defined
Scope: X

CVSS 3.1 7.5

CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H

Attack vector: Network
Attack complexity: High
Privileges required: None
User interaction: Required
Scope: Unchanged
Confidentiality: High
Integrity: High
Availability: High

Weakness

CWE-1287: Improper Validation of Specified Type of Input

The product receives input that is expected to be of a certain type, but it does not validate or incorrectly validates that the input is actually of the expected type.

How to prevent it

Implementation: Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

References

Packages

github.com/gitpython-developers/GitPython

Timeline

Oct 14, 2026 Published
Oct 27, 2026 Last updated by the source
Nov 1, 2026 Latest EPSS score

Advisory	Severity	Why it's related
GHSA-83vg-56qc-22m7 GitPython validates a submodule's ".git" path only after cloning into it (RCE)	High	Also affects gitpython
GHSA-gq48-pqfc-9p58 GitPython: Submodule.move() follows an attacker-committed intermediate symlink outside the worktree	Medium	Also affects gitpython
GHSA-23mf-xhv8-69c2 GitPython: arbitrary file read via attacker-controlled branch name in `Head.checkout()` (incomplete fix of CVE-2026-78679)	High	Also affects gitpython
GHSA-f9j4-qggq-h239 GitPython Remote.pull() refspec bypasses the --upload-pack unsafe-option guard, enabling arbitrary command execution	Critical	Also affects gitpython
GHSA-m64x-33q8-m5h7 GitPython parse_actor_and_date() is vulnerable to quadratic backtracking on malformed identity lines	High	Also affects gitpython
GHSA-fx3j-rwgx-fr94 GitPython: separate_git_dir leaks env vars via crafted .gitmodules submodule name	High	Also affects gitpython
GHSA-59cr-6r3x-644w GitPython submodule update path traversal can write outside the repository	Medium	Also affects gitpython
GHSA-g5vv-9gxw-82hx GitPython: Denial of Service via catastrophic backtracking (ReDoS) in Actor.name_email_regex — commit author/committer field parsing	High	Also affects gitpython

Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor