GitPython EUVD-2026-57792

Two concurrent conditions are required. First, the attacker must have sufficient access to influence the template keyword argument or an equivalent --template entry in multi_options passed to Repo.clone_from() - this implies at least low-privilege access to the application interface that triggers clone operations (PR:L). Second, the attacker must be able to stage a directory containing a chmod +x executable post-checkout hook that the git process can read at clone time; the advisory notes this is realistic via shared filesystems, world-writable paths like /tmp, application upload directories, or attacker-writable network-mounted paths (AT:P). Exploitation operates in the default allow_unsafe_options=False configuration - the denylist bypass is the sole required condition within GitPython itself. Exploitation is limited by: the need for filesystem-reachable hook staging (network-only attackers without local or shared filesystem access cannot satisfy AT:P); the requirement for argument influence (not exploitable by targets who call clone_from() with fully internal, non-user-derived options); and the PR:L requirement (unauthenticated external callers who cannot reach clone argument paths are not affected).

The CVSS 4.0 score of 7.7 with AC:H and AT:P accurately reflects the dual precondition: the attacker must both control clone arguments (PR:L) and stage a reachable hook directory. These modifiers appropriately temper what would otherwise be a near-critical impact triple (VC:H/VI:H/VA:H). EPSS data is absent from the provided intelligence - exploitation probability cannot be quantified. No CISA KEV listing is present, so mass exploitation is not confirmed. However, a live-verified POC against the latest release at disclosure (3.1.53) significantly elevates real-world risk: the barrier to weaponization is low for any application that forwards user-supplied metadata to clone_from(). Highest-risk deployments are CI/CD pipelines, git hosting platforms, code analysis services, and developer automation tools that accept external repository inputs. The absence of KEV listing and the AC:H/AT:P conditions suggest targeted rather than opportunistic exploitation at this stage, but the confirmed POC and the ubiquity of GitPython in Python-based DevOps tooling make patching urgent.

An attacker targeting a CI/CD service backed by GitPython stages an executable post-checkout hook (e.g., a reverse shell or credential harvester) in a world-readable directory such as /tmp/evil/hooks/post-checkout. The attacker then submits a repository job or API request that causes the service to call Repo.clone_from(url, dest, template='/tmp/evil') - achievable wherever the application forwards user-controlled repository metadata to clone arguments. Git copies the hook directory into the new repository and executes post-checkout during checkout, running arbitrary OS commands under the service's process identity. A proof-of-concept demonstrating this exact chain has been publicly disclosed and live-verified against GitPython 3.1.53.