CVE-2026-46441: Flowise mass assignment breaks

CISO Take

A mass assignment vulnerability in Flowise's assistant update API (prior to v3.1.2) allows any authenticated user to overwrite server-controlled fields—including workspaceId—effectively crossing tenant boundaries in multi-workspace deployments. For organizations using Flowise to orchestrate enterprise AI agents across business units or clients, this breaks the isolation guarantee: a user in Workspace A can reassign assistants into Workspace B, potentially accessing proprietary prompts, tool configurations, and embedded credentials. There is no public exploit, no EPSS data, and no KEV listing, but the attack is trivial for any authenticated user with basic API knowledge—no specialized AI expertise required. Upgrade to Flowise 3.1.2 immediately; if patching is not possible, apply WAF rules blocking workspaceId modification in PATCH/PUT requests to assistant endpoints.

Sources: NVD GitHub Advisory ATLAS

What is the risk?

Medium-High for multi-tenant Flowise deployments where workspace boundaries enforce data separation between teams, customers, or business units. The authentication requirement reduces exposure versus unauthenticated flaws, but any legitimate user—including malicious insiders or holders of compromised accounts—can exploit this trivially via a crafted API request. Single-tenant or network-isolated deployments face substantially lower risk. The absence of a CVSS score reflects recency, not reduced severity: CWE-639 (Authorization Bypass Through User-Controlled Key) and CWE-915 (Mass Assignment) are well-understood, high-impact vulnerability classes in multi-tenant SaaS contexts.

How does the attack unfold?

Initial Access

Attacker authenticates to the Flowise instance using valid credentials obtained via insider access, phishing, or credential compromise.

AML.T0012

API Exploitation

Attacker crafts a PUT request to the assistant update endpoint, injecting an arbitrary workspaceId belonging to a target tenant's workspace.

AML.T0049

Tenant Isolation Breach

Server accepts the tampered request without authorization validation, reassigning the assistant to the target workspace and nullifying tenant boundaries.

AML.T0081

Data Exfiltration or Manipulation

Attacker accesses or corrupts the target workspace's AI agent configurations, system prompts, and embedded service credentials via the reassigned assistant context.

AML.T0085

Initial Access

Attacker authenticates to the Flowise instance using valid credentials obtained via insider access, phishing, or credential compromise.

AML.T0012

API Exploitation

Attacker crafts a PUT request to the assistant update endpoint, injecting an arbitrary workspaceId belonging to a target tenant's workspace.

AML.T0049

Tenant Isolation Breach

Server accepts the tampered request without authorization validation, reassigning the assistant to the target workspace and nullifying tenant boundaries.

AML.T0081

Data Exfiltration or Manipulation

Attacker accesses or corrupts the target workspace's AI agent configurations, system prompts, and embedded service credentials via the reassigned assistant context.

AML.T0085

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Flowise	npm	—	No patch

Do you use Flowise? You're affected.

How severe is it?

CVSS 3.1

9.6 / 10

EPSS

0.3%

chance of exploitation in 30 days

Higher than 19% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○ CISA SSVC: Public PoC

○ Public PoC indexed (trickest/cve)

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV Network

AC Low

PR Low

UI None

S Changed

C High

I High

A None

What should I do?

5 steps

