CVE-2026-67323 in GitPython
Summary
by MITRE • 08/01/2026
GitPython before 3.1.51 fails to guard against dangerous Git options passed as keyword arguments in Repo.archive() and git.ls_remote(), allowing command injection via options such as --exec/--upload-pack (leading to arbitrary command execution). Additionally, Repo.iter_commits() and Repo.blame() do not check for leading-dash revision arguments, so a revision like --output=<path> can cause Git to open and truncate an arbitrary file. Exploitation requires an application that passes attacker-controlled arguments to these methods.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/01/2026
This vulnerability resides in the GitPython library version 3.1.51 and earlier, where improper input validation creates multiple command injection pathways through Git command execution. The core issue stems from insufficient sanitization of user-supplied arguments passed to Git commands via repository methods, specifically affecting Repo.archive(), git.ls_remote(), Repo.iter_commits(), and Repo.blame() functions. The vulnerability allows malicious actors to inject dangerous Git options that bypass normal parameter validation mechanisms.
The technical flaw manifests through two primary attack vectors. First, the Repo.archive() and git.ls_remote() methods fail to properly sanitize keyword arguments that get passed directly to Git commands, enabling command injection when options like --exec or --upload-pack are provided. These options can be exploited to execute arbitrary shell commands on the system running the vulnerable application. Second, Repo.iter_commits() and Repo.blame() methods do not validate revision arguments for leading dashes, allowing crafted revision parameters such as --output=<path> to cause Git to open and truncate arbitrary files on the filesystem, potentially leading to data corruption or information disclosure.
From an operational impact perspective, successful exploitation requires an application that accepts attacker-controlled input and passes it directly to these vulnerable GitPython methods. This creates a significant risk for applications that process user-provided repository references, commit identifiers, or branch names without proper sanitization. The vulnerability aligns with CWE-78, which describes improper neutralization of special elements used in OS commands, and CWE-94, covering improper control of generation of code. The attack pattern maps to ATT&CK technique T1059.001 for command and scripting interpreter execution and T1021.004 for remote services.
The security implications extend beyond simple command execution to include potential privilege escalation scenarios when applications run with elevated permissions or access to sensitive repositories. Applications using GitPython for automated code analysis, continuous integration systems, or repository management tools become prime targets for exploitation. The vulnerability is particularly dangerous in environments where GitPython is used to process untrusted input from web forms, API endpoints, or external repository references.
Mitigation strategies should focus on immediate library updates to version 3.1.51 or later, which includes proper argument validation and sanitization. Organizations should implement defensive programming practices by validating all user-supplied arguments before passing them to GitPython methods, using whitelisting approaches for known safe parameters, and implementing input sanitization routines that prevent special characters from reaching Git command execution layers. Additional protective measures include running applications with minimal required privileges, implementing network segmentation, and monitoring for unusual Git command execution patterns that might indicate exploitation attempts.