| Package | Affected versions | Patched versions |
|---|---|---|
| flowise | < 3.1.2 | 3.1.2 |
| flowise | < 3.1.2 | 3.1.2 |
A Mass Assignment vulnerability exists in the chatflow update endpoint of FlowiseAI.
The endpoint allows clients to modify server-controlled properties such as deployed, isPublic, workspaceId, createdDate, and updatedDate when updating a chatflow object.
Due to missing server-side validation and authorization checks, an authenticated user can manipulate internal attributes of a chatflow and reassign it to another workspace. This allows cross-workspace resource reassignment and unauthorized modification of deployment and visibility settings.
The endpoint responsible for updating chatflows:
PUT /api/v1/chatflows/{chatflowId}
accepts a JSON request body containing the chatflow configuration (flowData) along with other metadata fields.
However, the server does not restrict which properties may be modified by the client. As a result, user-controlled request bodies can include additional fields that should normally be controlled only by the backend.
Examples of server-controlled fields that can be manipulated include:
These fields appear to be directly mapped to the underlying database entity when processing the update request, suggesting that the server performs a direct merge of the request body into the chatflow model without applying a strict DTO whitelist or authorization checks.
For example, modifying the request body with:
{
"deployed": true,
"isPublic": true,
"createdDate": "1999-03-06T10:59:32.000Z",
"updatedDate": "1999-03-06T13:21:34.000Z",
"workspaceId": "11111111-2222-3333-4444-555555555555"
}
results in the server accepting and persisting these values.
In testing, a second workspace was created in the database and the workspaceId field was successfully modified through the API request. The chatflow was reassigned to the attacker-controlled workspace, confirming that the application does not enforce workspace ownership validation.
Authenticate to the Flowise interface.
Capture the request used to update a chatflow:
PUT /api/v1/chatflows/<CHATFLOW_ID>
Content-Type: application/json
Modify the request body by injecting additional fields:
{
"name": "test-flow",
"flowData": "{...}",
"deployed": true,
"isPublic": true,
"workspaceId": "11111111-2222-3333-4444-555555555555"
}
Send the request.
Observe that the response returns the manipulated values:
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site free{
"deployed": true,
"isPublic": true,
"workspaceId": "11111111-2222-3333-4444-555555555555"
}
Verify in the database that the chatflow has been reassigned:
SELECT id, workspaceId FROM chat_flow WHERE id='<CHATFLOW_ID>';
The workspaceId value reflects the attacker-supplied workspace.
This vulnerability allows authenticated users to manipulate server-controlled attributes of chatflows.
Confirmed impacts include:
In multi-tenant environments, this allows an attacker to move chatflows between workspaces without authorization, breaking tenant isolation boundaries.
This may enable:
The issue stems from missing authorization checks and improper handling of client-controlled input in the chatflow update endpoint.