GitPython CVE-2026-42284

Exploitation requires the target application to call GitPython's Repo.clone_from() or Submodule.update() methods with the multi_options or clone_multi_options parameter derived from attacker-controlled input. This typically occurs in repository management platforms, CI/CD systems, documentation generators, or Git hosting services that allow users to specify custom clone options or repository configurations. The vulnerability is NOT exploitable against applications that hardcode multi_options or sanitize input to reject strings containing whitespace or special characters. Network access (AV:N) means the attacker can trigger the vulnerability remotely via HTTP API, web form, or service interface without local system access. High attack complexity (AC:H) reflects the requirement to control specific function parameters - not all GitPython usage is vulnerable, only code paths that accept external multi_options. No authentication (PR:N) or user interaction (UI:N) is required once the vulnerable code path is reached, making automated exploitation feasible against exposed endpoints. The attack succeeds on default GitPython configurations without requiring non-standard features or settings.

Real-world risk is moderate-to-high for applications that pass untrusted input to GitPython's clone operations. CVSS 8.1 (AV:N/AC:H/PR:N/UI:N) indicates network-exploitable without authentication but with high attack complexity - the attacker must control multi_options arguments passed to Repo.clone_from() or Submodule.update(), which typically requires the application to accept user-supplied repository URLs or clone options. Public exploit code exists (GitHub advisory GHSA-x2qx-6953-8485 includes working PoC), lowering the barrier for exploitation. However, EPSS score and KEV status are not available at time of analysis, suggesting no confirmed widespread or automated exploitation campaigns. The scope is unchanged (S:U), meaning impact is limited to the GitPython process context, but full confidentiality/integrity/availability compromise is possible via arbitrary code execution through malicious hooks. Priority depends on whether your application exposes multi_options to external input - most defensive uses of GitPython with hardcoded clone parameters are not vulnerable. Organizations using GitPython in web APIs, CI/CD pipelines, or repository management platforms with user-supplied clone options should prioritize remediation immediately.

An attacker identifies a web application that clones Git repositories based on user-supplied URLs and clone options (e.g., a CI/CD platform, documentation builder, or code review tool). The attacker crafts a malicious multi_options parameter: ['--branch main --config core.hooksPath=/tmp/evil']. The application passes this to GitPython's Repo.clone_from(), which validates the string as starting with '--branch' and allows it. After shlex.split, Git receives '--config core.hooksPath=/tmp/evil' as a separate argument, configures the hooks path, and executes the attacker's post-checkout hook during clone, achieving remote code execution in the application server context with full access to confidential data, integrity modification capabilities, and potential lateral movement to infrastructure.