CVE-2026-69252 is a high severity (CVSS 8.8) missing authorization flaw in Flowise. Before 3.1.3, the files route enforced no permission check on GET or DELETE, so a low privileged API key could list and delete files belonging to other workspaces. Upgrade to Flowise 3.1.3.
What's affected
The record says Flowise before 3.1.3 is affected, and that the issue is fixed in 3.1.3. Fixed in Flowise 3.1.3, which the project published as a GitHub release. The release page I retrieved shows the repository as archived and read only by its owner since 13 August 2026. That does not change the advice to run 3.1.3 or later, but it does mean you should check where future security fixes will come from before you rely on this project long term.
The record says the /api/v1/files route was protected only by a feature gate and did not enforce a permission check on GET or DELETE. A low privileged authenticated API key with unrelated permissions could list files under the organization storage root, and delete files by path, because the code used the active organization and a user controlled path without restricting by permission or workspace.
I relied on the record for the technical description of this CVE. The 3.1.3 release page was the only vendor page I retrieved, and it does not give a per-CVE explanation.
How to check if you're exposed
npm ls -g flowise
docker image ls | grep -i flowise
The first command shows a global npm install, the second any Flowise container image and its tag. If you run it from a compose file or a Kubernetes manifest, read the image tag there. Anything below 3.1.3 is in scope.
Then find who can reach the affected feature. In most deployments the first control is who holds a login or an API key, so list those too. Every path described in the record needs some level of access, or in the unauthenticated case, only network reach to the service.
A quicker route for a whole project is the free in-browser dependency scan at Gold. Paste a manifest or lockfile and it matches each dependency against known CVEs, including ones pulled in indirectly.
What to do now
- Upgrade Flowise to 3.1.3 or later and redeploy all instances, including containers built from older images.
- Review all API keys and revoke those you do not recognise or that are unused.
- Back up the organization storage so deleted files can be restored.
- Check storage for missing files across workspaces since you began running an affected version.
- Issue keys per workspace with the narrowest permissions that work.
- Check whether the project's archived status affects your support plan, and decide on an owner for security updates.
- Run Flowise behind authentication and a network boundary, and do not expose its admin or API ports directly to the internet.
Reachability analysis helps with ordering the work. Knowing whether your code actually calls the affected path tells you which services to patch first.
Why it matters
The weakness is CWE-862, missing authorization. Authentication told the server who was calling. Nothing then asked whether that caller was allowed to touch these files, or whether the files belonged to the caller's workspace.
For teams that use workspaces to separate projects or customers, this breaks the boundary the workspaces are meant to provide. The harm in the record is both disclosure of file names and deletion of other workspaces' files. The record does not mark this CVE as known exploited.
Quick check
Is an API key enough to exploit it?
The record says a low privileged authenticated API key with unrelated permissions could do it.
What is the damage?
Listing files in the organization storage root, and deleting files that belong to other workspaces.
Sources
- https://github.com/FlowiseAI/Flowise/releases/tag/flowise@3.1.3
- Record: NVD entry for CVE-2026-69252 (score 8.8, HIGH)
Last reviewed: 18 October 2026.
