Flowise RBAC Bypass Exposing Workspace Variables via $vars Injection in Custom Function Sandbox

Technical Analysis

The vulnerability stems from an inconsistency between two code paths: the official /api/v1/variables REST endpoint enforces the variables:view permission, but the internal utility that populates $vars for the custom-function execution sandbox (utils.ts:932) does not perform the same check. Because $vars is unconditionally injected into every custom JS execution context (utils.ts:1782), and runtime-type variables are resolved live from process.env (utils.ts:976), any authenticated caller with access to the node-custom-function tool can execute arbitrary code that reads $vars and exfiltrates the full workspace variable map — including secrets like DB passwords, JWT signing keys, SMTP credentials, and cloud API keys. This crosses a tool/agent privilege boundary: a low-privilege identity gains access to data gated behind a higher-privilege permission simply by invoking a different tool endpoint that shares the same underlying variable-resolution logic without re-checking authorization.

Affected Systems

Flowise

Detection Signatures

• Requests to /api/v1/node-custom-function from accounts/API keys lacking variables:view permission
• Custom function code referencing $vars enumeration (e.g. Object.keys($vars), JSON.stringify($vars))
• Unexpected outbound traffic or logs following custom-function execution containing values matching known secret patterns (JWT, AWS keys, DB connection strings)
• API key usage patterns showing repeated node-custom-function calls without corresponding /api/v1/variables calls

Remediation Steps

1. 1

   Upgrade Flowise

   Update to a patched Flowise release beyond 3.1.2 once available that enforces variables:view before populating $vars in custom function execution.

2. 2

   Enforce authorization at variable resolution

   Add a variables:view (or equivalent) permission check directly in the utils.ts code path that builds $vars, not just at the REST route level, to eliminate the inconsistency.

3. 3

   Restrict runtime variable mapping

   In self-hosted deployments, disable or tightly restrict type=runtime variables, and limit which environment variable keys can be mapped to workspace variables.

4. 4

   Apply least privilege to custom function tool access

   Restrict which users/API keys can invoke node-custom-function, treating it as an equally sensitive capability as direct variable access.

5. 5

   Audit and rotate exposed secrets

   Rotate any credentials that were mapped as Flowise workspace variables (DB passwords, JWT secrets, SMTP, cloud keys) given potential prior exposure.