OESA-2026-2308 (CVE-2026-42215)

Vulnerability from osv_openeuler – Published: 2026-05-15 11:11 – Updated: 2026-08-06 11:11 – Source website
VLAI
Summary
python-GitPython security update
Details

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
  1. 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/=.*$/=(CVE-2026-42215)

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.(CVE-2026-44243)

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.

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.(CVE-2026-44244)

Severity
8.8 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
To clipboard 

{
  "affected": [
    {
      "ecosystem_specific": {
        "noarch": [
          "python-GitPython-help-3.1.49-1.oe2403sp3.noarch.rpm",
          "python3-GitPython-3.1.49-1.oe2403sp3.noarch.rpm"
        ],
        "src": [
          "python-GitPython-3.1.49-1.oe2403sp3.src.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:24.03-LTS-SP3",
        "name": "python-GitPython",
        "purl": "pkg:rpm/openEuler/python-GitPython\u0026distro=openEuler-24.03-LTS-SP3"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1.49-1.oe2403sp3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "details": "GitPython is a python library used to interact with git repositories, high-level like git-porcelain, or low-level like git-plumbing.\r\n\r\nSecurity Fix(es):\n\n### Summary\nGitPython 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`.\n\n### Details\nGitPython explicitly treats helper-command options as unsafe because they can be used to execute arbitrary commands:\n\n- `git/repo/base.py:145-153` marks clone options such as `--upload-pack`, `-u`, `--config`, and `-c` as unsafe.\n- `git/remote.py:535-548` marks fetch/pull/push options such as `--upload-pack`, `--receive-pack`, and `--exec` as unsafe.\n\nThe vulnerable API paths check the raw kwarg names before they\u0026apos;re its normalized into command-line flags:\n\n- `Repo.clone_from()` checks `list(kwargs.keys())` in `git/repo/base.py:1387-1390`\n- `Remote.fetch()` checks `list(kwargs.keys())` in `git/remote.py:1070-1071`\n- `Remote.pull()` checks `list(kwargs.keys())` in `git/remote.py:1124-1125`\n- `Remote.push()` checks `list(kwargs.keys())` in `git/remote.py:1197-1198`\n\nThat 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`.\n\nLater, 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:\n\n- `upload_pack=...` becomes `--upload-pack=...`\n- `receive_pack=...` becomes `--receive-pack=...`\n\nBecause 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.\n\nIn practice:\n\n- `remote.fetch(**{\u0026quot;upload-pack\u0026quot;: helper})` is blocked with `UnsafeOptionError`\n- `remote.fetch(upload_pack=helper)` is allowed and reaches helper execution\n\nThe same bypass works for:\n\n```python\nRepo.clone_from(origin, out, upload_pack=helper)\nrepo.remote(\u0026quot;origin\u0026quot;).fetch(upload_pack=helper)\nrepo.remote(\u0026quot;origin\u0026quot;).pull(upload_pack=helper)\nrepo.remote(\u0026quot;origin\u0026quot;).push(receive_pack=helper)\n```\n\nThis 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.\n\nExisting tests cover the hyphenated form, not the vulnerable underscore form. For example:\n\n- `test/test_clone.py:129-136` checks `{\u0026quot;upload-pack\u0026quot;: ...}`\n- `test/test_remote.py:830-833` checks `{\u0026quot;upload-pack\u0026quot;: ...}`\n- `test/test_remote.py:968-975` checks `{\u0026quot;receive-pack\u0026quot;: ...}`\n\nThose tests correctly confirm the literal Git option names are blocked, but they do not exercise the normal Python kwarg spelling that bypasses the guard.\n\n### PoC\n1. Create and activate a virtual environment in the repository root:\n\n```bash\npython3 -m venv .venv-sec\n.venv-sec/bin/pip install setuptools gitdb\nsource ./.venv-sec/bin/activate\n```\n\n2. make a new python file and put the following in there, then run it:\n\n```python\nimport os\nimport stat\nimport subprocess\nimport tempfile\n\nfrom git import Repo\nfrom git.exc import UnsafeOptionError\n\n# Setup: create isolated repositories so the PoC uses a normal fetch flow.\nbase = tempfile.mkdtemp(prefix=\u0026quot;gp-poc-risk-\u0026quot;)\norigin = os.path.join(base, \u0026quot;origin.git\u0026quot;)\nproducer = os.path.join(base, \u0026quot;producer\u0026quot;)\nvictim = os.path.join(base, \u0026quot;victim\u0026quot;)\nproof = os.path.join(base, \u0026quot;proof.txt\u0026quot;)\nwrapper = os.path.join(base, \u0026quot;wrapper.sh\u0026quot;)\n\n# Setup: this wrapper is just to demo things you can do, not required for the exploit to work\n# you could also do something like an SSH reverse shell, really anything\nwith open(wrapper, \u0026quot;w\u0026quot;) as f:\n    f.write(f\u0026quot;\u0026quot;\u0026quot;#!/bin/sh\n{{\n  echo \u0026quot;code_exec=1\u0026quot;\n  echo \u0026quot;whoami=$(id)\u0026quot;\n  echo \u0026quot;cwd=$(pwd)\u0026quot;\n  echo \u0026quot;uname=$(uname -a)\u0026quot;\n  printf \u0026apos;argv=\u0026apos;; printf \u0026apos;\u0026lt;%s\u0026gt;\u0026apos; \u0026quot;$@\u0026quot;; echo\n  env | grep -E \u0026apos;^(HOME|USER|PATH|SSH_AUTH_SOCK|CI|GITHUB_TOKEN|AWS_|AZURE_|GOOGLE_)=\u0026apos; | sed \u0026apos;s/=.*$/=(CVE-2026-42215)\n\nA 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\u0026apos;s .git directory via insufficient validation of reference paths in reference creation, rename, and delete operations.(CVE-2026-44243)\n\n`GitConfigParser.set_value()` passes values to Python\u0026apos;s `configparser` without validating for newlines. GitPython\u0026apos;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 \u2014 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.\n\nThe vulnerability is not merely malformed config output: GitPython\u0026apos;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.\n\nThis was found while auditing MLRun\u0026apos;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 \u2014 they are caller-supplied API inputs that end up in `.git/config`.\n\nImpact: 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.(CVE-2026-44244)",
  "id": "OESA-2026-2308",
  "modified": "2026-08-06T11:11:16Z",
  "published": "2026-05-15T11:11:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-2308"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42215"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44243"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44244"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "python-GitPython security update",
  "upstream": [
    "CVE-2026-42215",
    "CVE-2026-44243",
    "CVE-2026-44244"
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.