CVE-2026-70474: Flowise Auth Bypass Vulnerability

CVE-2026-70474 Overview

Flowise is a drag-and-drop user interface for building customized large language model (LLM) flows. CVE-2026-70474 is a broken access control vulnerability [CWE-863] affecting Flowise versions prior to 3.1.3. Three OAuth2 credential endpoints look up credentials by id alone without applying a workspaceId filter. The authorize, callback, and refresh handlers query the Credential table by id only, and both callback and refresh are whitelisted from authentication. Attackers can initiate OAuth2 flows against credentials in other workspaces, forge OAuth2 callbacks to overwrite tokens, and refresh tokens for any credential. The issue is fixed in Flowise 3.1.3.

Critical Impact
Unauthenticated attackers can overwrite OAuth2 tokens on any credential and hijack third-party integrations across all Flowise workspaces.

Affected Products

Flowise versions prior to 3.1.3
FlowiseAI Flowise OAuth2 credential subsystem
Multi-tenant Flowise deployments serving multiple workspaces

Discovery Timeline

2026-08-04 - CVE-2026-70474 published to NVD
2026-08-05 - Last updated in NVD database

Technical Details for CVE-2026-70474

Vulnerability Analysis

The vulnerability stems from missing workspace-scoped authorization checks in three OAuth2 credential handlers. Flowise stores credentials in a Credential table keyed by UUID. In multi-tenant deployments, each credential belongs to a specific workspace and should only be accessible to members of that workspace. The affected handlers query the table using only the credential id supplied in the request path or state parameter. They never validate that the requester belongs to the workspace owning the credential. This confusion between authentication (who you are) and authorization (what you can access) allows cross-tenant access to sensitive OAuth2 tokens.

Root Cause

The root cause is a missing workspace filter on database lookups in the authorize, callback, and refresh route handlers. Additionally, the callback and refresh routes are explicitly whitelisted from authentication middleware, exposing them to unauthenticated network callers. The design assumed possession of a credential UUID implied legitimate access, which fails once UUIDs can be enumerated, leaked in logs, or guessed from other tenants.

Attack Vector

An attacker with any authenticated Flowise account can call /api/v1/oauth2-credential/authorize/<VICTIM_CREDENTIAL_UUID> to start an OAuth2 flow against a credential owned by another workspace. An unauthenticated attacker can call /api/v1/oauth2-credential/callback?code=ATTACKER_AUTH_CODE&state=<VICTIM_CREDENTIAL_UUID> to inject their own authorization code and overwrite the stored token. The attacker can also call /api/v1/oauth2-credential/refresh/<VICTIM_CREDENTIAL_UUID> to force token refresh on any credential. Token overwrite lets the attacker redirect downstream API traffic through their own OAuth2 identity, or capture tokens tied to a victim tenant's third-party services.

No verified proof-of-concept code is published. Refer to the GitHub Security Advisory GHSA-wch5-xp77-fxg4 for authoritative technical details.

Detection Methods for CVE-2026-70474

Indicators of Compromise

Requests to /api/v1/oauth2-credential/callback from unexpected source IPs or without a preceding /authorize request from the same session
Requests to /api/v1/oauth2-credential/refresh/<UUID> or /authorize/<UUID> where the UUID does not match the requester's workspace
Unexpected changes to accessToken, refreshToken, or expiresAt fields in the Credential table
OAuth2 provider audit logs showing new authorization grants tied to Flowise credentials the tenant did not initiate

Detection Strategies

Enable HTTP access logging on the Flowise API tier and alert on any unauthenticated hits to /api/v1/oauth2-credential/callback and /refresh/*
Correlate state parameter UUIDs in callback requests with the workspace of the originating authorize request; mismatches indicate abuse
Monitor for anomalous rates of OAuth2 token refresh events per credential

Monitoring Recommendations

Ingest Flowise application logs and reverse-proxy access logs into a centralized data lake for cross-tenant analysis
Alert on credential row updates (updatedAt bumps) that are not preceded by an authenticated user action in the same workspace
Track outbound API calls from Flowise to third-party OAuth2 providers and flag deviations from historical baselines

How to Mitigate CVE-2026-70474

Immediate Actions Required

Upgrade Flowise to version 3.1.3 or later, which enforces workspace scoping on the affected routes
Rotate all OAuth2 credentials configured in Flowise, including revoking existing refresh and access tokens at the identity provider
Audit the Credential table for unexpected updatedAt timestamps and reconcile with legitimate user activity
Review OAuth2 provider logs for unauthorized authorization grants targeting Flowise integrations

Patch Information

The fix is available in Flowise 3.1.3. See the Flowise 3.1.3 release notes and the GitHub Security Advisory GHSA-wch5-xp77-fxg4. The patched version adds workspace-scoped lookups to the authorize, callback, and refresh handlers.

Workarounds

Block external access to /api/v1/oauth2-credential/callback and /api/v1/oauth2-credential/refresh/* at a reverse proxy until the upgrade is applied, allowing only trusted OAuth2 provider redirect IPs where possible
Restrict Flowise to single-tenant deployments and remove untrusted authenticated users until patched
Place Flowise behind a WAF rule that requires an authenticated session cookie on all /api/v1/oauth2-credential/* routes

bash

# Example nginx block for unauthenticated OAuth2 callback/refresh routes
location ~ ^/api/v1/oauth2-credential/(callback|refresh)/ {
    allow 203.0.113.0/24;   # trusted OAuth2 provider egress
    deny all;
    proxy_pass http://flowise_upstream;
}