CVE-2026-69252: Broken Workspace Isolation and Missing Authorization in Flowise File Management API

Flowise serves as a graphical user interface and orchestrator for assembling customized Large Language Model (LLM) processing chains. To facilitate this, the system exposes a web UI and a set of backend HTTP APIs to handle storage, prompt management, and workflow parameters.\n\nWithin multi-tenant or multi-user enterprise deployments, Flowise relies on 'workspaces' to maintain isolation boundaries between different teams, projects, or users. Assets uploaded to one workspace must remain inaccessible to users of other workspaces, even if those users share the same parent organization structure.\n\nPrior to version 3.1.3, Flowise failed to enforce workspace-level authorization checks on the file management endpoint (/api/v1/files). While authentication was validated, individual authorization checks (checkPermission) were omitted entirely. Consequently, any authenticated API key—regardless of its scoped permissions—could invoke actions to retrieve directory listings and delete files globally within the parent organization directory.

The core defect lies in a combination of Missing Function-Level Access Control (CWE-862) and Broken Object-Level Authorization (BOLA). In the Express routing layer of Flowise, the endpoint registration failed to bundle proper role-based access control or workspace verification middleware.\n\nInstead, the route relied exclusively on a plan-based feature gate:\ntypescript\nrouter.use('/files', IdentityManager.checkFeatureByPlan('feat:files'), filesRouter)\n\nThis check only validated that the organization's subscription tier or configuration had the file manager enabled. It did not perform any validation of user permissions or logical boundaries.\n\nInside the controllers, the file operations were executed with organizational scope rather than workspace scope. When listing files, the backend retrieved all files under the directory path constructed using activeOrganizationId, disregarding the requester's activeWorkspaceId. For deletion operations, the system accepted a relative path and concatenated it to the organization's base directory, allowing a malicious actor to supply paths targeting files belonging to different workspaces.

To understand the logical failure, it is useful to visualize the flow of requests through the vulnerable components.\n\nmermaid\ngraph LR\n Attacker[\"Attacker (Low-Privilege API Key)\"] -->|\"GET/DELETE /api/v1/files\"| Router[\"Express Route Router\"]\n Router -->|\"Only checks plan feature\"| Controller[\"Files Controller\"]\n Controller -->|\"No checkPermission validation\"| Storage[\"Organization Storage Root\"]\n Storage -->|\"Accesses files in sibling workspace\"| VictimWorkspace[\"Victim Workspace Files\"]\n\n\nThe vulnerability was resolved in commit bc22bf8baec95b6a3d6e1b3563b4f03491cd6fbb by disabling the endpoint entirely. Below is an examination of the changes applied in the patch.\n\nIn packages/server/src/routes/index.ts, the files router was commented out to completely strip the attack surface:\ndiff\n-import filesRouter from './files'\n...\n-router.use('/files', IdentityManager.checkFeatureByPlan('feat:files'), filesRouter)\n+// router.use('/files', IdentityManager.checkFeatureByPlan('feat:files'), filesRouter)\n\n\nAdditionally, the API endpoint was hard-coded into the API key blacklist array in packages/server/src/utils/constants.ts to prevent standard API keys from accessing the route even if it is active:\ndiff\n-export const API_KEY_BLACKLIST_URLS = ['/api/v1/nvidia-nim', '/api/v1/account/delete']\n+export const API_KEY_BLACKLIST_URLS = ['/api/v1/nvidia-nim', '/api/v1/account/delete', '/api/v1/files']\n\n\nThis remediation path represents a temporary 'fail-secure' strategy. The complete removal of the feature eliminates the vulnerability but leaves the software without file manager functionality until a robust, workspace-aware permission model is integrated.

Exploitation of CVE-2026-69252 requires the attacker to possess an authenticated session or a valid API key within the organization. Even an API key restricted to minor scopes, such as tools:view, is sufficient because the target controller does not query key permissions.\n\nTo list the contents of sibling workspaces, an attacker makes a standard GET request to the file API:\nbash\ncurl -i \\\n -H 'Authorization: Bearer <low_privilege_api_key>' \\\n http://localhost:8080/api/v1/files\n\nIf files are present, the server responds with an array of objects. Each object reveals the underlying directory structure, disclosing the target workspace IDs:\njson\n[\n {\n \"name\": \"confidential_keys.txt\",\n \"path\": \"f92a9a4d-392e-4db2-af82-d14e1d553446/confidential_keys.txt\",\n \"size\": 128\n }\n]\n\n\nWith the leaked workspace ID and filename, the attacker can execute an unauthorized deletion. The attacker sends a DELETE request with the path pointing to the sibling workspace file:\nbash\ncurl -i -X DELETE --get \\\n -H 'Authorization: Bearer <low_privilege_api_key>' \\\n --data-urlencode 'path=f92a9a4d-392e-4db2-af82-d14e1d553446/confidential_keys.txt' \\\n http://localhost:8080/api/v1/files\n\nThe server processes the deletion directly, returning {\"message\": \"file_deleted\"}. No checks are executed to verify if the requesting API key possesses write or deletion permissions in workspace f92a9a4d-392e-4db2-af82-d14e1d553446.

The impact of CVE-2026-69252 is twofold, affecting both the confidentiality and availability of sensitive deployment data. In enterprise environments, LLM orchestrators often host sensitive training sets, system prompts, API keys, and corporate documents containing proprietary information.\n\nFirst, the disclosure of file listings allows low-privileged insiders or compromised API tokens to map out the entire document library of the organization. This facilitates targeted data exfiltration by revealing the exact locations and filenames of private assets.\n\nSecond, the cross-workspace deletion capabilities introduce severe availability risks. Because LLM pipelines often rely on persistent document stores, vector databases, or local configurations to function, the deletion of these assets can disrupt user-facing services. This constitutes a full denial-of-service capability on dependent LLM agents.

To resolve CVE-2026-69252, operators must upgrade their installations of Flowise to version 3.1.3 or higher. The update implements the complete deprecation of the /api/v1/files routes on both the backend and frontend.\n\nFor instances where an immediate upgrade is not feasible, security administrators should deploy manual mitigations. This can be accomplished by editing the routing files locally inside packages/server/src/routes/index.ts to comment out the /files endpoint registration, matching the modifications implemented in the official patch.\n\nAdditionally, detection of exploitation attempts can be achieved through web server log analysis. Security Operations Centers (SOCs) should monitor for any DELETE requests aimed at /api/v1/files and inspect the path URL parameter for attempts to reference folders outside of the user's active workspace. Any access to /api/v1/files by low-privileged API tokens should be investigated as unauthorized activity.