CVE-2026-78677 in GitPython
Summary
by MITRE • 08/25/2026
GitPython before 3.1.59 omits --separate-git-dir from unsafe_git_clone_options, allowing attackers to create arbitrary git directories outside the intended clone destination. Attackers can pass a separate_git_dir parameter to Repo.clone_from() or Repo.clone() to redirect repository metadata to an attacker-controlled filesystem path, enabling arbitrary directory creation and potential hook execution.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/25/2026
The vulnerability identified in GitPython versions prior to 3.1.59 represents a critical security flaw rooted in the improper handling of command-line arguments during git clone operations. Specifically, the library failed to include the --separate-git-dir flag within its list of unsafe_git_clone_options. This omission allows an attacker who can influence or control parameters passed to functions such as Repo.clone_from() or Repo.clone() to manipulate where Git stores repository metadata. By passing a separate_git_dir parameter pointing to an arbitrary filesystem path, an adversary can redirect the creation of .git directories away from the intended clone destination and into locations under their control. This behavior deviates significantly from secure defaults, which typically restrict such operations to within the target directory structure to prevent side-channel attacks or file system manipulation.
From a technical perspective, this flaw exploits the flexibility inherent in Git's architecture regarding where repository data can be stored. When --separate-git-dir is utilized without proper validation and restriction, it enables the creation of directories at arbitrary locations on the host filesystem. This capability goes beyond simple code execution; it facilitates unauthorized file system modifications, including the potential placement of malicious hooks or configuration files in sensitive areas. If an attacker controls a directory where Git metadata is written, they may also influence subsequent git operations performed by legitimate users or automated systems that interact with those repositories. The lack of sanitization for this specific argument creates a pathway for path traversal-like effects and arbitrary file creation, undermining the integrity of the local development environment.
The operational impact of this vulnerability extends beyond immediate code execution to broader system compromise scenarios. An attacker leveraging this flaw could establish persistent access points by planting malicious hooks that trigger during routine git operations such as pull or merge. These hooks execute shell commands with the privileges of the user running Git, potentially leading to remote code execution if combined with other vectors. Furthermore, the ability to create arbitrary directories can be used for denial-of-service attacks through disk space exhaustion or resource contention in shared environments. In CI/CD pipelines where automated cloning occurs frequently, this vulnerability could allow an attacker to disrupt build processes or inject malicious artifacts into downstream stages by manipulating repository structures before they are processed further.
This issue aligns with CWE-78 Improper Neutralization of Special Elements used in an OS Command and CWE-22 Path Traversal: '..' Element Not Properly Neutralized, as it involves the manipulation of file system paths through command-line arguments. In terms of MITRE ATT&CK mapping, this vulnerability supports techniques related to Execution via Client Binary Proxy or Hooking, specifically T1546 Event Triggered Execution and potentially T1059 Command and Scripting Interpreter if hooks are successfully planted. The attack vector is classified as Local Privilege Escalation or Remote Code Execution depending on the context of how GitPython is invoked within an application stack.
To mitigate this risk, organizations must immediately upgrade to GitPython version 3.1.59 or later, where the --separate-git-dir flag has been correctly added to the unsafe_git_clone_options list. This update ensures that any attempt to redirect git metadata storage via this parameter is blocked by default unless explicitly overridden through secure configuration channels. Additionally, developers should review existing codebases for direct calls to Repo.clone_from() or Repo.clone() with user-supplied inputs and implement strict input validation to ensure paths remain within expected boundaries. Implementing least-privilege principles for the execution context of Git operations can further reduce the impact if such a vulnerability is exploited in legacy systems that cannot be immediately patched. Regular auditing of third-party library dependencies and their security configurations remains essential to maintaining robust application security posture against evolving threats targeting version control integrations.