CVE-2026-70471: Flowise: RBAC Bypass Leading to Unauthorized Workspace Variables Disclosure

The /api/v1/variables route enforces variables:view. The custom function path does not. In packages/components/src/utils.ts, the active workspace's variables are fetched with no permission check (around line 932), and $vars is always injected into the code execution sandbox (around line 1782). A caller who can use /api/v1/node-custom-function therefore gets a pre-filled $vars map.

The map has two kinds of entries. Static variables map Variable.name to Variable.value. Runtime variables (type runtime) map the name to process.env[Variable.name], which reads the server's environment (around line 976). Depending on how the workspace was set up, that can reveal database passwords, JWT secrets, SMTP passwords and cloud keys.

The attacker needs a login or API key that can run custom functions but lacks variables:view. The vector shows low privileges and high confidentiality impact only. The advisory reports no integrity or availability effect. It is a privilege boundary bypass: the RBAC rule on the Variables API means nothing if the same data can be read from a custom function. The advisory describes the issue through the code paths and gives no runnable exploit request.

The flowise npm package, version 3.1.2 and earlier. It matters most in workspaces with RBAC where some roles may run custom functions but may not view variables, and where runtime variables expose environment values. Check the version:

npm ls flowise

Upgrade flowise to 3.1.3.

npm install -g [email protected]

The advisory recommends not injecting $vars unless the caller is authorized (require variables:view), or injecting only an allowlist of the variables a function needs. It also suggests restricting runtime variables on self-hosted installs and limiting which environment keys they can map. After upgrading, rotate any secret that a lower-privileged user could have read through a custom function.

Review Custom Function nodes and saved chatflows for code that reads $vars, in particular where the author's role lacks variables:view. Check access logs for calls to /api/v1/node-custom-function from keys and users that never call /api/v1/variables. Look at the workspace Variables list for runtime variables that map to sensitive environment names. If a suspicious function ran, treat the mapped secrets as exposed.

Finding — Unauthorized Workspace Variables disclosure via $vars injection (bypasses variables:view)

What’s wrong (code locations)

• Variables for the active workspace are fetched without checking “variables:view” at this call site: flowise-src/ packages/components/src/utils.ts:932
• Runtime variables are resolved from server environment variables: flowise-src/packages/components/src/utils.ts:976
• $vars is always injected into the code execution sandbox: flowise-src/packages/components/src/utils.ts:1782
• The official Variables API is permission-protected (contrast): flowise-src/packages/server/src/routes/variables/ index.ts:11

Why it is a privilege boundary bypass

A user/API key might be denied variables:view (and the /api/v1/variables route enforces it), but they can still:

• call /api/v1/node-custom-function (Finding 1)
• and have $vars pre-populated with all variables for the workspace, including runtime values from process.env

What data is exposed

Inside the custom JS context, $vars contains a flat map of:

• Variable.name -> Variable.value for static variables, and
• Variable.name -> process.env[Variable.name] for runtime variables (type === 'runtime')

This can expose secrets such as database passwords, JWT secrets, SMTP passwords, cloud keys, etc., depending on what the workspace Variables are configured to map.

Recommended fix (minimum)

• Do not inject $vars unless the caller is authorized:
• enforce variables:view before injecting $vars, or
• inject only an explicit allowlist of variables needed for the function
• Consider disabling or heavily restricting type=runtime variables in self-hosted environments (or restrict which env keys may be mapped).