CVE-2026-78678 in GitPython
Summary
by MITRE • 08/25/2026
GitPython versions before 3.1.59 contain an incomplete denylist in the unsafe_git_revision_options guard that omits --contents and -S options, allowing attackers to read arbitrary files by passing these options to Repo.blame(). Attackers can supply revision values like --contents=/etc/passwd to leak file contents through the blame result returned to the caller.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/25/2026
GitPython versions prior to 3.1.59 contain a critical security flaw within its unsafe_git_revision_options guard mechanism, which is designed to prevent command injection attacks when interacting with Git repositories. The core of this vulnerability lies in an incomplete denylist that fails to adequately restrict potentially dangerous command-line arguments passed to the underlying git binary. Specifically, the filter omits the --contents and -S options from its list of prohibited inputs. This oversight allows attackers who have control over user-supplied input used as revision values to bypass security controls and execute unintended operations against the host system or repository data.
The technical flaw manifests primarily through the Repo.blame() method, which is commonly used to determine line-by-line authorship history for files in a Git repository. Under normal circumstances, this function expects valid commit references such as branch names, tags, or SHA hashes. However, because the denylist does not block --contents and -S, an attacker can craft malicious revision strings that exploit these options. For instance, by supplying a value like --contents=/etc/passwd, the attacker tricks the git blame command into treating the specified file path as if it were part of the repository's history structure. This manipulation causes Git to output the raw contents of arbitrary files located on the filesystem where the script is executed, rather than returning standard blame metadata.
The operational impact of this vulnerability is significant, particularly in environments where user input directly influences git operations without sufficient sanitization. Attackers can leverage this flaw for unauthorized data exfiltration by reading sensitive configuration files, source code containing secrets or credentials, private keys, and other confidential information stored on the server. This capability effectively turns a version control utility into an arbitrary file read vector, compromising confidentiality integrity of the application environment. In web applications or CI/CD pipelines that process untrusted repository references, this could lead to severe data breaches without requiring elevated privileges beyond those held by the user running the GitPython script.
This vulnerability aligns with CWE-78 Improper Neutralization of Special Elements used in an OS Command and CWE-200 Exposure of Sensitive Information to an Unauthorized Actor. From a tactical perspective, it maps to ATT&CK technique T1530 Data from Local System Retrieval via file access mechanisms enabled by command injection. To mitigate this risk, organizations must upgrade GitPython to version 3.1.59 or later where the denylist has been corrected to include --contents and -S among other dangerous options. Additionally, developers should implement defense-in-depth strategies such as strict input validation using allowlists rather than relying solely on denylists for command arguments. Where possible, avoid passing user-controlled strings directly into git commands; instead use safe abstractions provided by the library that do not invoke shell interpreters or raw argument injection points. Regular security audits of code interacting with external binaries are also recommended to identify similar patterns in other parts of the application stack.