Cross-Workspace — CraftedSignal Threat Feed

FlowiseAI Cross-Workspace Assistant Takeover via Mass Assignment

hello@craftedsignal.io — Thu, 14 May 2026 16:24:43 +0000

FlowiseAI versions 3.1.1 and earlier are vulnerable to a mass assignment vulnerability in the Assistant controller located in packages/server/src/services/assistants/index.ts. An authenticated user can exploit this vulnerability to move an assistant, including its configuration, instructions, attached tools, and credentials, from one workspace to another. The vulnerability stems from the use of Object.assign(entity, body) without proper input validation, allowing a malicious actor to overwrite the workspaceId and id attributes of the Assistant entity. This issue is similar to a previously patched vulnerability in the DocumentStore (commit 840d2ae), highlighting a pattern of insecure mass assignment within the application. This vulnerability can lead to cross-workspace data access and privilege escalation.

Attack Chain

An attacker authenticates to FlowiseAI as a member of workspace A, obtaining a valid session cookie or JWT.
The attacker creates (or reuses) an existing assistant within workspace A and notes the assistant’s id.
The attacker crafts a malicious PUT request to the /api/v1/assistants/ endpoint.
The PUT request includes a JSON body containing a workspaceId attribute set to the UUID of workspace B (the target workspace).
The FlowiseAI server receives the request and calls Object.assign(updateEntity, body) within the Assistant controller.
The workspaceId in the request body overwrites the existing workspaceId of the assistant entity.
The persistence layer updates the assistant record in the database, associating it with workspace B.
The assistant is now accessible to members of workspace B, and the attacker in workspace A loses access.

Impact

This vulnerability allows any authenticated user with permission to update an assistant to move it to another workspace, violating workspace isolation. Given that workspace UUIDs are easily enumerated via the API, an attacker can readily target specific workspaces. Successfully moving an assistant grants the destination workspace access to the assistant’s configuration, instructions, attached tools, and credentials, potentially leading to unauthorized access to sensitive data and resources. This issue is classified as high severity because it breaks a fundamental security boundary within the application.

Recommendation

Upgrade FlowiseAI to a version higher than 3.1.1 to incorporate the fix described in PR https://github.com/FlowiseAI/Flowise/pull/6128.
Deploy the Sigma rule Detect FlowiseAI WorkspaceId Mass Assignment to your SIEM to identify potential exploitation attempts.
Implement regression tests as described in the advisory to prevent future occurrences of this type of vulnerability; ensure requests containing workspaceId, id, createdDate, or updatedDate are rejected on both create and update paths.

FlowiseAI CustomTemplate Mass Assignment Allows Cross-Workspace Template Takeover

hello@craftedsignal.io — Thu, 14 May 2026 16:24:30 +0000

FlowiseAI versions 3.1.1 and earlier are vulnerable to a mass assignment vulnerability in the CustomTemplate controller (packages/server/src/services/marketplaces/index.ts). This flaw allows an authenticated attacker to modify the workspaceId of a custom template through an API request, effectively moving the template to another workspace. The vulnerability stems from the use of Object.assign(entity, body) without proper input validation, enabling the client to control critical fields like workspaceId and id. This issue poses a significant threat as it breaks workspace isolation and allows unauthorized access to custom templates. The vulnerability was identified and a fix has been suggested via allowlisting in PR https://github.com/FlowiseAI/Flowise/pull/6129.

Attack Chain

Attacker, authenticated to workspace A, obtains a valid session cookie/JWT for the Flowise web UI.
Attacker identifies or creates a custom template within workspace A and notes its entity id.
Attacker crafts a PUT /api/v1/customtemplates/ request, including a JSON body with the target workspace B’s UUID in the "workspaceId" field (e.g., "workspaceId": "").
The server receives the request and calls Object.assign(updateEntity, body), copying the attacker-supplied workspaceId into the entity.
The updated entity, now associated with workspace B, is persisted to the database.
The custom template is now accessible to members of workspace B and can be modified or used by them.
The attacker from workspace A loses access to the template, as it is no longer associated with their workspace.
Workspace A’s audit logs do not reflect any unauthorized activity, as the operation appears as a normal template update.

