Executive brief
GitPython's `Repo.clone_from()` and `Repo.clone()` methods accept a `separate_git_dir` parameter that should be blocked as unsafe by default, but it is missing from the denylist. This allows attackers who control clone arguments to create a git repository's metadata directory (containing executable hooks) at any attacker-chosen filesystem path outside the intended destination, potentially corrupting other repositories or enabling arbitrary code execution.
Technical details
GitPython's clone methods forward keyword arguments to underlying `git clone` invocations after checking them against a denylist (`Repo.unsafe_git_clone_options`). The `--separate-git-dir` option redirects the entire `.git` metadata directory (including executable hooks) to an arbitrary caller-controlled path, leaving only a gitlink file at the destination. This option is already correctly blocked by `Repo.unsafe_git_init_options` for `Repo.init()` and is documented as unsafe in the `clone_from()` docstring, but it is absent from `unsafe_git_clone_options`. An attacker who can control a `separate_git_dir` kwarg passed to `clone_from()` or `clone()` can create a git directory structure at any path the process has write permission to, potentially overwriting existing repositories or infrastructure and escalating to hook-based RCE. The vulnerability requires the host application to forward untrusted input into the clone method's kwargs without additional validation, which matches the threat model already accepted for other sibling denylist entries like `--template` and `--config`.
Affected products
- GitPython GitPython <= 3.1.58
Timeline
- 2026-09-08: disclosed: Public disclosure via GitHub Advisory Database
- 2026-09-08: patched: Fix available in GitPython 3.1.59