CVE-2026-42861: Flowise mass assignment breaks

Q: Is CVE-2026-42861 actively exploited?

No confirmed active exploitation of CVE-2026-42861 has been reported, but organizations should still patch proactively.

Q: How to fix CVE-2026-42861?

1. Patch: Upgrade flowise to ≥3.1.2 immediately — the fix is available and referenced in GHSA-6fw7-3q8r-m5vj. 2. Workaround (if patching is delayed): deploy a WAF rule to reject PUT /api/v1/variables requests whose JSON body contains workspaceId, createdDate, or updatedDate keys. 3. Detection: Query the Flowise database for variables where workspaceId does not match the workspace of the account that last modified them — any discrepancy is a signal of exploitation. 4. Audit: Review API access logs for PUT /api/v1/variables calls with oversized or anomalous JSON bodies. 5. Rotate any API keys or sensitive credentials stored as Flowise variables in all workspaces as a precautionary measure following an audit.

Q: What systems are affected by CVE-2026-42861?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, multi-tenant AI deployments, LLM workflow platforms, AI pipeline orchestration.

Q: What is the CVSS score for CVE-2026-42861?

No CVSS score has been assigned yet.

CISO Take

FlowiseAI versions ≤3.1.1 contain a mass assignment vulnerability in the PUT /api/v1/variables endpoint that allows any authenticated user to overwrite server-controlled fields — including workspaceId — reassigning agent variables to arbitrary workspaces and bypassing tenant isolation. In shared or multi-tenant Flowise deployments, a low-privilege account is sufficient to move variables containing API keys, system prompts, or model credentials across workspace boundaries without authorization. The package carries 69 prior CVEs, signaling sustained attacker interest in this codebase, and exploitation is trivial — no tooling required beyond a standard HTTP client. Upgrade to flowise 3.1.2 immediately; in the interim, block PUT /api/v1/variables requests at the WAF level if they include workspaceId, createdDate, or updatedDate in the body, and audit variable records for unexpected cross-workspace reassignments.

Sources: NVD GitHub Advisory ATLAS

What is the risk?

Medium-high. Exploitation requires a valid account but is otherwise trivial — the attacker includes extra fields in a standard API request with no specialized tooling. The blast radius is concentrated in multi-tenant Flowise deployments where workspace boundaries are a security control; a single compromised or malicious account can breach that boundary entirely. Single-tenant deployments face reduced risk but remain exposed to metadata tampering (forged createdDate/updatedDate) that corrupts audit trails and compliance evidence chains, which is particularly damaging for organizations relying on Flowise workflow logs as ISO 42001 or EU AI Act compliance artifacts.

How does the attack unfold?

Initial Access

Attacker authenticates to Flowise with a valid low-privilege account in any workspace of the target deployment.

AML.T0012

Exploitation

Attacker crafts a PUT /api/v1/variables/{id} request for a variable they own, injecting an arbitrary workspaceId belonging to a victim tenant into the JSON body.

AML.T0049

Tenant Isolation Bypass

Server accepts and persists the attacker-controlled workspaceId and forged metadata timestamps without validation, silently reassigning the variable across workspace boundaries.

AML.T0081

Impact

Attacker accesses or contaminates agent variables containing API keys, system prompts, and model credentials in the victim workspace, breaking multi-tenant isolation and corrupting audit trails.

AML.T0085

Initial Access

Attacker authenticates to Flowise with a valid low-privilege account in any workspace of the target deployment.

AML.T0012

Exploitation

Attacker crafts a PUT /api/v1/variables/{id} request for a variable they own, injecting an arbitrary workspaceId belonging to a victim tenant into the JSON body.

AML.T0049

Tenant Isolation Bypass

Server accepts and persists the attacker-controlled workspaceId and forged metadata timestamps without validation, silently reassigning the variable across workspace boundaries.

AML.T0081

Impact

Attacker accesses or contaminates agent variables containing API keys, system prompts, and model credentials in the victim workspace, breaking multi-tenant isolation and corrupting audit trails.

AML.T0085

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Flowise	npm	<= 3.1.1	`3.1.2`

Do you use Flowise? You're affected.

How severe is it?

CVSS 3.1

N/A

EPSS

0.3%

chance of exploitation in 30 days

Higher than 17% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Trivial

Exploitation Confidence

medium

○ CISA SSVC: Public PoC

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

What should I do?

5 steps

