7.6

CVSS Score

4.0

-

CVSS Score

Basic Information

Concerned about an active attack path?

Talk to our security experts and see Miggo in action.

Miggo Vulnerability Database

→

CVE-2026-42862

CVE-2026-42862: Flowise: Mass Assignment in Tool Update Endpoint Allows Cross-Workspace Resource Reassignment

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

(GitHub Advisory)

Miggo Vulnerability Database

→

CVE-2026-42862

CVE-2026-42862:

7.6

CVSS Score

4.0

-

CVSS Score

Basic Information

Is this CVE running in your environment?

Easily map the attack path and prioritize which CVEs are a threat to your organization

Validate Exposure

Technical Details

SSVC / BOD 26-04 ↗

Exploitation pocAutomatable NoTech Impact Total

Select your environment

→SSVCScheduled60 days

Runtime reachability resolves your actual outcome.Book a demo

Package Name	Ecosystem	Vulnerable Versions	First Patched Version
flowise	npm	<= 3.1.1	3.1.2

Technical Details

Vulnerability Intelligence
Miggo AI

Root Cause Analysis

The vulnerability is a mass assignment issue in FlowiseAI's tool management endpoints. An authenticated attacker could modify protected, server-controlled properties of a tool, such as its workspaceId, by sending a crafted request to the PUT /api/v1/tools/{toolId} endpoint. This could lead to a tool being reassigned to a different workspace, breaking tenant isolation.

The root cause lies in the updateTool function within the tools controller (packages/server/src/controllers/tools/index.ts). This function was accepting the entire request body (req.body) and passing it directly to the toolsService.updateTool function. The service layer would then merge these user-provided fields into the database entity, including fields that should not be user-modifiable.

The patch addresses this by implementing an explicit allowlist in the updateTool controller function. Instead of passing the whole request body, it now creates a new toolBody object and only copies over specific, permitted fields (name, description, color, iconSrc, schema, func) from the request. This prevents malicious or unintended modification of protected properties like workspaceId, createdDate, and updatedDate. A similar fix was applied to the createTool function to prevent the same vulnerability during tool creation. The updateTool function in the service layer also received a defense-in-depth fix to explicitly set the workspaceId from the authenticated session, preventing it from being overridden by the request body.

Vulnerable functions

updateTool

packages/server/src/controllers/tools/index.ts

The `updateTool` function in the controller was vulnerable to mass assignment because it passed the entire request body (`req.body`) to the service layer without any filtering. This allowed an attacker to modify protected fields like `workspaceId` by including them in the PUT request to `/api/v1/tools/{toolId}`. The patch fixed this by creating an explicit allowlist of fields that can be updated.

updateTool

packages/server/src/services/tools/index.ts

The `updateTool` function in the service layer blindly merged the object it received from the controller into the database entity. This is the part of the code where the malicious data was persisted. The patch added a defense-in-depth measure by explicitly setting the `workspaceId` from the session, ensuring it cannot be overridden by the client.

createTool

packages/server/src/controllers/tools/index.ts

Similar to the `updateTool` function, the `createTool` function was also vulnerable. It took the entire request body and passed it to the service for creation, allowing an attacker to set protected fields on a new tool from the start. The patch applied the same allowlisting strategy to prevent this.

Vulnerability Intelligence
Miggo AI

Unlock WAF rules for this CVE

Generate vendor-ready rules for the observed attack patterns, plus reasoning and safe deployment guidance

Get WAF rules

WAF Protection Rules

WAF Rule

W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.

Reasoning

*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.