CVE-2026-70472 is a high severity (CVSS 8.8) authorization flaw in Flowise before 3.1.3. The openai-assistants-vector-store endpoints load a stored credential by id without checking which workspace owns it, so a user can act with another workspace's OpenAI key. The fix is Flowise 3.1.3.
What's affected
Flowise (npm package flowise) versions up to and including 3.1.2, fixed in 3.1.3, according to the GitHub advisory, which rates it high.
The weaknesses are CWE-285 (improper authorization) and CWE-863 (incorrect authorization). The route permissions named assistants:* only check feature access. The controller passes the credential value from the query string to the service, and the service looks up the credential by id alone, decrypts it and calls OpenAI APIs. No workspace check happens.
The advisory lists the impact: cross-workspace use of stored OpenAI keys, reading, changing or deleting vector stores and files in another workspace, and billing on the victim's OpenAI account. The attacker needs to know another workspace's credential id.
How to check if you're exposed
Check the installed version. For an npm install:
npm ls flowise
For Docker, read the image tag you run, and check the version shown in the Flowise interface. Anything before 3.1.3 is affected.
Then look at how you run it. The Flowise maintainers announced they are sunsetting the project, with the repository archived on 10 August 2026 and the npm packages and Docker images marked deprecated. The sunset page states that the code stays available under Apache 2.0 for forks. If you stay on Flowise, you own the patching, so plan who does it.
free in-browser dependency scan reads a package manifest in your browser and shows known vulnerabilities, including this one for the flowise npm package.
What to do now
- Check your Flowise version with npm ls flowise or the image tag.
- Upgrade to 3.1.3 or later, or to the build your fork maintains.
- Decide whether to stay on a project that is being wound down, or migrate.
- Review access logs for the affected routes for requests you do not recognize.
- Rotate any credentials stored in Flowise that other workspaces could have reached.
Why it matters
Authorization checks that stop at feature access are a recurring pattern in multi-tenant apps. The user may use the assistants feature, so the route allows them. Nobody asked whether this particular credential belongs to this user's workspace.
This is an insecure direct object reference. The fix pattern is to scope every lookup by the caller's workspace, as the advisory notes other code paths in the same project already do. Credential ids are not secret, they appear in URLs and logs, so they must never be the only thing protecting an object.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does the attacker need to be logged in?
Yes. The vector requires low privileges, and the advisory describes a user in one workspace using the credential id of another. They must also know the victim credential id.
Sources
Last reviewed: 18 October 2026.