Patch: Upgrade flowise to ≥3.1.2 immediately — the fix is available and referenced in GHSA-6fw7-3q8r-m5vj.
Workaround (if patching is delayed): deploy a WAF rule to reject PUT /api/v1/variables requests whose JSON body contains workspaceId, createdDate, or updatedDate keys.
Detection: Query the Flowise database for variables where workspaceId does not match the workspace of the account that last modified them — any discrepancy is a signal of exploitation.
Audit: Review API access logs for PUT /api/v1/variables calls with oversized or anomalous JSON bodies.
Rotate any API keys or sensitive credentials stored as Flowise variables in all workspaces as a precautionary measure following an audit.

What does CISA's SSVC say?

Decision Track*

Exploitation poc

Automatable No

Technical Impact partial

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 15(5) - Cybersecurity of AI systems

ISO 42001

A.6.2 - Data governance for AI systems

NIST AI RMF

GOVERN-6.2 - Policies and procedures for AI risk response

OWASP LLM Top 10

LLM06:2025 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-42861?

FlowiseAI versions ≤3.1.1 contain a mass assignment vulnerability in the PUT /api/v1/variables endpoint that allows any authenticated user to overwrite server-controlled fields — including workspaceId — reassigning agent variables to arbitrary workspaces and bypassing tenant isolation. In shared or multi-tenant Flowise deployments, a low-privilege account is sufficient to move variables containing API keys, system prompts, or model credentials across workspace boundaries without authorization. The package carries 69 prior CVEs, signaling sustained attacker interest in this codebase, and exploitation is trivial — no tooling required beyond a standard HTTP client. Upgrade to flowise 3.1.2 immediately; in the interim, block PUT /api/v1/variables requests at the WAF level if they include workspaceId, createdDate, or updatedDate in the body, and audit variable records for unexpected cross-workspace reassignments.

Is CVE-2026-42861 actively exploited?

No confirmed active exploitation of CVE-2026-42861 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-42861?

1. Patch: Upgrade flowise to ≥3.1.2 immediately — the fix is available and referenced in GHSA-6fw7-3q8r-m5vj. 2. Workaround (if patching is delayed): deploy a WAF rule to reject PUT /api/v1/variables requests whose JSON body contains workspaceId, createdDate, or updatedDate keys. 3. Detection: Query the Flowise database for variables where workspaceId does not match the workspace of the account that last modified them — any discrepancy is a signal of exploitation. 4. Audit: Review API access logs for PUT /api/v1/variables calls with oversized or anomalous JSON bodies. 5. Rotate any API keys or sensitive credentials stored as Flowise variables in all workspaces as a precautionary measure following an audit.

What systems are affected by CVE-2026-42861?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, multi-tenant AI deployments, LLM workflow platforms, AI pipeline orchestration.

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

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksmulti-tenant AI deploymentsLLM workflow platformsAI pipeline orchestration

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 15(5)

ISO 42001: A.6.2

NIST AI RMF: GOVERN-6.2

OWASP LLM Top 10: LLM06:2025

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 variable update endpoint of FlowiseAI. The endpoint allows authenticated users to modify server-controlled properties such as workspaceId, createdDate, and updatedDate when updating a variable resource. Due to missing server-side validation and authorization checks, an attacker can manipulate the workspaceId field and reassign variables to arbitrary workspaces. This behavior may break tenant isolation in multi-workspace environments. This issue has been patched in version 3.1.2.

Exploitation Scenario

A legitimate but malicious user in a shared Flowise deployment authenticates with their own workspace credentials. They identify target workspace UUIDs through error messages, enumeration, or brute-force of the UUID space. The attacker selects a variable they own and sends a PUT /api/v1/variables/{id} request with the victim's workspaceId injected into the JSON body alongside normal fields. The backend persists the record with the attacker-controlled workspaceId without validation. Depending on application logic governing workspace-level reads, the attacker can now access or contaminate variables in the victim workspace — harvesting LLM API keys, injecting malicious system prompt values, or altering model endpoint configurations to redirect AI agent traffic. Forged createdDate and updatedDate fields are used to disguise the tampering in audit logs.

Weaknesses (CWE)

CWE-284 Improper Access Control Primary CWE-284 Improper Access Control Primary CWE-639 Authorization Bypass Through User-Controlled Key Primary CWE-639 Authorization Bypass Through User-Controlled Key Primary CWE-915 Improperly Controlled Modification of Dynamically-Determined Object Attributes Primary CWE-915 Improperly Controlled Modification of Dynamically-Determined Object Attributes Primary CWE-284 Improper Access Control CWE-639 Authorization Bypass Through User-Controlled Key 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.