CVE-2026-69262: Flowise Auth Bypass Vulnerability

CVE-2026-69262 Overview

CVE-2026-69262 is a broken access control vulnerability [CWE-863] in Flowise, a drag-and-drop interface for building large language model (LLM) workflows. Versions prior to 3.1.3 authorize DELETE /api/v1/chatflows/:id requests using checkAnyPermission('chatflows:delete,agentflows:delete'). The delete handler resolves the target record only by id and workspaceId without validating the resource type. An authenticated user holding agentflows:delete can delete a CHATFLOW, and a user holding only chatflows:delete can delete an AGENTFLOW within the same workspace. The issue is resolved in Flowise version 3.1.3.

Critical Impact
An authenticated workspace user with a single delete permission can destroy resource types they were never granted access to, resulting in loss of LLM workflow availability.

Affected Products

FlowiseAI Flowise versions prior to 3.1.3
Deployments exposing /api/v1/chatflows/:id DELETE route
Multi-tenant workspaces sharing both chatflow and agentflow resources

Discovery Timeline

2026-08-04 - CVE-2026-69262 published to NVD
2026-08-05 - Last updated in NVD database
Flowise 3.1.3 - FlowiseAI releases patched version resolving the authorization flaw

Technical Details for CVE-2026-69262

Vulnerability Analysis

The flaw resides in the Express route definition for chatflow deletion within packages/server/src/routes/chatflows/index.ts. The DELETE handler is gated by checkAnyPermission('chatflows:delete,agentflows:delete'), which returns success when the caller holds either permission. Downstream, the controller in packages/server/src/controllers/chatflows/index.ts retrieves the target record using only the id and workspaceId fields.

The controller does not compare the caller's granted permission against the resolved record's type (CHATFLOW, AGENTFLOW, or ASSISTANT). This missing type check breaks the permission model that Flowise otherwise enforces at the API boundary. The vulnerability class is authorization bypass through improper resource type validation.

Root Cause

The root cause is a mismatch between coarse-grained permission gating and fine-grained resource typing. Flowise separates permissions per resource type (chatflows:delete, agentflows:delete, assistants:delete), but the shared delete route accepts any of them and then dispatches to a single controller that ignores type. Authorization is granted based on possession of a permission, not on whether that permission applies to the specific resource being deleted.

Attack Vector

An authenticated user in a Flowise workspace with only agentflows:delete sends DELETE /api/v1/chatflows/:id where :id references a chatflow. The permission check passes because the caller holds one of the accepted permissions. The controller loads the chatflow by id and workspaceId, then deletes it. The same primitive works in reverse: a user with only chatflows:delete can delete agentflows in the same workspace.

typescript

// Fix applied in packages/server/src/routes/chatflows/index.ts
// DELETE
-router.delete(['/', '/:id'], checkAnyPermission('chatflows:delete,agentflows:delete'), chatflowsController.deleteChatflow)
+router.delete(['/', '/:id'], checkAnyPermission('chatflows:delete,agentflows:delete,assistants:delete'), chatflowsController.deleteChatflow)

// Source: https://github.com/FlowiseAI/Flowise/commit/2f528ceced74afaa95fc7a282965e7788796448b

The controller was also updated to import EnumChatflowType and validate the resolved record's type against the caller's permissions before executing the delete.

Detection Methods for CVE-2026-69262

Indicators of Compromise

Unexpected DELETE /api/v1/chatflows/:id requests from users lacking full chatflow management roles
Missing chatflow or agentflow records in workspaces where administrators did not authorize removal
Audit log entries showing delete operations by principals holding a single narrow delete permission

Detection Strategies

Correlate Flowise application audit logs against the caller's assigned workspace permissions to flag cross-type deletions
Deploy a reverse proxy or API gateway rule that logs the requesting principal, target id, and inferred resource type for all DELETE calls to /api/v1/chatflows/*
Compare deleted record types against caller permission scopes and alert on mismatches

Monitoring Recommendations

Enable verbose logging on Flowise permission middleware to capture every checkAnyPermission decision
Track baseline delete rates per workspace and alert on volume spikes indicative of enumeration or mass deletion
Retain database-level deletion events for chatflow and agentflow tables to support post-incident reconstruction

How to Mitigate CVE-2026-69262

Immediate Actions Required

Upgrade Flowise to version 3.1.3 or later across all deployments
Audit existing workspace role assignments and revoke unnecessary chatflows:delete or agentflows:delete grants
Review recent deletion events in application and database logs to identify unauthorized removals prior to patching

Patch Information

The fix is delivered in Flowise 3.1.3. The corrective commit adds resource type validation in the delete controller and expands the permission list on the delete route to include assistants:delete. Review the GitHub Security Advisory GHSA-p5w8-m249-4r4v, the pull request #6445, and the Flowise 3.1.3 release notes before rolling out.

Workarounds

Restrict access to the Flowise instance to trusted operators until the upgrade is applied
Remove the DELETE route at the reverse proxy layer for workspaces that cannot upgrade immediately
Segregate chatflow and agentflow assets into separate workspaces so a single-permission compromise cannot reach the other type

bash

# Example NGINX rule to block DELETE on chatflows until patched
location ~ ^/api/v1/chatflows/ {
    limit_except GET POST PUT {
        deny all;
    }
    proxy_pass http://flowise_upstream;
}