CVE-2026-69262

Flowise is a drag & drop user interface to build a customized large language model flow. Prior to 3.1.3, DELETE /api/v1/chatflows/:id authorized requests with checkAnyPermission('chatflows:delete,agentflows:delete'), so possession of either permission was sufficient to reach the delete path. The delete logic then resolved the target record only by id and workspaceId and did not validate the target resource type, allowing a caller with only agentflows:delete to delete a CHATFLOW and a caller with only chatflows:delete to delete an AGENTFLOW in the same workspace. This issue is fixed in version 3.1.3.

Flowise is a drag & drop user interface to build a customized large language model flow. Prior to 3.1.3, DELETE /api/v1/chatflows/:id authorized requests with checkAnyPermission('chatflows:delete,agentflows:delete'), so possession of either permission was sufficient to reach the delete path. The delete logic then resolved the target record only by id and workspaceId and did not validate the target resource type, allowing a caller with only agentflows:delete to delete a CHATFLOW and a caller with only chatflows:delete to delete an AGENTFLOW in the same workspace. This issue is fixed in version 3.1.3.

summary:

In Flowise, DELETE /api/v1/chatflows/:id authorizes requests with checkAnyPermission('chatflows:delete,agentflows:delete'). Possession of either permission is sufficient to reach the delete path. The delete logic does not validate the target resource type, allowing a caller with only agentflows:delete to delete a CHATFLOW, and a caller with only chatflows:delete to delete an AGENTFLOW.

details:

The delete route accepts either chatflows:delete or agentflows:delete. The subsequent logic only resolves the target record by id and workspaceId, then deletes by id without checking whether the target resource type matches the granted permission domain.

As a result, there is no binding between permission scope and flow type:

• agentflows:delete can be used to delete CHATFLOW
• chatflows:delete can be used to delete AGENTFLOW

This breaks the intended RBAC separation between Chatflows and Agentflows.

impact:

Users authorized to manage only one flow type can delete the other flow type within the same workspace, resulting in unauthorized deletion and configuration loss.

reproduction steps:

1. Log in as a user who can create API keys.
2. Create a normal CHATFLOW and record its id.
3. Create an API key with only agentflows:delete.
4. Use that API key to send:

curl -i -X DELETE \
  -H 'Authorization: Bearer <agentflows_delete_only_key>' \
  http://localhost:8080/api/v1/chatflows/<chatflow_id>

5. Observe a 200 OK response, for example:

{"raw":[],"affected":1}

6. Read the same id again and observe 404 Not Found.

Flowise is a drag & drop user interface to build a customized large language model flow. Prior to 3.1.3, DELETE /api/v1/chatflows/:id authorized requests with checkAnyPermission('chatflows:delete,agentflows:delete'), so possession of either permission was sufficient to reach the delete path. The delete logic then resolved the target record only by id and workspaceId and did not validate the target resource type, allowing a caller with only agentflows:delete to delete a CHATFLOW and a caller with only chatflows:delete to delete an AGENTFLOW in the same workspace. This issue is fixed in version 3.1.3.

Flowise is a drag & drop user interface to build a customized large language model flow. Prior to 3.1.3, DELETE /api/v1/chatflows/:id authorized requests with checkAnyPermission('chatflows:delete,agentflows:delete'), so possession of either permission was sufficient to reach the delete path. The delete logic then resolved the target record only by id and workspaceId and did not validate the target resource type, allowing a caller with only agentflows:delete to delete a CHATFLOW and a caller with only chatflows:delete to delete an AGENTFLOW in the same workspace. This issue is fixed in version 3.1.3.

summary:

In Flowise, DELETE /api/v1/chatflows/:id authorizes requests with checkAnyPermission('chatflows:delete,agentflows:delete'). Possession of either permission is sufficient to reach the delete path. The delete logic does not validate the target resource type, allowing a caller with only agentflows:delete to delete a CHATFLOW, and a caller with only chatflows:delete to delete an AGENTFLOW.

details:

The delete route accepts either chatflows:delete or agentflows:delete. The subsequent logic only resolves the target record by id and workspaceId, then deletes by id without checking whether the target resource type matches the granted permission domain.

As a result, there is no binding between permission scope and flow type:

• agentflows:delete can be used to delete CHATFLOW
• chatflows:delete can be used to delete AGENTFLOW

This breaks the intended RBAC separation between Chatflows and Agentflows.

impact:

Users authorized to manage only one flow type can delete the other flow type within the same workspace, resulting in unauthorized deletion and configuration loss.

reproduction steps:

1. Log in as a user who can create API keys.
2. Create a normal CHATFLOW and record its id.
3. Create an API key with only agentflows:delete.
4. Use that API key to send:

curl -i -X DELETE \
  -H 'Authorization: Bearer <agentflows_delete_only_key>' \
  http://localhost:8080/api/v1/chatflows/<chatflow_id>

5. Observe a 200 OK response, for example:

{"raw":[],"affected":1}

6. Read the same id again and observe 404 Not Found.