Summary
Flowise had an authorization flaw in its chatflow deletion endpoint before version 3.1.3. Because the endpoint accepted either chatflow-delete or agentflow-delete permission without verifying the resource type, an authorized user could delete the other flow type within the same workspace.
Flowise had an authorization flaw in its chatflow deletion endpoint before version 3.1.3. Because the endpoint accepted either chatflow-delete or agentflow-delete permission without verifying the resource type, an authorized user could delete the other flow type within the same workspace.
Affected context
The issue occurs in Flowise deployments where users have workspace-scoped permissions for deleting chatflows or agentflows. The deletion endpoint checked whether the caller had either permission, but the subsequent lookup identified records by ID and workspace without confirming whether the target was the permitted resource type.
The issue occurs in Flowise deployments where users have workspace-scoped permissions for deleting chatflows or agentflows. The deletion endpoint checked whether the caller had either permission, but the subsequent lookup identified records by ID and workspace without confirming whether the target was the permitted resource type.
Exploit preconditions
- Attack surface: Authenticated Flowise API access through the flow deletion endpoint
- Required access: A valid account with either
chatflows:deleteoragentflows:deletepermission - Trigger point: A deletion request targeting a flow in the caller's workspace
- Why exploitation is possible: Authorization accepts either permission while resource-type validation is omitted before deletion
- Attack surface: Authenticated Flowise API access through the flow deletion endpoint
- Required access: A valid account with either
chatflows:deleteoragentflows:deletepermission - Trigger point: A deletion request targeting a flow in the caller's workspace
- Why exploitation is possible: Authorization accepts either permission while resource-type validation is omitted before deletion
Why this happens
The vulnerability is caused by an authorization decision that does not remain bound to the resource type being accessed. The endpoint uses an any-permission check, then resolves the target using only its identifier and workspace, allowing a permission for one flow class to authorize deletion of another. This behavior maps to CWE-863: Incorrect Authorization, because access control does not correctly enforce the intended permission boundary.
The vulnerability is caused by an authorization decision that does not remain bound to the resource type being accessed. The endpoint uses an any-permission check, then resolves the target using only its identifier and workspace, allowing a permission for one flow class to authorize deletion of another. This behavior maps to CWE-863: Incorrect Authorization, because access control does not correctly enforce the intended permission boundary.
Potential impact
- An authorized user could delete chatflows without the corresponding chatflow permission
- An authorized user could delete agentflows without the corresponding agentflow permission
- Workflows, configurations, or dependent application behavior may be disrupted
- Workspace data availability and operational continuity could be affected
- An authorized user could delete chatflows without the corresponding chatflow permission
- An authorized user could delete agentflows without the corresponding agentflow permission
- Workflows, configurations, or dependent application behavior may be disrupted
- Workspace data availability and operational continuity could be affected
General mitigation guidance
Mitigation generally focuses on enforcing authorization against both the requested action and the concrete resource type.
Common defensive patterns include:
- Bind each delete operation to an explicit, server-side resource-type authorization check
- Use separate endpoints or narrowly scoped policy rules where resource classes have different permissions
- Resolve the resource and verify its type before performing any destructive action
- Apply deny-by-default authorization and avoid treating alternative permissions as interchangeable
- Limit destructive privileges to the smallest required workspace scope
- Record and review administrative deletion events for unexpected cross-resource activity
Mitigation generally focuses on enforcing authorization against both the requested action and the concrete resource type.
Common defensive patterns include:
- Bind each delete operation to an explicit, server-side resource-type authorization check
- Use separate endpoints or narrowly scoped policy rules where resource classes have different permissions
- Resolve the resource and verify its type before performing any destructive action
- Apply deny-by-default authorization and avoid treating alternative permissions as interchangeable
- Limit destructive privileges to the smallest required workspace scope
- Record and review administrative deletion events for unexpected cross-resource activity
How teams detect issues like this
Organizations can look for:
- Static analysis and code review rules that flag broad any-permission checks on destructive endpoints
- Authorization tests covering every supported resource type and permission combination
- Signals where a caller's granted permission does not match the target resource class
- Policy checks requiring resource ownership, workspace scope, and type validation before deletion
- Audit-log analysis for unusual deletion patterns across chatflows and agentflows
Automated security review tools may help identify missing object-level authorization checks.
Organizations can look for:
- Static analysis and code review rules that flag broad any-permission checks on destructive endpoints
- Authorization tests covering every supported resource type and permission combination
- Signals where a caller's granted permission does not match the target resource class
- Policy checks requiring resource ownership, workspace scope, and type validation before deletion
- Audit-log analysis for unusual deletion patterns across chatflows and agentflows
Automated security review tools may help identify missing object-level authorization checks.
