Summary
Flowise OAuth2 endpoints do not consistently bind credential lookups to a workspace, allowing credentials to be accessed across workspace boundaries. Depending on the endpoint, an attacker may initiate authorization, overwrite stored OAuth tokens, or refresh tokens without the intended authorization checks.
Flowise OAuth2 endpoints do not consistently bind credential lookups to a workspace, allowing credentials to be accessed across workspace boundaries. Depending on the endpoint, an attacker may initiate authorization, overwrite stored OAuth tokens, or refresh tokens without the intended authorization checks.
Affected context
The issue affects Flowise deployments using the OAuth2 credential handlers before authorization is properly enforced. The authorize, callback, and refresh operations identify credentials by credential ID alone rather than combining the identifier with the caller's workspace context. Callback and refresh routes may also be reachable without authentication, increasing exposure when the application is publicly accessible.
The issue affects Flowise deployments using the OAuth2 credential handlers before authorization is properly enforced. The authorize, callback, and refresh operations identify credentials by credential ID alone rather than combining the identifier with the caller's workspace context. Callback and refresh routes may also be reachable without authentication, increasing exposure when the application is publicly accessible.
Exploit preconditions
- Attack surface: Flowise OAuth2 credential API endpoints
- Required access: The authorize operation may require an authenticated user, while callback and refresh operations may be reachable without authentication
- Trigger point: OAuth2 authorization, callback processing, or token refresh for a credential identifier
- Why exploitation is possible: Credential queries rely on the credential ID without verifying ownership, workspace membership, or equivalent authorization context
- Attack surface: Flowise OAuth2 credential API endpoints
- Required access: The authorize operation may require an authenticated user, while callback and refresh operations may be reachable without authentication
- Trigger point: OAuth2 authorization, callback processing, or token refresh for a credential identifier
- Why exploitation is possible: Credential queries rely on the credential ID without verifying ownership, workspace membership, or equivalent authorization context
Why this happens
The underlying bug is an object-level authorization failure mapped to CWE-863: Incorrect Authorization. OAuth2 handlers treat a credential identifier as sufficient authority to read or modify a credential, instead of scoping the lookup to the requesting user's workspace and permissions. This insecure direct-object reference pattern can permit cross-tenant access and token state changes when route-level authentication or ownership checks are absent.
The underlying bug is an object-level authorization failure mapped to CWE-863: Incorrect Authorization. OAuth2 handlers treat a credential identifier as sufficient authority to read or modify a credential, instead of scoping the lookup to the requesting user's workspace and permissions. This insecure direct-object reference pattern can permit cross-tenant access and token state changes when route-level authentication or ownership checks are absent.
Potential impact
- An attacker may access or act on OAuth2 credentials belonging to another workspace.
- Stored access or refresh tokens could be overwritten or refreshed without proper authorization.
- Integrations may be redirected to attacker-controlled authorization results.
- Connected third-party services could be accessed through compromised tokens.
- Workspace isolation and tenant confidentiality could be weakened.
- An attacker may access or act on OAuth2 credentials belonging to another workspace.
- Stored access or refresh tokens could be overwritten or refreshed without proper authorization.
- Integrations may be redirected to attacker-controlled authorization results.
- Connected third-party services could be accessed through compromised tokens.
- Workspace isolation and tenant confidentiality could be weakened.
General mitigation guidance
Mitigation generally focuses on enforcing authorization at the resource-query and business-logic layers.
Common defensive patterns include:
- Scope every credential lookup by credential ID, workspace or tenant identity, and the caller's permitted roles.
- Require authentication and explicit authorization for callback and refresh operations where practical.
- Bind OAuth state to the initiating user, workspace, credential, and authorization transaction.
- Reject requests when credential ownership, workspace membership, or OAuth state cannot be verified.
- Use least-privilege service accounts and minimize the permissions granted to stored OAuth integrations.
- Avoid exposing sensitive token values in responses, logs, or error messages.
- Apply secure-by-default route policies and centralized authorization middleware.
Mitigation generally focuses on enforcing authorization at the resource-query and business-logic layers.
Common defensive patterns include:
- Scope every credential lookup by credential ID, workspace or tenant identity, and the caller's permitted roles.
- Require authentication and explicit authorization for callback and refresh operations where practical.
- Bind OAuth state to the initiating user, workspace, credential, and authorization transaction.
- Reject requests when credential ownership, workspace membership, or OAuth state cannot be verified.
- Use least-privilege service accounts and minimize the permissions granted to stored OAuth integrations.
- Avoid exposing sensitive token values in responses, logs, or error messages.
- Apply secure-by-default route policies and centralized authorization middleware.
How teams detect issues like this
Organizations can look for this class of issue through:
- Static analysis and code review checks for database queries that retrieve credentials by ID without tenant or workspace predicates.
- Review of OAuth handlers for missing authentication, ownership checks, state validation, and authorization middleware.
- Tests that attempt cross-workspace access using valid identifiers from a different tenant.
- API policy checks confirming that callback and refresh routes enforce the intended access controls.
- Monitoring for unusual token refreshes, callback activity, authorization failures, and cross-workspace access patterns.
Automated security review tools may help identify direct-object references and authorization checks that are missing or inconsistently applied.
Organizations can look for this class of issue through:
- Static analysis and code review checks for database queries that retrieve credentials by ID without tenant or workspace predicates.
- Review of OAuth handlers for missing authentication, ownership checks, state validation, and authorization middleware.
- Tests that attempt cross-workspace access using valid identifiers from a different tenant.
- API policy checks confirming that callback and refresh routes enforce the intended access controls.
- Monitoring for unusual token refreshes, callback activity, authorization failures, and cross-workspace access patterns.
Automated security review tools may help identify direct-object references and authorization checks that are missing or inconsistently applied.
