GitPython clone option validation bypass leading to arbitrary code execution
GitPython versions before 3.1.47 contain an argument-validation bypass in the _clone() function. The function validates the original multi_options list before joining its entries and tokenizing them with shlex.split(). An entry beginning with an allowed option, such as --branch, can therefore conceal additional arguments that emerge only after validation. An attacker can inject Git configuration options, including core.hooksPath, causing Git to execute attacker-controlled hooks during cloning. The vulnerability is fixed in GitPython 3.1.47.
What it means and what to do now: patch path, interim mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
Successful exploitation allows arbitrary Git configuration injection and execution of attacker-controlled hooks during a clone operation, resulting in arbitrary code execution in the context of the process performing the operation.
If you can’t patch tonight, do this now.
No mitigation currently meets Red Hat's product-security criteria for ease of use, deployment, applicability, or stability. Apply the available patched release or vendor update.
Patch, then assume compromise.
Upgrade GitPython to version 3.1.47 or later, or install the applicable vendor-patched package or container image. The fix validates clone options after tokenization rather than validating only the original multi_options entries. SUSE provides an update through SUSE-SU-2026:4072-1, and Red Hat Ansible Automation Platform 2.6 container updates addressing this CVE are available through RHSA-2026:42132.
No public exploits tracked yet. Mallory keeps watching.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
12 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.