GitPython EUVD-2026-62463

Exploitation requires two conditions to be met sequentially: first, the victim must clone an attacker-controlled Git repository using GitPython (versions <= 3.1.57); second, the victim or an automated process must call submodule_update(init=True) or sm.update(init=True) on that repository, which is the specific API invocation that triggers the unvalidated path construction. Passive cloning alone does not trigger the vulnerability. These conditions are commonly satisfied in automated CI/CD pipelines that process pull requests or mirror external repositories, since submodule initialization is a standard and often default workflow step. Exploitation is limited by: (1) the UI:P interaction requirement meaning a human or automated system must actively trigger submodule initialization; (2) the attacker needing advance knowledge of target filesystem paths to maximize impact, though arbitrary directory creation is harmful even without guaranteed target knowledge; (3) write permissions at the traversed path - if the target path is owned by a different user or is read-only, directory creation will fail with a permissions error. No special network configuration, authentication bypass, or non-default GitPython settings are required beyond the submodule initialization step itself.

The CVSS 4.0 score of 8.4 reflects high real-world concern: network-reachable delivery (AV:N), low attack complexity (AC:L), no required privileges (PR:N), and passive user interaction (UI:P), with high integrity impact on both the vulnerable system (VI:H) and subsequent filesystem locations (SI:H). The interaction requirement is the primary limiting factor in raw score terms, but in practice submodule initialization is a routine, frequently automated step in CI/CD pipelines that process third-party repositories, making the effective exploitation barrier low. No EPSS score is provided in the available intelligence, limiting probabilistic exploitation estimation; however, the presence of a detailed, Docker-reproducible proof-of-concept in the GHSA advisory meaningfully lowers the weaponization threshold beyond what the absence of KEV listing might suggest. Even a mid-sized municipal IT team in legnica whose pipelines use GitPython to mirror or process external repositories should treat this as an urgent patching priority rather than a deferred hygiene task. The technical impact - arbitrary Git repository creation including hooks directories - enables secondary vectors such as hook-based code execution if the attacker can anticipate writable paths. The flaw is fully automatable across any pipeline that calls submodule_update(init=True) on untrusted input, which aligns with a high SSVC exploitation concern despite the lack of current KEV confirmation.

An attacker publishes a Git repository containing a .gitmodules file with a submodule name set to a traversal string such as ../../../../home/victim/.ssh, then induces a victim to clone it using GitPython - for example, by submitting a pull request to a project whose CI pipeline clones and initializes submodules from contributor forks. When the pipeline calls submodule_update(init=True), GitPython creates a full Git repository at /home/victim/.ssh, populating it with a hooks directory and config file that overwrite or corrupt the SSH authorized_keys directory. A Docker-reproducible proof-of-concept demonstrating this flow is publicly documented in the GHSA advisory.