GitPython CVE-2026-110857

Exploitation requires a consuming application to pass an attacker-controlled remote URL into GitPython's Git.ls_remote (or the similarly unguarded merge_base and IndexFile.move option-injection paths). The decisive prerequisite is that the underlying Git permits the ext transport (protocol.ext.allow), which modern Git disables by default - so the attack succeeds mainly where this has been relaxed or where the application passes untrusted URLs in a context Git treats as user-initiated. Limiting factors: attacker cannot exploit without the application accepting external URLs (UI:P / AT:P), the ext helper must be allowed by Git config, and the flaw is fixed in GitPython 3.2.0. Not exploitable against a default Git configuration that blocks the ext protocol.

This is a moderate-to-serious priority driven by impact rather than ease of exploitation. The CVSS 4.0 vector (AV:N, AC:H, AT:P, PR:N, UI:P, VC:H/VI:H/VA:H) scores 7.7 and shows that while no authentication is required and full triad impact is achievable (code execution), exploitation is gated by High attack complexity, a Present attack requirement (AT:P), and passive user/application interaction (UI:P). The critical real-world limiter is that the ext:: remote-helper transport must be permitted by Git - modern Git disables this by default (protocol.ext.allow=user), so default-configured environments are not exploitable without a non-default setting or an application that explicitly enables it. No EPSS score, CISA KEV listing, or public POC is present in the provided data, so there is no evidence of active exploitation; exploitation status is 'no public exploit identified at time of analysis.' The signals are internally consistent - high technical impact but constrained prerequisites - meaning this should be patched on a normal-to-expedited cadence rather than treated as an emergency, with priority raised for any deployment that passes untrusted URLs into GitPython or has relaxed Git protocol settings. The CWE-1287 (improper input validation) classification aligns with the root cause: Git.ls_remote forwarding URLs without check_unsafe_protocols validation.

An application using GitPython (e.g., a CI/CD runner, repo-indexing service, or web app) accepts a remote repository URL from an untrusted user and passes it to Git.ls_remote (or merge_base / IndexFile.move). The attacker submits an 'ext::sh -c <command>' style URL; because ls_remote skips check_unsafe_protocols validation, GitPython hands it to Git, which executes the attacker's command if the ext transport is permitted. No public exploit code is identified at time of analysis, but the technique is well-understood and the attack requires the victim application to process the malicious URL (UI:P).