Severity by source
CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Primary rating from Vendor (https://github.com/FlowiseAI/Flowise) · only source for this CVE.
CVSS VectorVendor: https://github.com/FlowiseAI/Flowise
CVSS:4.0/AV:N/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Lifecycle Timeline
7DescriptionCVE.org
Summary
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.
Details
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:
- deployed
- isPublic
- workspaceId
- createdDate
- updatedDate
- category
- type
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.
PoC
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:
{
"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.
Impact
This vulnerability allows authenticated users to manipulate server-controlled attributes of chatflows.
Confirmed impacts include:
- Unauthorized modification of chatflow visibility (isPublic)
- Unauthorized deployment state changes (deployed)
- Cross-workspace reassignment of chatflows (workspaceId)
- Unauthorized modification of metadata (createdDate, updatedDate)
In multi-tenant environments, this allows an attacker to move chatflows between workspaces without authorization, breaking tenant isolation boundaries.
This may enable:
- Cross-workspace workflow takeover
- Unauthorized exposure of private workflows
- Manipulation of deployed agent workflows
The issue stems from missing authorization checks and improper handling of client-controlled input in the chatflow update endpoint.
AnalysisAI
{chatflowId} endpoint to overwrite server-controlled fields including workspaceId, deployed, isPublic, createdDate, and updatedDate. The vendor advisory GHSA-5wxp-qjgq-fx6m confirms tenant isolation can be broken in multi-tenant deployments, and publicly available exploit code exists in the form of a detailed PoC published with the advisory. No public exploit identified at time of analysis as actively used in the wild, and this CVE is not listed in CISA KEV.
Technical ContextAI
FlowiseAI is an open-source low-code platform for building LLM-powered agent workflows (chatflows and agentflows), distributed as the npm package 'flowise'. The vulnerability sits in the Express-based REST API at PUT /api/v1/chatflows/{chatflowId}, where the request body is merged directly into the underlying TypeORM chat_flow entity without a DTO whitelist or per-field authorization check. CWE-284 (Improper Access Control) captures the root cause: the handler trusts client-supplied keys for fields that should be backend-controlled, including the tenant-scoping workspaceId. CPE pkg:npm/flowise identifies the affected component as the upstream JavaScript package rather than a specific distro build.
RemediationAI
Vendor-released patch: upgrade flowise to version 3.1.2 or later, available at https://github.com/FlowiseAI/Flowise/releases/tag/flowise%403.1.2 - this release bundles fixes for several related mass-assignment and IDOR issues (tools, variables, PUT /api/v1/user) in addition to chatflows. If immediate upgrade is not feasible, place the FlowiseAI API behind a reverse proxy (nginx, Envoy) that strips unexpected JSON keys (deployed, isPublic, workspaceId, createdDate, updatedDate, category, type) from PUT /api/v1/chatflows/{chatflowId} request bodies; this preserves legitimate name and flowData updates but blocks the mass-assignment vector at the cost of maintaining the field allowlist out-of-band. As a more restrictive compensating control in multi-tenant deployments, restrict PUT /api/v1/chatflows/* to trusted admin accounts via network ACLs or auth proxy rules until 3.1.2 is rolled out - this breaks normal user editing workflows but contains cross-workspace abuse. Audit the chat_flow table for unexpected workspaceId, isPublic=true, or deployed=true changes during the exposure window and review GHSA-5wxp-qjgq-fx6m for indicators.
Same weakness CWE-284 – Improper Access Control
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-35106
GHSA-5wxp-qjgq-fx6m