CVE-2026-42863: Flowise Mass Assignment enables

Q: Is CVE-2026-42863 actively exploited?

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

Q: How to fix CVE-2026-42863?

1. Patch: Update flowise to >= 3.1.2 immediately — this release introduces server-side DTO whitelisting on the chatflow update endpoint. 2. Audit: Query for unexpected workspaceId changes — SELECT id, name, workspaceId, updatedDate FROM chat_flow ORDER BY updatedDate DESC — and cross-reference against known user activity. 3. Visibility review: Audit all chatflows where isPublic=true and confirm each is intentionally public. 4. Detection: In versions < 3.1.2, flag PUT /api/v1/chatflows/* requests whose JSON body contains workspaceId, deployed, isPublic, createdDate, or updatedDate fields at the WAF or API gateway layer. 5. Workaround (if patching is delayed): Restrict API access to authenticated internal networks via reverse proxy and implement WAF rules rejecting unexpected fields in chatflow update payloads.

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

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, LLM orchestration pipelines, multi-tenant AI platforms, no-code AI workflow builders.

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

No CVSS score has been assigned yet.

CISO Take

FlowiseAI's chatflow update endpoint (PUT /api/v1/chatflows/{id}) accepts arbitrary client-supplied fields without server-side validation, allowing any authenticated user to override workspace ownership, deployment state, and public visibility of AI agent workflows. In multi-tenant Flowise deployments — common in enterprise AI build environments — this directly breaks tenant isolation: an attacker can silently reassign another tenant's workflow to their own workspace, exposing embedded system prompts, API credentials, and connected data source configurations. The package carries a history of 69 CVEs, indicating a persistent pattern of security quality concerns rather than an isolated defect. Patch immediately to flowise 3.1.2 and audit your database for unexpected workspaceId changes since the last known-good state.

Sources: NVD GitHub Advisory ATLAS

What is the risk?

High risk in any multi-tenant or shared Flowise deployment. Exploitation requires only valid authentication — no elevated privileges — and the technique is trivial: inject server-controlled fields into a standard JSON API request body with no special tooling. The mass assignment pattern is broadly understood at script-kiddie level and requires zero AI/ML expertise. Impact is amplified because Flowise workflows routinely embed API keys, system prompts, data source bindings, and business logic that becomes fully accessible post-reassignment. Single-tenant self-hosted deployments face lower cross-tenant risk but remain exposed to unauthorized deployment state manipulation and visibility changes that can disrupt production AI pipelines.

How does the attack unfold?

Initial Access

Attacker authenticates to the Flowise platform using a valid but low-privilege account in a multi-tenant deployment — no special permissions required.

AML.T0012

API Exploitation

Attacker captures a standard chatflow update request and injects server-controlled fields (workspaceId, isPublic, deployed) into the PUT /api/v1/chatflows/{id} JSON body.

AML.T0049

Configuration Takeover

Server accepts and persists the attacker-supplied workspaceId without ownership validation, reassigning the victim's complete AI agent workflow to the attacker's workspace.

AML.T0081

Data Access and Impact

Attacker gains full access to the victim's chatflow including embedded system prompts, API credentials, and data source connections; optionally exposes workflows publicly or disrupts production AI pipelines by toggling deployment state.

AML.T0085

Initial Access

Attacker authenticates to the Flowise platform using a valid but low-privilege account in a multi-tenant deployment — no special permissions required.

AML.T0012

API Exploitation

Attacker captures a standard chatflow update request and injects server-controlled fields (workspaceId, isPublic, deployed) into the PUT /api/v1/chatflows/{id} JSON body.

AML.T0049

Configuration Takeover

Server accepts and persists the attacker-supplied workspaceId without ownership validation, reassigning the victim's complete AI agent workflow to the attacker's workspace.

AML.T0081

Data Access and Impact

Attacker gains full access to the victim's chatflow including embedded system prompts, API credentials, and data source connections; optionally exposes workflows publicly or disrupts production AI pipelines by toggling deployment state.

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 18% 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: Update flowise to >= 3.1.2 immediately — this release introduces server-side DTO whitelisting on the chatflow update endpoint.
Audit: Query for unexpected workspaceId changes — SELECT id, name, workspaceId, updatedDate FROM chat_flow ORDER BY updatedDate DESC — and cross-reference against known user activity.
Visibility review: Audit all chatflows where isPublic=true and confirm each is intentionally public.
Detection: In versions < 3.1.2, flag PUT /api/v1/chatflows/* requests whose JSON body contains workspaceId, deployed, isPublic, createdDate, or updatedDate fields at the WAF or API gateway layer.
Workaround (if patching is delayed): Restrict API access to authenticated internal networks via reverse proxy and implement WAF rules rejecting unexpected fields in chatflow update payloads.

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

Art. 15 - Accuracy, robustness and cybersecurity Art. 9 - Risk management system

ISO 42001

Annex A, A.6.2 - AI system design and development — security controls

NIST AI RMF

GOVERN 1.2 - Policies and processes for AI risk management MANAGE 2.4 - Mechanisms to sustain AI risk management

OWASP LLM Top 10

LLM06 - Excessive Agency

Frequently Asked Questions

What is CVE-2026-42863?

FlowiseAI's chatflow update endpoint (PUT /api/v1/chatflows/{id}) accepts arbitrary client-supplied fields without server-side validation, allowing any authenticated user to override workspace ownership, deployment state, and public visibility of AI agent workflows. In multi-tenant Flowise deployments — common in enterprise AI build environments — this directly breaks tenant isolation: an attacker can silently reassign another tenant's workflow to their own workspace, exposing embedded system prompts, API credentials, and connected data source configurations. The package carries a history of 69 CVEs, indicating a persistent pattern of security quality concerns rather than an isolated defect. Patch immediately to flowise 3.1.2 and audit your database for unexpected workspaceId changes since the last known-good state.

Is CVE-2026-42863 actively exploited?

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

How to fix CVE-2026-42863?

1. Patch: Update flowise to >= 3.1.2 immediately — this release introduces server-side DTO whitelisting on the chatflow update endpoint. 2. Audit: Query for unexpected workspaceId changes — SELECT id, name, workspaceId, updatedDate FROM chat_flow ORDER BY updatedDate DESC — and cross-reference against known user activity. 3. Visibility review: Audit all chatflows where isPublic=true and confirm each is intentionally public. 4. Detection: In versions < 3.1.2, flag PUT /api/v1/chatflows/* requests whose JSON body contains workspaceId, deployed, isPublic, createdDate, or updatedDate fields at the WAF or API gateway layer. 5. Workaround (if patching is delayed): Restrict API access to authenticated internal networks via reverse proxy and implement WAF rules rejecting unexpected fields in chatflow update payloads.

What systems are affected by CVE-2026-42863?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, LLM orchestration pipelines, multi-tenant AI platforms, no-code AI workflow builders.

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

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksLLM orchestration pipelinesmulti-tenant AI platformsno-code AI workflow builders

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: Art. 15, Art. 9

ISO 42001: Annex A, A.6.2

NIST AI RMF: GOVERN 1.2, MANAGE 2.4

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 chatflow update endpoint of FlowiseAI. The endpoint allows clients to modify server-controlled properties such as deployed, isPublic, workspaceId, createdDate, and updatedDate when updating a chatflow object. Due to missing server-side validation and authorization checks, an authenticated user can manipulate internal attributes of a chatflow and reassign it to another workspace. This allows cross-workspace resource reassignment and unauthorized modification of deployment and visibility settings. This issue has been patched in version 3.1.2.

Exploitation Scenario

An attacker with a legitimate low-privilege account in a multi-tenant Flowise SaaS deployment uses an API proxy to capture a standard chatflow update request. They enumerate a target chatflowId through the listing endpoint or by observing network traffic, then replay the PUT request with an injected workspaceId pointing to another tenant's workspace — a value obtainable by creating a second workspace in the same instance. The server persists the attacker-supplied workspace ID without ownership validation, transferring the victim's complete AI agent workflow — including embedded system prompts, connected API credentials, and RAG data source configurations — to the attacker's workspace. The attacker may simultaneously set isPublic=true to expose the workflow externally or deployed=false to disable the victim's production AI agent pipeline, causing service disruption and potential SLA breaches.

Weaknesses (CWE)

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