CVE-2026-42284 is an option validation bypass in GitPython, scored CVSS 8.1 (high). The library validates clone options as one string, then splits them, so unsafe git options slip through. Upgrade to GitPython 3.1.47 and never pass untrusted text into clone options.
What's affected
The NVD record lists GitPython before 3.1.47, and 3.1.47 is the fixed version. The advisory states versions up to 3.1.44 as affected and 3.1.47 or later as patched. Use 3.1.47 or later and skip 3.1.45 and 3.1.46, since neither is named as a fix.
The advisory also says the issue affects Submodule.update() through its clone_multi_options argument, not only Repo.clone_from. It matters when a program passes outside input into multi_options.
How to check if you're exposed
- Find the installed version in each environment.
pip show GitPython
pip list | grep -i gitpython
- Check your lock files and container images too.
grep -i gitpython requirements*.txt poetry.lock Pipfile.lock 2>/dev/null
- Search your code for
multi_optionsandclone_multi_options, then trace whether any value comes from a user, a repository, a web request or a configuration file someone else controls.
grep -rn "multi_options" .
What to do now
- Upgrade GitPython to 3.1.47 or later and rebuild images.
- Stop passing untrusted values as clone options. Use fixed options chosen by your code.
- Run repository cloning in a sandbox with no credentials, since git hooks run with the rights of the process.
- If you must accept options, allow only a short list of known safe values and compare after splitting, not before.
- Review services that clone repositories for users, such as build tools and code review bots, since those are the likeliest exposed paths.
Why it matters
The class is CWE-88, argument injection. GitPython has a check that blocks dangerous clone options, such as one that changes where hooks are read from. The check ran on the original list. Then the library joined the list into one string and split it again with shell style rules. A single entry could start with an allowed option and carry a second option after a space, so the check saw the safe start and git saw both.
The advisory says git then applies the config and runs hooks during the clone, which means commands from an attacker run on the machine doing the clone. The danger is for programs that accept option text from outside, so the severity score of 8.1 has a high complexity rating.
The fix is conceptually simple. Validate what you execute, not what you received. Whenever input is transformed between a check and its use, the check can be sidestepped. That is worth remembering when you write your own wrappers around command line tools.
The KEV flag is false, and I found no report of exploitation in the wild. GitPython is a transitive dependency of many Python tools, so look beyond your direct requirements.
Try it yourself
This shows how a fix that already exists is surfaced for the exact package version you run.
Click through it at your own pace, or open it full screen.
Quick check
Am I affected if I only call Repo.clone_from with fixed options?
The risk comes from untrusted option text. With fixed options chosen by your code, the bypass has no input to use. Upgrade anyway.
Sources
Last reviewed: 19 October 2026.
