Affected: Homebrew: btcli
`GitPython` version `3.1.50` blocks unsafe `git clone` options such as `--upload-pack`, `-u`, `--config`, and `-c` unless callers explicitly pass `allow_unsafe_options=True`. However, the default unsafe-option gate does not recognize joined short-option forms such as `-u/path/to/helper`.
Git itself accepts `-u<upload-pack>` as the short form of `--upload-pack=<upload-pack>`. As a result, `Repo.clone_from(..., multi_options=["-u<helper>"], allow_unsafe_options=False)` can execute the helper command even though the equivalent long option is blocked.
Affected package:
- Ecosystem: PyPI - Package: `GitPython` - Confirmed affected version: `3.1.50` - Repository: `gitpython-developers/GitPython` - Current PyPI version during triage: `3.1.50`
Relevant behavior:
- `Repo.unsafe_git_clone_options` correctly lists `--upload-pack`, `-u`, `--config`, and `-c` as unsafe clone options. - `Repo._clone()` splits `multi_options` with `shlex.split(" ".join(multi_options))` and then calls `Git.check_unsafe_options(...)`. - `_canonicalize_option_name("-u/path/to/helper")` returns a string beginning with `u...`, not the canonical short option `u`, so it does not match the blocked `-u` entry. - Git accepts the same joined short option as `--upload-pack=<helper>` and executes the helper during clone.
Preconditions:
An application must pass attacker-influenced clone options into `Repo.clone_from(..., multi_options=...)` while relying on GitPython's default unsafe-option gate to block command-…
GitPython 3.1.50 fails to recognize joined short-option forms such as -u<value> (the short form of --upload-pack=<value>) when enforcing its default unsafe-option gate. When an application passes attacker-influenced clone options into Repo.clone_from(..., multi_options=..., allow_unsafe_options=False), an attacker can supply -u<helper> to bypass the gate that blocks --upload-pack/-u, causing Git to execute the specified helper command during clone. Fixed in 3.1.51.
Affected: openEuler:24.03-LTS-SP4: python-GitPython
GitPython is a python library used to interact with git repositories, high-level like git-porcelain, or low-level like git-plumbing. Security Fix(es):
GitPython before 3.1.52 is vulnerable to environment-variable exfiltration in Repo.clone_from(). The caller-supplied remote URL is passed through Git.polish_url(), which on non-Cygwin platforms calls os.path.expandvars() on the URL before invoking git clone. An attacker who controls the clone URL can embed $NAME or ${NAME} tokens that are expanded to the values of the hosting process's environment variables (e.g., AWS_SECRET_ACCESS_KEY or GITHUB_TOKEN). The resulting URL, now containing the secret, is transmitted over the network to an attacker-controlled host during the clone attempt, disclosing the secret.(CVE-2026-67322)
GitPython before 3.1.51 fails to guard against dangerous Git options passed as keyword arguments in Repo.archive() and git.ls_remote(), allowing command injection via options such as --exec/--upload-pack (leading to arbitrary command execution). Additionally, Repo.iter_commits() and Repo.blame() do not check for leading-dash revision arguments, so a revision like --output=<path> can cause Git to open and truncate an arbitrary file. Exploitation requires an application that passes attacker-controlled arguments to these methods.(CVE-2026-67323)
GitPython 3.1.50 fails to recognize joined short-option forms such as -u<value> (the short form of --upload-pack=<value>) when enforcing i…
Affected: PyPI: gitpython
GitPython 3.1.50 fails to recognize joined short-option forms such as -u<value> (the short form of --upload-pack=<value>) when enforcing its default unsafe-option gate. When an application passes attacker-influenced clone options into Repo.clone_from(..., multi_options=..., allow_unsafe_options=False), an attacker can supply -u<helper> to bypass the gate that blocks --upload-pack/-u, causing Git to execute the specified helper command during clone. Fixed in 3.1.51.
django: Django: Remote code execution via GeoDjango spatial lookups aiohttp: AIOHTTP: Arbitrary code execution via untrusted input to CookieJar.load() JWCrypto: python-cryptography: python: JWCrypto: Memory exhaustion via crafted compressed JWE tokens tmp: path Traversal via unsanitized prefix/postfix enables directory escape awxkit: path traversal via YAML !include directive pyasn1: pyasn1: Denial of Service via crafted ASN.1 REAL values gitpython: GitPython: Environment variable exfiltration via attacker-controlled clone URL gitpython: GitPython: Arbitrary code execution via command injection due to unguarded Git options gitpython: GitPython: Arbitrary Code Execution via Joined Short Options Bypass gitpython: GitPython: Command Injection via Git option prefix abbreviation aiohttp: AIOHTTP: HTTP Request Smuggling via WebSocket Upgrade aiohttp: AIOHTTP: Denial of Service via malformed HTTP responses awx: project archive extraction allows path traversal file writes awx: webhook status callback SSRF leaks the Git PAT awx: notification backends allow SSRF and credential leakage gitpython: GitPython: Arbitrary file overwrite and read via unsafe git option forwarding GitPython: GitPython: Arbitrary file read via TagReference.create()
Affected: Ubuntu:Pro:14.04:LTS: python-git, Ubuntu:Pro:16.04:LTS: python-git, Ubuntu:Pro:18.04:LTS: python-git, Ubuntu:Pro:20.04:LTS: python-git, Ubuntu:Pro:22.04:LTS: python-git, Ubuntu:Pro:24.04:LTS: python-git, Ubuntu:Pro:26.04:LTS: python-git
GitPython 3.1.50 fails to recognize joined short-option forms such as -u<value> (the short form of --upload-pack=<value>) when enforcing its default unsafe-option gate. When an application passes attacker-influenced clone options into Repo.clone_from(..., multi_options=..., allow_unsafe_options=False), an attacker can supply -u<helper> to bypass the gate that blocks --upload-pack/-u, causing Git to execute the specified helper command during clone. Fixed in 3.1.51.