CVE-2026-76218 is an argument injection flaw (CWE-88) in the Repo.init method of GitPython. Unsafe git options are passed straight through, so a template directory can plant hooks that run on later operations. The record rates it High at 7.5. Version 3.1.58 fixes it, so upgrade.
What's affected
The record says GitPython before 3.1.58 is affected, and the GitHub advisory (GHSA-9rj7-rf2p-w77r) lists 3.1.58 and later as patched.
The advisory says two preconditions apply. The application must forward a template keyword argument that someone outside can control, and the planted hooks must come from a directory the attacker can supply. That is why attack complexity is high. The advisory also points out that the clone path was fixed separately under CVE-2026-73623, and that Repo.init had never received the same guard.
Severity, as two sources state it. The record gives 7.5 (High) under CVSS 3.1, and VulnCheck lists 7.7 (High) under CVSS 4.0.
How to check if you're exposed
Check the installed version of the package in each environment that uses it.
pip show gitpython
pip list | grep -i gitpython
pip freeze | grep -i gitpython
Also check lock files and container images, since GitPython often arrives through tools such as automation scripts, notebooks and CI helpers. Then search your own code for calls to Repo.init and ask a plain question: can a user, a file or a network source influence the options passed to it? If the options are fixed strings in your code, the practical risk is low. If they are built from outside input, treat the issue as urgent.
What to do now
- Upgrade GitPython to 3.1.58 or later.
- Search your code for Repo.init calls and confirm that no caller forwards arbitrary keyword arguments.
- Allow only a fixed set of options in any wrapper you write around git operations.
- Avoid running git commands in directories that were initialised from untrusted templates.
- If your service creates repositories for users, run it with a restricted account and no stored credentials.
Why it matters
The class is argument injection, CWE-88. Repo.init forwards its keyword arguments to the git init command with no check for unsafe options and no parameter to opt in to unsafe ones. The advisory explains that git init with a template option copies hook scripts into the new repository's hooks folder, and git runs hooks on the next matching operation.
This one illustrates how a fix for one path rarely closes a whole class. The clone method got a guard, and the neighbouring init method did not. When a library wraps a command line tool, each wrapper method needs the same policy about what may be passed through. For your own code, the cheap defence is the same everywhere: pass only values you chose, never a dictionary of options that came from a request. KEV status is false.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
How is this different from CVE-2026-73623?
That CVE covers the clone method, and this one covers Repo.init. They are separate code paths with separate fixes, in 3.1.54 and 3.1.58 respectively.
Does upgrading to 3.1.54 cover this?
No. The fix for this one is listed at 3.1.58, so go to that version or later.
Sources
Last reviewed: 18 October 2026.