Impact

This vulnerability allows any authenticated user to violate workspace boundaries, potentially exposing sensitive workflow templates to unauthorized users. An attacker can move a customtemplate to any workspace whose UUID they can enumerate, which is made trivial due to workspace UUIDs being exposed in API responses. Successful exploitation allows unauthorized access, modification, and usage of custom templates, potentially leading to data leaks or other malicious activities.

Recommendation

Upgrade to a version of FlowiseAI that includes the fix from PR https://github.com/FlowiseAI/Flowise/pull/6129, which implements an allowlist pattern.
Implement regression tests as described in the advisory to prevent future regressions that could reintroduce mass assignment vulnerabilities in CustomTemplate creation and update paths.
Deploy the Sigma rule Detect Flowise CustomTemplate WorkspaceId Modification to detect potential exploitation attempts by monitoring API requests to the /api/v1/customtemplates/ endpoint with a modified workspaceId in the request body.
Enable webserver logging to facilitate the detection of malicious HTTP requests.

FlowiseAI Cross-Workspace Dataset Takeover via Mass Assignment

hello@craftedsignal.io — Thu, 14 May 2026 16:24:15 +0000

FlowiseAI versions 3.1.1 and earlier contain a mass assignment vulnerability in the Dataset service, allowing authenticated users to move datasets between workspaces. The vulnerability stems from the use of Object.assign() to copy request body parameters directly into Dataset entities without proper input validation or sanitization. Specifically, the workspaceId field can be overwritten by a malicious user, leading to unauthorized access and data exposure in the target workspace. The root cause mirrors a previously patched vulnerability in the DocumentStore service, indicating a systemic issue with input handling across the application. This flaw can be exploited by any authenticated user with permission to update a dataset.

Attack Chain

An attacker authenticates to FlowiseAI within workspace A, obtaining a valid session cookie or JWT.
The attacker identifies a dataset within workspace A that they have permission to update.
The attacker crafts a malicious API request (PUT /api/v1/datasets/) to update the target dataset.
The request body includes a workspaceId parameter set to the UUID of a different workspace (workspace B).
The server-side Dataset controller uses Object.assign(updateEntity, body) to update the dataset entity, blindly accepting the malicious workspaceId.
The persistence layer commits the changes to the database, updating the workspaceId of the dataset.
The dataset is now associated with workspace B, granting access to members of workspace B.
The attacker in workspace A loses access to the dataset, effectively transferring ownership.

Impact

This vulnerability allows any authenticated user to move datasets from one workspace to another, leading to unauthorized data access and potential data breaches. Datasets contain training and evaluation data, which may include sensitive information. Successful exploitation allows unauthorized access to this data in the destination workspace, and removes access from the original owner. Given that workspace UUIDs can be enumerated via the API, the impact is significant.

Recommendation

Apply the patch from PR https://github.com/FlowiseAI/Flowise/pull/6051 which implements an allowlist pattern.
Implement regression tests to ensure that attempts to modify workspaceId, id, createdDate, or updatedDate fields via API requests are rejected or ignored (see suggested fix in content).
Deploy the Sigma rule below to detect suspicious updates to dataset entities with modified workspaceId values.
Implement input validation on all API endpoints that modify Dataset entities to prevent mass assignment vulnerabilities.

FlowiseAI DatasetRow Mass Assignment Allows Cross-Workspace Data Takeover

hello@craftedsignal.io — Thu, 14 May 2026 16:24:01 +0000

