### 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: 1. deployed 2. isPublic 3. workspaceId 4. createdDate 5. updatedDate 6. category 7. 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: ```json { "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: ```http 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: ```json { "deployed": true, "isPublic": true, "workspaceId": "11111111-2222-3333-4444-555555555555" } ``` Verify in the database that the chatflow has been reassigned: ```sql 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.
### 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: 1. deployed 2. isPublic 3. workspaceId 4. createdDate 5. updatedDate 6. category 7. 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: ```json { "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: ```http 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: ```json { "deployed": true, "isPublic": true, "workspaceId": "11111111-2222-3333-4444-555555555555" } ``` Verify in the database that the chatflow has been reassigned: ```sql 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.
### 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: 1. deployed 2. isPublic 3. workspaceId 4. createdDate 5. updatedDate 6. category 7. 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: ```json { "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: ```http 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: ```json { "deployed": true, "isPublic": true, "workspaceId": "11111111-2222-3333-4444-555555555555" } ``` Verify in the database that the chatflow has been reassigned: ```sql 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.
### 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: 1. deployed 2. isPublic 3. workspaceId 4. createdDate 5. updatedDate 6. category 7. 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: ```json { "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: ```http 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: ```json { "deployed": true, "isPublic": true, "workspaceId": "11111111-2222-3333-4444-555555555555" } ``` Verify in the database that the chatflow has been reassigned: ```sql 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.
Update flowise to 3.1.2 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanFlowiseAI has Mass Assignment in Chatflow Update Endpoint that Allows Cross-Workspace AgentFlow Reassignment affects flowise (npm). Severity is high. ### 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: 1. deployed 2. isPublic 3. workspaceId 4. createdDate 5. updatedDate 6. category 7. 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: ```json { "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: ```http 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: ```json { "deployed": true, "isPublic": true, "workspaceId": "11111111-2222-3333-4444-555555555555" } ``` Verify in the database that the chatflow has been reassigned: ```sql 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.
AI coding agents often install or upgrade packages automatically in npm. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| flowisenpm | <=3.1.1 | 3.1.2 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate flowise to 3.1.2 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanFlowiseAI has Mass Assignment in Chatflow Update Endpoint that Allows Cross-Workspace AgentFlow Reassignment affects flowise (npm). Severity is high. ### 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: 1. deployed 2. isPublic 3. workspaceId 4. createdDate 5. updatedDate 6. category 7. 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: ```json { "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: ```http 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: ```json { "deployed": true, "isPublic": true, "workspaceId": "11111111-2222-3333-4444-555555555555" } ``` Verify in the database that the chatflow has been reassigned: ```sql 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.
AI coding agents often install or upgrade packages automatically in npm. A high vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| flowisenpm | <=3.1.1 | 3.1.2 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard