AI Threat AlertA missing permission check in Flowise's code execution sandbox lets any authenticated user or API key call /api/v1/node-custom-function and receive every workspace variable pre-populated in $vars, even when their account is explicitly denied the variables:view permission — the same data the properly-protected Variables API refuses to show them. This matters because those variables commonly hold database passwords, JWT signing secrets, SMTP credentials, and cloud provider keys, either as static values or as live process.env lookups, meaning a low-privilege insider or a compromised low-tier API key can pivot straight to full infrastructure compromise. There's no CISA KEV listing, no public exploit or Nuclei template yet, and EPSS sits at a low 0.28% (top 79th percentile — moderate relative likelihood, not urgent by internet-scanning standards), so this looks like an insider/multi-tenant risk rather than an opportunistic mass-exploitation one. Given zero downstream npm dependents recorded, exposure is concentrated in direct Flowise deployments rather than transitive supply chain. Patch to Flowise 3.1.3 immediately in any multi-user or multi-tenant deployment; until then, audit which accounts/API keys can reach node-custom-function, rotate any secrets stored in workspace Variables, and review logs for anomalous node-custom-function calls from accounts lacking variables:view.
What is the risk?
Moderate-to-high severity despite the absence of a published CVSS score. The bug is a textbook broken-access-control flaw (CWE-863): a secondary code path (node-custom-function) fetches and injects the same sensitive data that a properly-permissioned endpoint blocks. Exploitability is low-complexity for anyone who already holds a Flowise account or API key with node-custom-function access but lacks variables:view — no chained exploit, no special tooling required, just a single API call. The main mitigating factor is that it requires an existing authenticated identity (not unauthenticated RCE), which narrows the threat actor pool to insiders, disgruntled restricted users, or attackers who've already obtained a low-privilege credential via phishing or credential stuffing. No KEV listing, no public PoC, and low EPSS confirm this isn't being mass-exploited today, but the impact ceiling (full secret disclosure enabling lateral movement into databases, cloud accounts, and email infrastructure) makes it a priority patch for any organization running Flowise with multiple users or tenants.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| Flowise | npm | <= 3.1.2 | 3.1.3 |
Do you use Flowise? You're affected.
How severe is it?
What should I do?
1 step1) Upgrade to Flowise 3.1.3 or later immediately — this is the definitive fix. 2) Until patched, restrict or disable access to /api/v1/node-custom-function for any user/API key that is not fully trusted with all workspace variables, since permission scoping cannot be relied upon. 3) Rotate all credentials stored in Flowise Workspace Variables (DB passwords, JWT secrets, SMTP passwords, cloud keys) as a precaution, especially in shared/multi-tenant instances. 4) Audit API access logs for calls to node-custom-function from accounts or keys that lack variables:view, which is a strong indicator of exploitation attempts or accidental exposure. 5) Apply least-privilege to workspace Variables going forward — avoid storing high-value secrets (cloud admin keys, root DB credentials) directly in Flowise Variables where feasible; prefer scoped/short-lived credentials or a secrets manager with just-in-time injection.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-70471?
A missing permission check in Flowise's code execution sandbox lets any authenticated user or API key call /api/v1/node-custom-function and receive every workspace variable pre-populated in $vars, even when their account is explicitly denied the variables:view permission — the same data the properly-protected Variables API refuses to show them. This matters because those variables commonly hold database passwords, JWT signing secrets, SMTP credentials, and cloud provider keys, either as static values or as live process.env lookups, meaning a low-privilege insider or a compromised low-tier API key can pivot straight to full infrastructure compromise. There's no CISA KEV listing, no public exploit or Nuclei template yet, and EPSS sits at a low 0.28% (top 79th percentile — moderate relative likelihood, not urgent by internet-scanning standards), so this looks like an insider/multi-tenant risk rather than an opportunistic mass-exploitation one. Given zero downstream npm dependents recorded, exposure is concentrated in direct Flowise deployments rather than transitive supply chain. Patch to Flowise 3.1.3 immediately in any multi-user or multi-tenant deployment; until then, audit which accounts/API keys can reach node-custom-function, rotate any secrets stored in workspace Variables, and review logs for anomalous node-custom-function calls from accounts lacking variables:view.
Is CVE-2026-70471 actively exploited?
No confirmed active exploitation of CVE-2026-70471 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-70471?
1) Upgrade to Flowise 3.1.3 or later immediately — this is the definitive fix. 2) Until patched, restrict or disable access to /api/v1/node-custom-function for any user/API key that is not fully trusted with all workspace variables, since permission scoping cannot be relied upon. 3) Rotate all credentials stored in Flowise Workspace Variables (DB passwords, JWT secrets, SMTP passwords, cloud keys) as a precaution, especially in shared/multi-tenant instances. 4) Audit API access logs for calls to node-custom-function from accounts or keys that lack variables:view, which is a strong indicator of exploitation attempts or accidental exposure. 5) Apply least-privilege to workspace Variables going forward — avoid storing high-value secrets (cloud admin keys, root DB credentials) directly in Flowise Variables where feasible; prefer scoped/short-lived credentials or a secrets manager with just-in-time injection.
What systems are affected by CVE-2026-70471?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, low-code/no-code LLM orchestration, code execution sandboxes, multi-tenant SaaS platforms.
What is the CVSS score for CVE-2026-70471?
No CVSS score has been assigned yet.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0012Valid AccountsAML.T0053AI Agent Tool InvocationAML.T0055Unsecured CredentialsCompliance Controls Affected
What are the technical details?
Original Advisory
Flowise is a drag-and-drop user interface for building customized large language model (LLM) flows. Prior to 3.1.3, Flowise injects $vars into the code execution sandbox without requiring variables:view, bypassing the permission-protected Variables API. Variables for the active workspace are fetched at packages/components/src/utils.ts and runtime variables are resolved from server environment variables, while the official variables route enforces variables:view. A user or API key that is denied variables:view can call /api/v1/node-custom-function and receive $vars pre-populated with all variables for the workspace, including Variable.name to Variable.value static variables and Variable.name to process.env[Variable.name] runtime variables. This can expose secrets such as database passwords, JWT secrets, SMTP passwords, and cloud keys, depending on the workspace Variables configuration. This issue is fixed in version 3.1.3.
Exploitation Scenario
An organization runs a shared Flowise instance where a marketing team member has an account scoped to build and test LLM flows but is explicitly denied variables:view because the workspace also stores production database and SMTP credentials used by other flows. That user (or an attacker who phished their session/API key) invokes /api/v1/node-custom-function to run what looks like a benign custom JS node. Flowise's utils.ts populates the sandbox's $vars object with the full set of workspace variables regardless of the caller's variables:view permission — both static secrets and process.env-resolved runtime secrets. The attacker's custom function simply returns or exfiltrates $vars (e.g., logs it, POSTs it externally, or renders it in the flow output), harvesting the database password, JWT signing secret, SMTP credentials, and cloud API key in one call. They then use the database password for direct data exfiltration, the JWT secret to forge authentication tokens, and the SMTP credentials to send phishing mail from a trusted domain.
Weaknesses (CWE)
CWE-863Incorrect AuthorizationPrimaryCWE-863Incorrect AuthorizationPrimaryCWE-863Incorrect AuthorizationCWE-863 — Incorrect Authorization: The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.
- [Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) [REF-229] to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
- [Architecture and Design] Ensure that access control checks are performed related to the business logic. These checks may be different than the access control checks that are applied to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor [REF-7].
Source: MITRE CWE corpus.
References
Timeline
Related Vulnerabilities
CVE-2025-7133810.0Flowise: unauthenticated file write enables RCE
Same package: flowiseCVE-2025-5952810.0Flowise: Unauthenticated RCE via MCP config injection
Same package: flowiseCVE-2026-464429.9Flowise: sandbox escape enables authenticated RCE
Same package: flowiseCVE-2025-619139.9Flowise: path traversal in file tools leads to RCE
Same package: flowiseCVE-2026-409339.9Flowise: RCE via MCP stdio command injection
Same package: flowise