Flowise Cross-Workspace OAuth2 Credential Access via Missing Workspace Scoping
First seen Aug 4, 2026 · Updated Aug 4, 2026
Flowise's OAuth2 credential endpoints (authorize, callback, refresh) look up credentials by ID alone without checking workspace ownership, and two of these endpoints are fully unauthenticated. This lets any authenticated user access other workspaces' OAuth2 client metadata, and lets any unauthenticated attacker forge callbacks to inject tokens into or refresh tokens for arbitrary credentials. Since these credentials are used by Flowise's AI agents to authenticate to third-party tools and APIs, the flaw effectively lets attackers hijack the external identities and permissions of agents belonging to other tenants.
Technical Analysis
The vulnerability is an IDOR/broken object-level authorization issue: three handlers in packages/server/src/routes/oauth2/index.ts query the Credential table with findOneBy({id}) and never apply the workspaceId filter used elsewhere in the codebase (e.g., services/credentials/index.ts). The entry point is compounded by an authentication bypass — the callback and refresh routes are added to WHITELIST_URLS and matched via prefix comparison, so requests to them skip JWT/API key verification entirely. An attacker can therefore call the authorize endpoint as any authenticated user to leak another workspace's client_id/scope/redirect_uri, or call the unauthenticated callback endpoint with a victim credential's UUID as the `state` parameter to overwrite that credential's stored tokens with attacker-controlled values, or call refresh to pull fresh token data for any credential. Because these credentials back tool/agent integrations (e.g., third-party APIs the Flowise agent calls), the exploit crosses tenant/workspace boundaries and effectively grants the attacker the calling privileges of another workspace's connected tool identity.
Affected Systems
Flowise; protocols: OAuth2
Detection Signatures
- Requests to /api/v1/oauth2-credential/callback or /api/v1/oauth2-credential/refresh with no valid session/API key headers
- OAuth2 callback requests where the `state` parameter matches a credential UUID not owned by the requester's workspace
- Repeated authorize/refresh calls against credential IDs not associated with the caller's workspaceId in application logs
- Unexpected updatedDate changes on Credential records absent a corresponding authenticated session in audit logs
- Anomalous cross-workspace credentialId enumeration patterns in access logs
Remediation Steps
- 1
Upgrade Flowise
Update to a patched Flowise release beyond 3.1.2 once available that enforces workspaceId scoping on all OAuth2 credential lookups.
- 2
Enforce workspace scoping on all credential queries
Modify authorize, callback, and refresh handlers to filter Credential lookups by both id and workspaceId, matching the pattern already used in services/credentials/index.ts.
- 3
Remove callback/refresh from auth whitelist
Replace the blanket WHITELIST_URLS bypass with a scoped, signed-state validation mechanism (e.g., HMAC-signed state tokens tied to workspace and expiry) instead of exempting these routes from authentication entirely.
- 4
Rotate exposed OAuth2 credentials
Rotate client secrets and revoke/reissue tokens for all OAuth2 credentials stored in affected Flowise instances, since token integrity and client metadata confidentiality may have been compromised.
- 5
Add monitoring and rate limiting
Implement rate limiting and anomaly detection on OAuth2 credential endpoints to detect enumeration attempts against credential IDs outside a caller's workspace.
CVE / Advisory IDs
Industries Most Exposed
Respond to this threat
Pro subscribers get a full AI-generated incident-response playbook for this threat — detection, containment, eradication, and recovery steps — plus an unlimited AI Threat Advisor for questions about your environment.