CVE-2026-70474 is a high severity (CVSS 8.1) authorization flaw in Flowise before 3.1.3. Three OAuth2 credential endpoints look up credentials by id with no workspace filter, and two of them skip authentication. 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, per the GitHub advisory.
The weakness is CWE-863, incorrect authorization. The authorize, callback and refresh handlers query the credential table by id only. Callback and refresh are on the authentication whitelist. The advisory summarizes three consequences: any signed in user can start OAuth2 flows against credentials in other workspaces, an unauthenticated party can forge a callback to overwrite tokens in any credential, and an unauthenticated party can refresh tokens for any credential.
The record's vector shows low privileges required, while the advisory text describes unauthenticated paths for two of the endpoints. Treat the advisory's description as the more detailed statement, and the 8.1 score as given by the record.
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
Two ideas combine here. The lookup trusts an identifier, and two routes are on a whitelist that bypasses authentication because OAuth callbacks come from outside by design. Callback endpoints still need to prove the request belongs to a flow the server started, typically through an unguessable state value tied to the session.
When a callback can overwrite tokens, the result is not only data theft. A third party can plant its own token in a credential and have your workflows act against the wrong account. That makes integrity the main concern.
Quick check
Which endpoints skip authentication?
Per the advisory, the callback and refresh handlers are whitelisted from authentication. The authorize handler requires a signed in user but does not check workspace ownership.
Sources
Last reviewed: 18 October 2026.
