GitPython rejected submodule paths containing the string .git/hooks too late in the cloning process, allowing an attacker to plant a malicious post‑checkout hook before the path validation occurs. Because the hook is written to the repository’s hooks directory, any subsequent Git operation that triggers post‑checkout runs the attacker‑provided code, giving remote code execution. The weakness is a logic error in input handling (CWE‑696) and a path traversal vulnerability (CWE‑73). The attacker does not need elevated privileges; the vulnerability is exercised by any process that calls create_submodule with a path that includes a sub‑directory of .git, such as .git/hooks.

GitPython, the python library used to interact with Git repositories, is affected in all releases prior to 3.2.1. Versions 3.1.x and the 3.2.0 series contain a flawed _validate_repo_path routine that only raises an error after the repository has been cloned, while the check in git/index/base.py fails to roll back the planted hook file.

The vulnerability carries a CVSS score of 7.5, indicating high severity. The EPSS score is <1%, indicating a very low probability of exploitation, but the attack requires the application to accept submodule paths that place files in .git/hooks and that the destination directory is empty enough for a clone. Because the flaw manifests only when the target application allows an attacker‑controlled submodule path, exploitation is feasible in environments where untrusted repositories are integrated. The issue is not listed in CISA’s KEV catalog, so no active exploits are formally documented. Once the library is updated or submodule paths are sanitized, the risk is eliminated.