CVE-2026-69252 Overview
CVE-2026-69252 is a missing authorization vulnerability [CWE-862] in Flowise, a drag-and-drop interface for building large language model workflows. Versions prior to 3.1.3 expose the /api/v1/files route without enforcing permission checks on GET or DELETE methods. The route relies only on the feat:files feature gate. A low-privileged authenticated API key with unrelated permissions can list files under the organization storage root and delete files belonging to other workspaces in the same organization. The getAllFiles and deleteFile handlers use activeOrganizationId and a user-controlled path without validating permissions or activeWorkspaceId.
Critical Impact
Any authenticated API key holder can enumerate and delete files across all workspaces within the same Flowise organization, breaking tenant isolation and enabling cross-workspace data destruction.
Affected Products
- Flowise versions prior to 3.1.3
- FlowiseAI Flowise LLM workflow builder
- Multi-tenant Flowise deployments sharing an organization scope
Discovery Timeline
- 2026-08-04 - CVE-2026-69252 published to NVD
- 2026-08-04 - Last updated in NVD database
Technical Details for CVE-2026-69252
Vulnerability Analysis
The /api/v1/files route in Flowise supports file listing and deletion for stored workflow assets. Route protection consists of a single feature gate, feat:files, without invocation of the checkPermission middleware used elsewhere in the codebase. Authenticated callers holding any API key that satisfies the feature gate can therefore reach both the GET and DELETE handlers regardless of their assigned role or scope.
Inside those handlers, getAllFiles and deleteFile scope requests only by activeOrganizationId. Neither function checks activeWorkspaceId, nor does either validate that the caller has file-management permissions. The path parameter passed to DELETE /api/v1/files?path=... is user-controlled and used directly against the organization storage root. This confuses two distinct trust boundaries: organization membership and workspace ownership.
Root Cause
The root cause is a missing authorization check [CWE-862]. Access control was implemented at the feature-flag layer instead of the per-action permission layer. Workspace isolation was never enforced in the file handlers.
Attack Vector
An attacker with a low-privileged API key in the target organization sends GET /api/v1/files to enumerate every file in the organization storage root. The attacker then calls DELETE /api/v1/files?path=<victim-workspace-file> to remove assets belonging to other workspaces. No elevated role, social engineering, or user interaction is required.
// Security patch in packages/server/src/utils/constants.ts
// Source: https://github.com/FlowiseAI/Flowise/commit/bc22bf8baec95b6a3d6e1b3563b4f03491cd6fbb
-export const API_KEY_BLACKLIST_URLS = ['/api/v1/nvidia-nim', '/api/v1/account/delete']
+export const API_KEY_BLACKLIST_URLS = ['/api/v1/nvidia-nim', '/api/v1/account/delete', '/api/v1/files']
The fix adds /api/v1/files to the API key blacklist, blocking access via low-privileged API keys. See the GitHub Pull Request for the complete route wiring changes.
Detection Methods for CVE-2026-69252
Indicators of Compromise
- Unexpected GET /api/v1/files requests originating from API keys that do not own file-management permissions.
- DELETE /api/v1/files?path= requests referencing paths outside the caller's own workspace directory.
- Sudden disappearance of workflow assets, uploads, or attachments in workspaces whose owners did not initiate deletion.
- HTTP 200 responses to /api/v1/files calls from API key subjects that historically never accessed that route.
Detection Strategies
- Parse Flowise access logs and alert on any /api/v1/files request whose authenticated subject is an API key rather than a session user.
- Correlate DELETE /api/v1/files events with the caller's activeWorkspaceId and flag path values that resolve outside that workspace.
- Baseline normal file-API usage per API key and alert on volumetric enumeration patterns.
Monitoring Recommendations
- Forward Flowise application logs and reverse-proxy access logs to a centralized logging platform for retention and query.
- Monitor for the CVE-2026-69252 GitHub Security Advisory GHSA-wp74-f5hh-5f3r references in vulnerability scanners.
- Track Flowise version strings across deployments and alert when any instance reports a version below 3.1.3.
How to Mitigate CVE-2026-69252
Immediate Actions Required
- Upgrade Flowise to version 3.1.3 or later, as published in the Flowise 3.1.3 release notes.
- Rotate all Flowise API keys after upgrading to invalidate any keys that may have been abused.
- Audit file storage for missing or unexpectedly deleted assets and restore from backup where necessary.
- Review API key permission assignments and remove keys that do not require file access.
Patch Information
The fix is delivered in Flowise 3.1.3 via commit bc22bf8baec95b6a3d6e1b3563b4f03491cd6fbb. The patch adds /api/v1/files to the API_KEY_BLACKLIST_URLS constant, preventing API key authentication from reaching the vulnerable route. See the GitHub Commit Details for the full diff.
Workarounds
- Block /api/v1/files at a reverse proxy or ingress layer for requests carrying API key authentication headers if immediate upgrade is not possible.
- Restrict network access to the Flowise API to trusted management networks only.
- Reduce the blast radius by segmenting Flowise organizations so that untrusted tenants do not share an activeOrganizationId.
# Example nginx snippet blocking API-key access to the vulnerable route
location = /api/v1/files {
if ($http_authorization ~* "^Bearer ") {
return 403;
}
proxy_pass http://flowise_upstream;
}
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

