Which versions of Flowise are affected by EUVD-2026-52850?

Flowise versions 3.1.2 and earlier contain a critical privilege boundary bypass that allows authenticated users to access all workspace secrets (database passwords, API keys, JWT signing keys)…. A patch is available.

How to fix or mitigate EUVD-2026-52850?

Within 24 hours, audit all Flowise workspace variables and API keys; immediately restrict or disable any API keys or users without explicit `variables:view` permission, and review audit logs for unauthorized calls to `/api/v1/node-custom-function`. Within 7 days, rotate all secrets stored in Flowise workspaces including database passwords, cloud provider API keys, and JWT signing secrets; migrate these to an external secret management system (AWS Secrets Manager, HashiCorp Vault, or equivalent) and reconfigure Flowise to retrieve secrets dynamically. Within 30 days, disable the custom JavaScript execution feature via firewall rules or application configuration to block the vulnerable `/api/v1/node-custom-function` endpoint, and monitor Flowise release notes for version 3.2+ which should contain fixes for this privilege boundary bypass.

Flowise EUVD-2026-52850

Q: What is the CVSS score of EUVD-2026-52850?

EUVD-2026-52850 has a CVSS 4.0 base score of 7.1 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/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. EPSS exploitation probability: 0.3%.

| CVE-2026-70471 HIGH

Incorrect Authorization (CWE-863)

2026-08-04 https://github.com/FlowiseAI/Flowise

GHSA-8r8h-6vcc-xhrv

Authentication Bypass RCE

7.1

CVSS 4.0 · Vendor: https://github.com/FlowiseAI/Flowise

Severity by source

Vendor (https://github.com/FlowiseAI/Flowise) PRIMARY

7.1 HIGH

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/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

vuln.today AI

6.5 MEDIUM

Network-accessible API, low complexity; PR:L because valid authentication is required; C:H due to potential exfiltration of production secrets; no integrity or availability impact applies.

3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (https://github.com/FlowiseAI/Flowise).

CVSS VectorVendor: https://github.com/FlowiseAI/Flowise

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Lifecycle Timeline

Patch available

Aug 04, 2026 - 19:02 EUVD

Source Code Evidence Fetched

Aug 04, 2026 - 18:08 vuln.today

Analysis Generated

Aug 04, 2026 - 18:08 vuln.today

CVE Published

Aug 04, 2026 - 17:43 cve.org

HIGH

DescriptionCVE.org

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).

AnalysisAI

Unauthorized workspace variable disclosure in Flowise (<= 3.1.2) allows any authenticated user or API key - even one explicitly denied the variables:view RBAC permission - to exfiltrate all workspace secrets by calling /api/v1/node-custom-function. The $vars object, populated with static variable values and runtime secrets resolved from process.env, is unconditionally injected into every custom JavaScript execution sandbox (utils.ts:1782), while the official /api/v1/variables endpoint correctly enforces the permission gate - creating a direct privilege boundary bypass. Depending on workspace configuration, exposed data can include database passwords, JWT signing secrets, SMTP credentials, and cloud provider API keys. No public exploit code has been identified at time of analysis, and this CVE is not listed in CISA KEV.

Technical ContextAI

Flowise is an open-source, drag-and-drop LLM workflow builder distributed as an npm package (pkg:npm/flowise). It implements role-based access control with granular permissions, including variables:view. The vulnerability is rooted in CWE-863 (Incorrect Authorization): the code path in packages/components/src/utils.ts fetches all workspace variables at line 932 without verifying the caller holds variables:view, resolves runtime-type variables from process.env at line 976, and unconditionally injects the resulting flat map as $vars into the Node.js sandbox context at line 1782. By contrast, the authoritative Variables REST API route (packages/server/src/routes/variables/index.ts:11) does enforce the RBAC check, confirming that the authorization logic exists but was never applied to the code execution path. The sandbox itself - accessible via /api/v1/node-custom-function - was designed for custom JavaScript execution within flows, making any data injected into it fully readable by the executing script.

RemediationAI

Upgrade Flowise to version 3.1.3 or later via npm; the patched release is documented at https://github.com/FlowiseAI/Flowise/releases/tag/flowise@3.1.3 and the security advisory is at https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-8r8h-6vcc-xhrv. If immediate upgrade is not feasible, restrict access to the /api/v1/node-custom-function endpoint at the reverse-proxy or network layer to fully-trusted users only - this eliminates the attack vector but disables custom function execution for all users, which may break existing flows. As a complementary control, audit workspace variables and remove or rotate any secrets of type runtime that map sensitive environment variables (database URLs, JWT keys, cloud credentials); eliminating high-value secrets from workspace variables removes the exfiltration payoff while the patch is applied, though it does not fix the underlying authorization bypass. Do not rely solely on RBAC configuration as a mitigation - the bypass circumvents the permission check entirely.