GHSA-v396-v7q4-x2qj

`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-executing options. The local PoC uses only a local bare Git repository and a local helper script. It does not contact any third-party service. Local reproduction: The PoC creates a disposable bare Git repository, a helper script, and a sentinel file path. It first confirms that the long `--upload-pack=<helper>` form is blocked by GitPython. It then calls `Repo.clone_from(..., multi_options=["-u<helper>"], allow_unsafe_options=False)`. Observed sanitized output: ```text gitpython_version=3.1.