CVE-2026-69262 is a high severity (CVSS 8.1) incorrect authorization flaw in Flowise. Before 3.1.3, the chatflow delete route accepted either chatflows:delete or agentflows:delete and did not check the target type. Users with one permission can delete the other kind of flow. 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 DELETE /api/v1/chatflows/:id authorized requests with a check for either permission, so having either was enough to reach the delete path. The delete logic then found the record by id and workspace only, without checking its type. A caller with only agentflows:delete could delete a chatflow, and a caller with only chatflows:delete could delete an agentflow, in the same 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.
- Export or back up chatflows and agentflows regularly.
- Review which users and API keys hold either delete permission and remove it where it is not needed.
- Check audit logs for unexpected deletions since you started running an affected version.
- Restore missing flows from backup after upgrading.
- 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-863, incorrect authorization. The permission model had two separate rights, but one route served both resource types and accepted either right for either type. The check was real, but it was attached to the wrong question.
The impact is limited to the same workspace and is a loss of availability and work, not a code execution path. Still, deleted flows can mean lost production assistants. Back up your flows. The record does not mark this CVE as known exploited.
Quick check
Does it cross workspaces?
The record describes deletion within the same workspace.
What is lost?
Chatflows or agentflows that the caller was not meant to be able to delete.
Sources
- https://github.com/FlowiseAI/Flowise/releases/tag/flowise@3.1.3
- Record: NVD entry for CVE-2026-69262 (score 8.1, HIGH)
Last reviewed: 18 October 2026.
