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`…
GitHub_M·CWE-863·Published 2026-08-04
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: ```bash 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: ```json {"raw":[],"affected":1} ``` 6. Read the same `id` again and observe `404 Not Found`.
| Version | Type | Source | Base | Exp | Impact | Vector |
|---|---|---|---|---|---|---|
| 4.0 | Primary | cve.org | 7.1 | — | — | CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N |
| 4.0 | Secondary | GHSA | 7.1 | — | — | CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N |
| 4.0 | Secondary | NVD | 7.1 | — | — | CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/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 |
| 4.0 | Secondary | ENISA EUVD | 7.1 | — | — | CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N |