CVE-2026-42862: Flowise Mass Assignment Vulnerability Breaks Workspace Isolation

Technical summary

CVE-2026-42862 is a mass assignment vulnerability in Flowise versions prior to 3.1.2, residing in the tool update endpoint. The vulnerability stems from inadequate server-side validation and authorization checks that permit authenticated users to modify security-critical fields including workspaceId, createdDate, and updatedDate via the resource update request. An attacker can inject or modify the workspaceId parameter to reassign a tool from their own workspace to an arbitrary target workspace. The absence of authorization controls means the application does not verify that the authenticated user has permission to move tools into the destination workspace. This breaks tenant isolation by allowing cross-workspace tool manipulation. The vulnerability is classified under CWE-284 (Improper Access Control), CWE-639 (Authorization Bypass), and CWE-915 (Improperly Controlled Modification of Dynamically-Determined Object Attributes), reflecting multiple authorization and input validation failures.

Business impact

In multi-tenant or multi-workspace Flowise deployments, this vulnerability enables workspace isolation breaches. An attacker with standard user credentials can move tools—which may contain sensitive prompts, API integrations, data transformations, or proprietary LLM configurations—into workspaces they do not belong to. This could lead to intellectual property theft, unauthorized access to shared AI workflows, data exfiltration, or sabotage of production pipelines. For organizations using Flowise to build customer-facing AI products, tools leaking across workspace boundaries could expose proprietary algorithms or customer-specific configurations. The reputational and compliance impact depends on what data is embedded in the tools being reassigned.

Affected systems

Flowise versions prior to 3.1.2 are affected. Deployments using multiple workspaces to enforce logical or organizational separation between teams or customers face the highest risk. Single-workspace Flowise instances or those without multi-tenant usage patterns experience reduced impact, though the authorization flaw remains a security issue. The vulnerability affects the tool update endpoint accessible to any authenticated user within the Flowise application.

Exploitability

This vulnerability requires valid authentication—an attacker must already have a user account within a Flowise instance. However, the attack itself is trivial to execute: an authenticated user simply sends a modified update request with a different workspaceId parameter. No special knowledge, race conditions, or user interaction is required. The attack leaves minimal forensic traces in typical application logs and could go undetected if workspace access logs are not monitored. The CVSS 3.1 score of 5.0 (Medium) reflects that exploitation is straightforward for any authenticated user, though the impact is limited to integrity (unauthorized tool modification/movement) rather than confidentiality or availability. The 'changed scope' indicator (S:C) indicates the impact affects resources beyond the attacker's direct authorization scope.

Remediation

Upgrade Flowise to version 3.1.2 or later. This patch addresses the mass assignment and authorization bypass by implementing proper server-side validation of the workspaceId field and enforcing authorization checks to ensure the authenticated user has permission to move tools to the target workspace. Organizations should prioritize patching any multi-workspace Flowise deployments immediately, as the attack surface is high and exploitation is trivial.

Patch guidance

1. Verify your current Flowise version (check your deployment logs, container image tag, or the Flowise admin interface). 2. If running a version prior to 3.1.2, plan and execute an upgrade to 3.1.2 or the latest available release. 3. For containerized deployments, pull the updated image and redeploy; for source-based installations, update the repository and rebuild. 4. Test the update in a non-production environment first, particularly if you have customized Flowise or integrated it deeply with other systems. 5. After patching, conduct a brief audit of recent tool changes to detect any unauthorized workspace reassignments that may have occurred before the patch was applied. 6. Consult the official Flowise release notes and security advisory for any migration steps or breaking changes associated with version 3.1.2.

Detection guidance

Monitor and audit the tool update endpoint for suspicious activity. Log all update requests that modify the workspaceId field, including the user initiating the request, the source workspace, and the target workspace. Cross-reference update logs with expected tool lifecycle changes to identify anomalies. Check Flowise audit logs (if available) for tools that moved between workspaces without documented reason. Review workspace membership and tool inventory periodically to detect unexpected ownership changes. If multi-workspace separation is critical to your security model, implement additional monitoring on workspace boundary crossings. Network-level monitoring may also detect unexpected API calls to the update endpoint from unusual user accounts or IP addresses.

Why prioritize this

Although the CVSS score is Medium (5.0), this vulnerability should be prioritized for organizations running multi-workspace Flowise deployments because: (1) exploitation is trivial—no special tools or knowledge required; (2) the attack is performed by authenticated insiders or compromised accounts, a common threat; (3) the impact on tenant isolation could lead to IP theft or data exposure in multi-customer or multi-team environments; (4) the fix is straightforward (a version upgrade with no documented breaking changes). Single-workspace deployments should still patch, but can deprioritize slightly.

Risk score, explained

The CVSS 3.1 score of 5.0 reflects a Medium severity. Attack Vector is Network (exploitable remotely), Attack Complexity is Low (no special conditions), and Privileges Required are Low (any authenticated user can attack). User Interaction is None, meaning no tricking of users is necessary. Scope is Changed, indicating the attacker can affect resources outside their direct authorization scope (tools in other workspaces). Confidentiality impact is None (the attack does not directly expose data), Integrity is Low (tools can be moved, modifying the logical integrity of workspace boundaries), and Availability is None. The score appropriately reflects that while exploitation is easy and the authorization bypass is serious, the direct damage is limited to tool reassignment rather than data theft or system downtime. Organizations should treat this as a prioritized patch, not a critical incident requiring emergency response, unless they operate high-sensitivity multi-tenant environments.

Frequently asked questions