FlowiseAI versions 3.1.1 and earlier contain a mass assignment vulnerability in the DatasetRow controller/service (packages/server/src/services/dataset/index.ts). The vulnerability arises from the use of Object.assign(entity, body) without an explicit field allowlist when creating or updating DatasetRow entities. This allows an attacker to control properties like workspaceId and id through the request body, leading to a cross-workspace data takeover. The vulnerability is similar to a previously patched issue in DocumentStore (commit 840d2ae), where an explicit field-by-field allowlist was implemented. This oversight enables an authenticated user to move DatasetRows, which contain individual training/evaluation records, between workspaces, potentially exposing sensitive data.

Attack Chain

An attacker, authenticated as a member of workspace A, obtains a valid session cookie or JWT for the Flowise web UI.
The attacker creates a new DatasetRow within workspace A using the documented API (or reuses an existing one).
The attacker identifies the id of the DatasetRow they control.
The attacker sends a PUT request to the /api/v1/datasetrows/ endpoint (or an equivalent update endpoint).
The PUT request includes a JSON body containing "workspaceId": "", where is the UUID of a different, arbitrary workspace.
The server-side controller receives the request and executes Object.assign(updateEntity, body).
The workspaceId value from the request body overwrites the original workspaceId field of the updateEntity.
The persistence layer commits the modified row to the database, resulting in the DatasetRow being associated with workspace B. Members of workspace B can now access, modify, and utilize the transferred DatasetRow, while workspace A loses access.

Impact

Successful exploitation allows any authenticated workspace member with the permission to update a DatasetRow to move it to any workspace. Since workspace UUIDs are exposed through API responses (e.g., /api/v1/workspaces), enumeration is trivial. This cross-workspace boundary violation exposes training/evaluation records contained in DatasetRows to unauthorized users. An attacker can also rebind a row to a Dataset in another workspace via datasetId, further exposing row content.

Recommendation

Upgrade to FlowiseAI version 3.1.2 or later, where the fix from PR https://github.com/FlowiseAI/Flowise/pull/6051 has been applied, implementing an allowlist pattern.
Deploy the Sigma rule “Detect FlowiseAI DatasetRow WorkspaceId Modification” to detect attempts to modify the workspaceId parameter via the /api/v1/datasetrows endpoint.
Implement regression tests that assert requests containing workspaceId, id, createdDate, or updatedDate are rejected or do not change those columns on the persisted row for both create and update paths, as suggested in the overview.
Monitor web server logs for PUT requests to /api/v1/datasetrows with unusual parameters in the request body.

FlowiseAI Evaluation Cross-Workspace Data Takeover via Mass Assignment

hello@craftedsignal.io — Thu, 14 May 2026 16:23:48 +0000

FlowiseAI, a low-code/no-code platform for building AI orchestration flows, is susceptible to a mass assignment vulnerability in versions 3.1.1 and earlier. The vulnerability resides within the Evaluation controller/service (packages/server/src/services/evaluations/index.ts). By exploiting this flaw, an authenticated user can manipulate the workspaceId of an Evaluation entity. This manipulation is possible due to the use of Object.assign(entity, body) without proper input validation, allowing an attacker to inject arbitrary workspaceId values into the request body. The vulnerability poses a significant risk as it enables cross-workspace data access and manipulation, potentially exposing sensitive information to unauthorized users. The root cause is similar to a previously patched vulnerability in DocumentStore (commit 840d2ae), indicating a pattern of insecure object assignment within the codebase.

Attack Chain

Attacker authenticates to FlowiseAI as a member of workspace A, obtaining a valid session cookie or JWT.
Attacker identifies or creates an Evaluation entity within workspace A, noting its unique id.
Attacker obtains the workspaceId of a target workspace B, potentially through API enumeration (e.g., /api/v1/workspaces) or by inspecting other entities’ workspaceId fields.
Attacker crafts a PUT request to the /api/v1/evaluations/ endpoint, using the id of the Evaluation entity from workspace A.
The request body includes a JSON payload with the "workspaceId" field set to the workspaceId of workspace B.
The server’s Evaluation controller receives the request and uses Object.assign(updateEntity, body) to update the Evaluation entity. The attacker-controlled workspaceId overwrites the existing value.
The persistence layer commits the changes to the database, associating the Evaluation entity with workspace B.
The Evaluation entity is now accessible to members of workspace B and inaccessible to members of workspace A, resulting in unauthorized data access and potential modification.

