FlowiseAI — CraftedSignal Threat Feed

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 Evaluator Cross-Workspace Takeover via Mass Assignment

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

FlowiseAI versions 3.1.1 and earlier are susceptible to a mass assignment vulnerability within the Evaluator entity. This flaw arises from the Evaluator controller/service’s use of Object.assign(entity, body) without proper input validation, allowing client-controlled parameters such as workspaceId, id, createdDate, and updatedDate to be injected via API requests. An attacker, authenticated within one workspace, can leverage this vulnerability to move Evaluator entities—and potentially sensitive scoring rubrics—to other workspaces. This can result in unauthorized access to data, privilege escalation, and a loss of data ownership. This issue is similar to a previously patched vulnerability in the DocumentStore (commit 840d2ae), indicating a systemic pattern of insecure object assignment within the application.

Attack Chain

The attacker authenticates to the FlowiseAI web UI as a member of workspace A, obtaining a valid session cookie or JWT.
The attacker creates or identifies an existing Evaluator entity within workspace A.
The attacker crafts a malicious PUT request to the /api/v1/evaluators/ endpoint (or equivalent) targeting the Evaluator entity identified in the previous step.
The attacker includes a JSON body within the PUT request, specifically setting the workspaceId parameter to the UUID of a different workspace (workspace B).
The FlowiseAI server receives the request and, due to the mass assignment vulnerability, uses Object.assign(updateEntity, body) to update the Evaluator entity, overwriting its workspaceId with the attacker-supplied value.
The persistence layer commits the changes to the database, effectively transferring ownership of the Evaluator entity to workspace B.
Members of workspace B can now access, modify, and utilize the transferred Evaluator entity.
The attacker’s workspace A loses access to the Evaluator, and no suspicious activity is logged in workspace A’s audit logs, masking the malicious action.

Impact

This vulnerability allows any authenticated user with permission to update an evaluator to move it to any workspace. The impact of a successful attack includes unauthorized access to evaluators and their scoring rubrics by members of the target workspace, data exfiltration, and potential privilege escalation. An attacker can enumerate workspace UUIDs via the /api/v1/workspaces API listing or through other API responses, making it trivial to identify valid target workspaces.

Recommendation

Upgrade FlowiseAI to version 3.1.2 or later, where the fix from pull request #6050 has been applied.
Deploy the Sigma rule “Detect FlowiseAI Evaluator WorkspaceId Manipulation via API” to identify attempts to exploit this vulnerability by monitoring API requests that modify the workspaceId parameter.
Implement regression tests to verify that attempts to modify workspaceId, id, createdDate, or updatedDate via API requests are rejected or ignored by the server.
Apply the allowlist pattern to all controllers that handle entity updates to prevent similar mass assignment vulnerabilities.