CVE-2026-69262: Incorrect Authorization Flaw in Flowise Chatflow Deletion Endpoint

Flowise is an open-source, low-code platform designed for orchestrating and managing large language model (LLM) workflows. The platform exposes administrative and configuration interfaces via HTTP REST APIs, allowing users to build, run, and modify agents, vector stores, and conversational pipelines. The core of this functionality relies on the Express-based backend server component, which exposes various APIs for managing entity data and session state.

This vulnerability, tracked as CVE-2026-69262 (GHSA-p5w8-m249-4r4v), is classified under CWE-863: Incorrect Authorization. In collaborative or multi-tenant deployment scenarios, access to specific entity types like chatflows, agentflows, or assistants is governed by granular permission roles. However, the system's deletion workflow failed to properly enforce these boundaries, exposing the internal state to unauthorized operations.

Because the backend did not cross-reference the entity type of the target database record with the caller's specific permission scope, the deletion endpoint allowed users to modify resources beyond their assigned roles. The attack surface is accessible to any authenticated user with at least some basic deletion permissions, presenting a significant threat to resource integrity and service availability in multi-user environments.

The root cause of this vulnerability lies in a structural mismatch between the route-level middleware definitions and the downstream service-level verification logic. Flowise routes utilize an Express middleware helper called checkAnyPermission to filter requests based on permission groups. For the chatflow deletion endpoint (DELETE /api/v1/chatflows/:id), the middleware was initialized to allow access to users holding either chatflow or agentflow deletion privileges.

This configuration behaves as a logical OR statement. If the requesting user possesses agentflows:delete but lacks chatflows:delete, the middleware successfully validates the request and passes execution to chatflowsController.deleteChatflow. The routing logic assumes that the downstream controller or service will perform more precise validation, but this critical verification was absent.

Once the controller received the request, it forwarded the target identifier (:id) directly to chatflowsService.deleteChatflow. The service queried the database, retrieved the ChatFlow object, and directly invoked the database delete function. Because both chatflows and agentflows reside within the same database table and share identical identifier formats, the application deleted the resource without checking if the user possessed the specific permission corresponding to the resource's type attribute.

To completely remediate this flaw, the Flowise development team modified the routing, controller, and service-level components to enforce type mapping. Instead of relying solely on the routing middleware, the system now maps the user's explicit permissions to a restricted set of allowed database entity types before performing the database operation.

Below is the vulnerable controller logic contrasted with the patched controller implementation in packages/server/src/controllers/chatflows/index.ts:

// VULNERABLE CONTROLLER LOGIC
const deleteChatflow = async (req: Request, res: Response, next: NextFunction) => {
    try {
        // Directly passes parameters to service without evaluating user permission types
        const apiResponse = await chatflowsService.deleteChatflow(req.params.id, orgId, workspaceId)
        return res.json(apiResponse)
    } catch (error) {
        next(error)
    }
}

// PATCHED CONTROLLER LOGIC
const deleteChatflow = async (req: Request, res: Response, next: NextFunction) => {
    try {
        const userPermittedTypes: EnumChatflowType[] = []
        const permissions = req.user!.permissions
        if (req.user?.isOrganizationAdmin) {
            // Administrators automatically acquire all permissions
            userPermittedTypes.push(EnumChatflowType.CHATFLOW)
            userPermittedTypes.push(EnumChatflowType.AGENTFLOW)
            userPermittedTypes.push(EnumChatflowType.MULTIAGENT)
            userPermittedTypes.push(EnumChatflowType.ASSISTANT)
        } else {
            // Map explicit permission strings to database enum values
            if (permissions.includes(`chatflows:delete`)) userPermittedTypes.push(EnumChatflowType.CHATFLOW)
            if (permissions.includes(`agentflows:delete`)) {
                userPermittedTypes.push(EnumChatflowType.AGENTFLOW)
                userPermittedTypes.push(EnumChatflowType.MULTIAGENT)
            }
            if (permissions.includes(`assistants:delete`)) userPermittedTypes.push(EnumChatflowType.ASSISTANT)
            if (userPermittedTypes.length === 0)
                throw new InternalFlowiseError(StatusCodes.FORBIDDEN, `You do not have permission to delete any chatflow types`)
        }
        // Pass mapped userPermittedTypes downstream
        const apiResponse = await chatflowsService.deleteChatflow(req.params.id, orgId, workspaceId, userPermittedTypes)
        return res.json(apiResponse)
    } catch (error) {
        next(error)
    }
}

