Flowise <= 3.1.1 — 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 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 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.

FlowiseAI Authenticated Remote Code Execution via NodeVM Sandbox Escape

hello@craftedsignal.io — Thu, 14 May 2026 14:59:44 +0000

FlowiseAI, a low-code platform for building AI orchestration flows, is vulnerable to authenticated remote code execution (RCE) affecting versions 3.1.1 and earlier. The vulnerability stems from a missing authorization check on the /api/v1/node-custom-function endpoint, enabling any authenticated user or API key holder to submit malicious JavaScript code to the Custom JS Function node. When the E2B_APIKEY environment variable is not configured, the platform falls back to a NodeVM sandbox. Attackers can escape this sandbox, gain access to the host’s process object, and execute arbitrary system commands. This allows attackers to compromise the Flowise server, potentially leading to data breaches, service disruption, or further lateral movement within the network. Most self-hosted instances are affected because the NodeVM sandbox is enabled by default when E2B_APIKEY is not explicitly set.

Attack Chain

An attacker authenticates to the FlowiseAI application using valid credentials or a valid API key.
The attacker crafts a malicious JavaScript payload designed to escape the NodeVM sandbox.
The attacker sends an HTTP POST request to the /api/v1/node-custom-function endpoint, including the malicious JavaScript code in the javascriptFunction parameter within the request body.
The server, lacking proper authorization checks, executes the attacker-supplied JavaScript code within the Custom JS Function node.
The malicious JavaScript exploits an exception path within the NodeVM to escape the sandbox, gaining access to the host’s process object and child_process module.
The attacker uses the child_process module to execute arbitrary system commands on the Flowise server. For example, cp.execSync('id').toString().trim() to get the user ID.
The attacker retrieves the output of the executed command and potentially uses it to gather sensitive information or further compromise the system.
The attacker leverages the compromised server for lateral movement, data exfiltration, or other malicious activities.

Impact

Successful exploitation allows any authenticated Flowise user to execute arbitrary commands on the Flowise server. This can lead to a full compromise of the server, including the ability to read environment variables and secrets, access the filesystem, and make outbound network requests. The default configuration, which relies on the vulnerable NodeVM sandbox when E2B_APIKEY is not configured, increases the attack surface, as the majority of self-hosted Flowise instances are likely affected. A successful attack can result in data breaches, service disruption, and further exploitation of the compromised environment.

Recommendation

Deploy the “FlowiseAI NodeVM Sandbox Escape Attempt” Sigma rule to detect attempts to exploit this vulnerability by identifying the use of the Error object and constructor chain manipulation within the Custom JS Function node.
Deploy the “FlowiseAI Custom Function RCE via API” Sigma rule to detect HTTP requests to the /api/v1/node-custom-function endpoint with suspicious JavaScript payloads containing potentially malicious code execution patterns.
Immediately apply the recommended remediation steps: add explicit permission gating to /api/v1/node-custom-function, fail closed if E2B_APIKEY is absent, and restrict this endpoint from generic API key access.

FlowiseAI Mass Assignment Vulnerability in Variable Update Endpoint

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

FlowiseAI, a low-code platform for building AI workflows, is vulnerable to a mass assignment flaw (CVE-2026-42861) affecting versions 3.1.1 and earlier. The vulnerability resides in the /api/v1/variables/{variableId} endpoint, which is used for updating variable resources. Due to missing server-side validation, an authenticated attacker can modify critical, server-controlled properties such as workspaceId, createdDate, and updatedDate. This can lead to unauthorized cross-workspace reassignment of variables, potentially compromising tenant isolation in multi-tenant environments. The issue was reported in May 2026, and defenders need to implement mitigations to prevent unauthorized data access and manipulation.

Attack Chain

Attacker authenticates to FlowiseAI with valid user credentials.
Attacker identifies a target variable ID within the application they wish to manipulate.
Attacker crafts a malicious PUT request to /api/v1/variables/{variableId}.
The request body includes the workspaceId field, setting it to the ID of a different workspace the attacker wishes to access.
The request body may also include modified createdDate and updatedDate values for the variable.
The FlowiseAI server, lacking proper validation, accepts the attacker-supplied workspaceId, createdDate, and updatedDate values.
The server updates the variable in the database with the attacker-controlled values, effectively reassigning the variable to the attacker’s chosen workspace.
The attacker can now access and potentially manipulate resources within the targeted workspace using the reassigned variable.

Impact

Successful exploitation allows authenticated users to manipulate internal variable attributes, potentially leading to cross-workspace reassignment of variables, unauthorized modification of metadata, and tenant isolation bypass in multi-workspace deployments. This can allow an attacker to move variables between workspaces without proper authorization. The vulnerability affects FlowiseAI installations version 3.1.1 and earlier.

Recommendation

Apply input validation and authorization checks on the /api/v1/variables/{variableId} endpoint to prevent modification of server-controlled properties like workspaceId, createdDate, and updatedDate as described in CVE-2026-42861.
Monitor PUT requests to the /api/v1/variables/{variableId} endpoint for attempts to modify the workspaceId parameter to detect potential exploitation attempts. Use the detection rule Detect FlowiseAI Mass Assignment in Variable Update to identify anomalous requests.
Implement workspace access controls and verify that users can only access variables within their assigned workspace, regardless of the workspaceId attribute.