Patch immediately: upgrade Flowise to version 3.1.2 or later.
Interim WAF control (if patching is delayed): block modification of workspaceId, createdDate, and updatedDate fields in PUT/PATCH requests to /api/v1/assistants/* endpoints.
Audit: review assistant workspaceId assignment history for anomalous cross-workspace transfers since deployment.
Credential rotation: rotate any API keys or secrets embedded in assistant configurations as a precaution.
Network hardening: ensure the Flowise management API is not internet-exposed; restrict access to VPN or internal networks only.

What does CISA's SSVC say?

Decision Attend

Exploitation poc

Automatable No

Technical Impact total

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Auth Bypass Data Extraction Agent Framework AML.T0012 - Valid Accounts AML.T0049 - Exploit Public-Facing Application AML.T0081 - Modify AI Agent Configuration AML.T0085 - Data from AI Services

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 9 - Risk management system

ISO 42001

A.6.1.2 - Segregation of duties and access control

NIST AI RMF

GOVERN 1.2 - Accountability and responsibility

OWASP LLM Top 10

LLM06 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-46441?

A mass assignment vulnerability in Flowise's assistant update API (prior to v3.1.2) allows any authenticated user to overwrite server-controlled fields—including workspaceId—effectively crossing tenant boundaries in multi-workspace deployments. For organizations using Flowise to orchestrate enterprise AI agents across business units or clients, this breaks the isolation guarantee: a user in Workspace A can reassign assistants into Workspace B, potentially accessing proprietary prompts, tool configurations, and embedded credentials. There is no public exploit, no EPSS data, and no KEV listing, but the attack is trivial for any authenticated user with basic API knowledge—no specialized AI expertise required. Upgrade to Flowise 3.1.2 immediately; if patching is not possible, apply WAF rules blocking workspaceId modification in PATCH/PUT requests to assistant endpoints.

Is CVE-2026-46441 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-46441, increasing the risk of exploitation.

How to fix CVE-2026-46441?

1. Patch immediately: upgrade Flowise to version 3.1.2 or later. 2. Interim WAF control (if patching is delayed): block modification of workspaceId, createdDate, and updatedDate fields in PUT/PATCH requests to /api/v1/assistants/* endpoints. 3. Audit: review assistant workspaceId assignment history for anomalous cross-workspace transfers since deployment. 4. Credential rotation: rotate any API keys or secrets embedded in assistant configurations as a precaution. 5. Network hardening: ensure the Flowise management API is not internet-exposed; restrict access to VPN or internal networks only.

What systems are affected by CVE-2026-46441?

This vulnerability affects the following AI/ML architecture patterns: LLM agent orchestration platforms, Multi-tenant AI workflow automation, Enterprise AI assistant deployments, AI agent frameworks.

What is the CVSS score for CVE-2026-46441?

CVE-2026-46441 has a CVSS v3.1 base score of 9.6 (CRITICAL). The EPSS exploitation probability is 0.27%.

What is the AI security impact?

Affected AI Architectures

LLM agent orchestration platformsMulti-tenant AI workflow automationEnterprise AI assistant deploymentsAI agent frameworks

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

AML.T0049 Exploit Public-Facing Application

AML.T0081 Modify AI Agent Configuration

AML.T0085 Data from AI Services

Compliance Controls Affected

EU AI Act: Article 9

ISO 42001: A.6.1.2

NIST AI RMF: GOVERN 1.2

OWASP LLM Top 10: LLM06

What are the technical details?

Original Advisory

Flowise is a drag & drop user interface to build a customized large language model flow. Prior to version 3.1.2, a mass assignment vulnerability exists in the assistant update endpoint of FlowiseAI. The endpoint allows authenticated users to modify server-controlled properties such as workspaceId, createdDate, and updatedDate when updating an assistant resource. Due to missing server-side validation and authorization checks, an attacker can manipulate the workspaceId field and reassign assistants to arbitrary workspaces. This breaks tenant isolation in multi-workspace environments. This issue has been patched in version 3.1.2.

Exploitation Scenario

An authenticated Flowise user with access to Workspace A discovers the assistant update API accepts arbitrary workspaceId values in the request body. Using browser DevTools or an intercepting proxy, they capture a legitimate assistant update request and replace the workspaceId value with the UUID of Workspace B—obtained via enumeration or insider knowledge. The server processes the request without validating that the target workspaceId falls within the user's authorized scope, reassigning the assistant to Workspace B. The attacker can then access the assistant's system prompt, tool definitions, and embedded credentials from Workspace B's context, or inject a malicious assistant with a crafted system prompt into a workspace used by high-privilege users or automated pipelines.

Weaknesses (CWE)

CWE-284 Improper Access Control CWE-284 Improper Access Control CWE-639 Authorization Bypass Through User-Controlled Key CWE-639 Authorization Bypass Through User-Controlled Key CWE-915 Improperly Controlled Modification of Dynamically-Determined Object Attributes CWE-915 Improperly Controlled Modification of Dynamically-Determined Object Attributes

CWE-284 — Improper Access Control: The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.

[Architecture and Design, Operation] Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
[Architecture and Design] Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.

Source: MITRE CWE corpus.