Following the controller refactoring, the corresponding service component in packages/server/src/services/chatflows/index.ts was patched to validate the fetched record against the permitted array:

// PATCHED SERVICE LAYER LOGIC
const deleteChatflow = async (
    chatflowId: string,
    orgId: string,
    workspaceId: string,
    userPermittedTypes: EnumChatflowType[]
): Promise<any> => {
    try {
        const appServer = getRunningExpressApp()
        const chatflow = await getChatflowById(chatflowId, workspaceId)
        
        // Assert that the fetched flow's type attribute is included in the user's permitted types
        if (!userPermittedTypes.includes(chatflow.type as EnumChatflowType))
            throw new InternalFlowiseError(StatusCodes.FORBIDDEN, `You do not have permission to delete this chatflow type`)
 
        const dbResponse = await appServer.AppDataSource.getRepository(ChatFlow).delete({ id: chatflowId })

Exploitation of CVE-2026-69262 requires authenticated access to a target Flowise workspace, with the attacker possessing a session token assigned with limited deletion capabilities. An attacker lacking any deletion rights is stopped at the routing level, making this vulnerability inaccessible to unauthenticated external threats.

Once authenticated, the attacker identifies the UUID of the target chatflow to be deleted. Because these flow identifiers are represented as UUIDs, they must first be obtained via normal interface usage, application logging, or related endpoint read operations. Once the identifier is obtained, the attacker transmits a direct HTTP DELETE request to the vulnerable endpoint.

The exploit can be reproduced using a standard command-line HTTP utility. The following proof-of-concept curl command executes the deletion of a targeted chatflow using an agentflow editor's authorization header:

curl -X DELETE "http://target-host:3000/api/v1/chatflows/9b1deb4d-3b7d-4bad-9bdd-2b0d7b3dcb6d" \
  -H "Authorization: Bearer <agentflow_editor_token>" \
  -H "Content-Type: application/json"

In vulnerable configurations, this request will result in an HTTP 200 OK response status, and the chatflow database entry is permanently removed. Following the application of the patch, this exact request triggers an HTTP 403 Forbidden response and an error payload stating: You do not have permission to delete this chatflow type.

The primary operational consequence of this vulnerability is localized denial of service and data destruction. Deleting a chatflow permanently removes its design blueprints, conversational nodes, and integration endpoints. Any application, API client, or customer-facing chatbot relying on the deleted flow's unique identifier will immediately cease functioning.

According to the official CVE record, this vulnerability carries a CVSS v4.0 Base Score of 7.1 (High). The high severity classification is driven by the low attack complexity and the lack of specific user interaction required to execute the exploit. While it does not lead to information disclosure or remote system compromise, its impact on the availability of dependent applications is significant.

No active exploitation in the wild or public exploit code has been identified, and the vulnerability is not currently listed in CISA's Known Exploited Vulnerabilities catalog. However, in shared environments where different teams configure distinct business flows on a single host, this vulnerability introduces a lateral security boundary failure.

The definitive resolution for CVE-2026-69262 is upgrading the Flowise instance to version 3.1.3 or higher. Because the patch resolves the vulnerability at the application layer via controller checks, no database modifications or structural changes to existing database records are needed.

To perform the upgrade using npm or pnpm, execute the corresponding command for your deployment model:

# Global deployment upgrade
npm install -g flowise@3.1.3
 
# Project-level dependency upgrade
npm install flowise@3.1.3

If upgrading immediately is not possible, administrators should restrict workspace access to highly trusted users. Additionally, security teams can configure monitoring systems to alert on HTTP DELETE traffic directed at the /api/v1/chatflows/ path. Cross-correlating these events with active user permission logs can help detect unauthorized deletion attempts before they occur in production.

Security teams should also review other CRUD endpoints (such as PUT /api/v1/chatflows/:id) to ensure they do not permit type mutation bypasses. Allowing users to alter the type attribute of a flow during an update could enable them to alter the permission domain of an existing resource.