Summary
Flowise versions before 3.1.3 allow openai-assistants-vector-store endpoints to use a client-supplied credential identifier without verifying that the credential belongs to the caller's workspace. An attacker who obtains another workspace's credential ID may use the associated OpenAI key to access victim vector stores and files, potentially causing data exposure, unauthorized changes, and billing impact.
Flowise versions before 3.1.3 allow openai-assistants-vector-store endpoints to use a client-supplied credential identifier without verifying that the credential belongs to the caller's workspace. An attacker who obtains another workspace's credential ID may use the associated OpenAI key to access victim vector stores and files, potentially causing data exposure, unauthorized changes, and billing impact.
Affected context
The issue occurs in Flowise deployments using the openai-assistants-vector-store functionality in a multi-tenant environment. Route permissions verify feature access, but the credential lookup and subsequent OpenAI operations do not consistently bind the requested credential or vector-store resources to the authenticated user's workspace. Exploitation depends on a credential identifier from another workspace being known or obtainable.
The issue occurs in Flowise deployments using the openai-assistants-vector-store functionality in a multi-tenant environment. Route permissions verify feature access, but the credential lookup and subsequent OpenAI operations do not consistently bind the requested credential or vector-store resources to the authenticated user's workspace. Exploitation depends on a credential identifier from another workspace being known or obtainable.
Exploit preconditions
- Attack surface: Authenticated openai-assistants-vector-store API endpoints
- Required access: A valid account with permission to use the relevant assistants functionality
- Additional condition: Knowledge of, or access to, a credential identifier belonging to another workspace
- Trigger point: A request that supplies the client-controlled credential parameter
- Why exploitation is possible: The service retrieves the credential by identifier, decrypts it, and invokes OpenAI APIs without enforcing workspace ownership
- Attack surface: Authenticated openai-assistants-vector-store API endpoints
- Required access: A valid account with permission to use the relevant assistants functionality
- Additional condition: Knowledge of, or access to, a credential identifier belonging to another workspace
- Trigger point: A request that supplies the client-controlled credential parameter
- Why exploitation is possible: The service retrieves the credential by identifier, decrypts it, and invokes OpenAI APIs without enforcing workspace ownership
Why this happens
The underlying defect is a missing authorization check across a tenant boundary. The controller forwards a client-controlled credential identifier, while the service performs an identifier-only lookup and does not constrain the result by the caller's workspace. This behavior maps primarily to CWE-285: Improper Authorization and also to CWE-863: Incorrect Authorization, because feature-level permissions are applied without validating ownership of the credential and related resources.
The underlying defect is a missing authorization check across a tenant boundary. The controller forwards a client-controlled credential identifier, while the service performs an identifier-only lookup and does not constrain the result by the caller's workspace. This behavior maps primarily to CWE-285: Improper Authorization and also to CWE-863: Incorrect Authorization, because feature-level permissions are applied without validating ownership of the credential and related resources.
Potential impact
- An attacker may use another workspace's OpenAI credential
- Victim vector stores and files could be read, modified, or deleted
- Unauthorized OpenAI API activity could cause billing charges for the victim
- Cross-tenant data exposure or manipulation could occur
- The affected OpenAI account could be misused for additional operations
- An attacker may use another workspace's OpenAI credential
- Victim vector stores and files could be read, modified, or deleted
- Unauthorized OpenAI API activity could cause billing charges for the victim
- Cross-tenant data exposure or manipulation could occur
- The affected OpenAI account could be misused for additional operations
General mitigation guidance
Mitigation should center on enforcing authorization at the resource and service layers rather than relying only on route-level feature permissions.
Defensive patterns include:
- Deriving workspace identity from the authenticated session instead of trusting client-supplied ownership identifiers
- Filtering credential and vector-store lookups by the caller's authorized workspace
- Rechecking tenant ownership immediately before decrypting credentials or invoking external APIs
- Applying deny-by-default authorization for cross-workspace resource access
- Limiting service-account and OpenAI credential privileges to the smallest necessary scope
- Avoiding disclosure of resource identifiers that can facilitate unauthorized lookup
Mitigation should center on enforcing authorization at the resource and service layers rather than relying only on route-level feature permissions.
Defensive patterns include:
- Deriving workspace identity from the authenticated session instead of trusting client-supplied ownership identifiers
- Filtering credential and vector-store lookups by the caller's authorized workspace
- Rechecking tenant ownership immediately before decrypting credentials or invoking external APIs
- Applying deny-by-default authorization for cross-workspace resource access
- Limiting service-account and OpenAI credential privileges to the smallest necessary scope
- Avoiding disclosure of resource identifiers that can facilitate unauthorized lookup
How teams detect issues like this
Detection can combine static analysis, code review, runtime monitoring, and policy enforcement:
- Search for credential or resource lookups performed solely by client-supplied identifiers
- Review controller-to-service calls for missing workspace, tenant, or ownership context
- Flag external API calls that use decrypted credentials without a preceding authorization check
- Add tests that attempt access to resources owned by a different workspace
- Monitor unusual cross-tenant access patterns, unexpected vector-store mutations, and abnormal OpenAI usage or billing
- Use automated code review and authorization-analysis tools to identify identifier-only queries and missing policy checks
Detection can combine static analysis, code review, runtime monitoring, and policy enforcement:
- Search for credential or resource lookups performed solely by client-supplied identifiers
- Review controller-to-service calls for missing workspace, tenant, or ownership context
- Flag external API calls that use decrypted credentials without a preceding authorization check
- Add tests that attempt access to resources owned by a different workspace
- Monitor unusual cross-tenant access patterns, unexpected vector-store mutations, and abnormal OpenAI usage or billing
- Use automated code review and authorization-analysis tools to identify identifier-only queries and missing policy checks