Impact

The vulnerability allows any authenticated user to move Evaluation entities between workspaces. This cross-workspace boundary violation allows an attacker to access and potentially modify evaluation runs, including captured prompts, model outputs, and scoring data, belonging to other workspaces. Successful exploitation leads to a high level of data exposure, as the attacker can exfiltrate or manipulate data that should be isolated to specific workspaces. The vulnerability affects FlowiseAI versions up to and including 3.1.1.

Recommendation

Upgrade FlowiseAI to the latest version, which includes the fix from PR https://github.com/FlowiseAI/Flowise/pull/6050 that implements an allowlist pattern for updating Evaluation entities.
Deploy the Sigma rule Detect FlowiseAI Evaluation WorkspaceId Manipulation to identify potential exploitation attempts by monitoring PUT requests to the /api/v1/evaluations/ endpoint with modified workspaceId values.
Implement regression tests, as suggested in the source, to ensure that future code changes do not reintroduce the mass assignment vulnerability.
Consider implementing additional input validation on API endpoints to prevent similar mass assignment vulnerabilities in other parts of the application.

FlowiseAI Chatflow Update Endpoint Mass Assignment Vulnerability

hello@craftedsignal.io — Thu, 14 May 2026 14:55:39 +0000

A mass assignment vulnerability has been identified in FlowiseAI versions 3.1.1 and earlier. The vulnerability resides in the chatflow update endpoint, which lacks proper server-side validation and authorization checks. This allows authenticated users to manipulate server-controlled properties of chatflow objects, such as deployed, isPublic, and workspaceId, by including them in the request body. By exploiting this flaw, an attacker can reassign chatflows to different workspaces, modify deployment settings, and alter visibility settings, potentially leading to unauthorized access and control over resources in multi-tenant environments. This vulnerability is identified as CVE-2026-42863.

Attack Chain

The attacker authenticates to the FlowiseAI interface with valid credentials.
The attacker captures a legitimate request used to update a chatflow object via the PUT /api/v1/chatflows/{chatflowId} endpoint.
The attacker modifies the captured request body to include server-controlled fields such as deployed, isPublic, and workspaceId.
The attacker sets the workspaceId to the ID of a workspace controlled by the attacker.
The attacker sends the crafted request to the /api/v1/chatflows/{chatflowId} endpoint.
The FlowiseAI server accepts the modified request and updates the chatflow object in the database without proper validation.
The chatflow is now reassigned to the attacker’s workspace, granting the attacker unauthorized access.
The attacker can further modify the chatflow, change its visibility, or alter its deployment status.

Impact

The mass assignment vulnerability in FlowiseAI allows authenticated users to manipulate server-controlled attributes of chatflows. This can result in unauthorized modification of chatflow visibility, deployment state changes, and cross-workspace reassignment of chatflows. In multi-tenant environments, this vulnerability breaks tenant isolation boundaries, enabling attackers to move chatflows between workspaces without authorization. Successful exploitation can lead to cross-workspace workflow takeover, unauthorized exposure of private workflows, and manipulation of deployed agent workflows, potentially affecting all FlowiseAI installations with versions 3.1.1 or lower.

Recommendation

Deploy the Sigma rule “Detect FlowiseAI Chatflow Mass Assignment Attempt via API” to detect attempts to modify restricted fields via the chatflow update API endpoint.
Apply input validation to the PUT /api/v1/chatflows/{chatflowId} endpoint to prevent modification of deployed, isPublic, workspaceId, createdDate, updatedDate, category, and type parameters, mitigating CVE-2026-42863.
Upgrade FlowiseAI to a patched version that addresses the mass assignment vulnerability to prevent unauthorized modification of chatflow attributes, protecting against CVE-2026-42863.