Summary
SurrealDB allows an authenticated namespace, database, or record user to switch a session to another namespace or database without verifying that the user's authorization scope covers the target. If the target tables permit the requested operation, this may allow cross-tenant reading, creation, updating, or deletion of records.
SurrealDB allows an authenticated namespace, database, or record user to switch a session to another namespace or database without verifying that the user's authorization scope covers the target. If the target tables permit the requested operation, this may allow cross-tenant reading, creation, updating, or deletion of records.
Affected context
The issue occurs in SurrealDB deployments where tenant isolation relies on authenticated-level restrictions while the SurrealQL USE statement changes the active namespace or database. Risk is higher when tables expose broad permissions, such as PERMISSIONS FULL, and when users can submit or execute USE statements within an authenticated session.
The issue occurs in SurrealDB deployments where tenant isolation relies on authenticated-level restrictions while the SurrealQL USE statement changes the active namespace or database. Risk is higher when tables expose broad permissions, such as PERMISSIONS FULL, and when users can submit or execute USE statements within an authenticated session.
Exploit preconditions
- Attack surface: SurrealQL session or query interface that accepts USE statements
- Required access: An authenticated namespace, database, or record user account
- Trigger point: Switching the session to a namespace or database outside the caller's authorized scope
- Why exploitation is possible: The session transition does not adequately verify that the authenticated level covers the requested target, while target-table permissions may authorize subsequent operations
- Attack surface: SurrealQL session or query interface that accepts USE statements
- Required access: An authenticated namespace, database, or record user account
- Trigger point: Switching the session to a namespace or database outside the caller's authorized scope
- Why exploitation is possible: The session transition does not adequately verify that the authenticated level covers the requested target, while target-table permissions may authorize subsequent operations
Why this happens
The underlying flaw is an authorization boundary failure in session context switching. The USE statement changes the active namespace or database without enforcing an authorization check that binds the requested context to the caller's authenticated scope. This maps to CWE-639, Authorization Bypass Through User-Controlled Key, because attacker-controlled tenant or database selection can influence which protected records and operations become available.
The underlying flaw is an authorization boundary failure in session context switching. The USE statement changes the active namespace or database without enforcing an authorization check that binds the requested context to the caller's authenticated scope. This maps to CWE-639, Authorization Bypass Through User-Controlled Key, because attacker-controlled tenant or database selection can influence which protected records and operations become available.
Potential impact
- An attacker may read data belonging to another tenant.
- An attacker could create or modify records in another namespace or database.
- An attacker may delete or corrupt records where table permissions allow it.
- Cross-tenant access could undermine confidentiality, integrity, and tenant isolation.
- An attacker may read data belonging to another tenant.
- An attacker could create or modify records in another namespace or database.
- An attacker may delete or corrupt records where table permissions allow it.
- Cross-tenant access could undermine confidentiality, integrity, and tenant isolation.
General mitigation guidance
Mitigation generally focuses on enforcing authorization at every namespace,
database, and record context transition rather than trusting the requested
USE target.
Common defensive patterns include:
- Binding session context changes to the authenticated user's authorized scope.
- Applying deny-by-default permissions and narrowly defining allowed operations.
- Enforcing tenant authorization again at table and record access boundaries.
- Reducing reliance on user-controlled namespace or database identifiers.
- Using separate credentials, roles, or database boundaries where stronger tenant isolation is required.
- Auditing cross-tenant access attempts and applying least privilege to service accounts.
Mitigation generally focuses on enforcing authorization at every namespace,
database, and record context transition rather than trusting the requested
USE target.
Common defensive patterns include:
- Binding session context changes to the authenticated user's authorized scope.
- Applying deny-by-default permissions and narrowly defining allowed operations.
- Enforcing tenant authorization again at table and record access boundaries.
- Reducing reliance on user-controlled namespace or database identifiers.
- Using separate credentials, roles, or database boundaries where stronger tenant isolation is required.
- Auditing cross-tenant access attempts and applying least privilege to service accounts.
How teams detect issues like this
Organizations can look for this class of issue through:
- Static and semantic analysis of session-context switching code for missing authorization checks.
- Code review signals involving user-controlled namespace, database, tenant, or record identifiers.
- Tests that attempt authorized and unauthorized USE transitions across tenant boundaries.
- Policy enforcement requiring deny-by-default table and record permissions.
- Audit monitoring for unusual cross-tenant context changes or access patterns.
Automated security review tools may help identify missing authorization checks, but
deployment-specific permission tests remain important.
Organizations can look for this class of issue through:
- Static and semantic analysis of session-context switching code for missing authorization checks.
- Code review signals involving user-controlled namespace, database, tenant, or record identifiers.
- Tests that attempt authorized and unauthorized USE transitions across tenant boundaries.
- Policy enforcement requiring deny-by-default table and record permissions.
- Audit monitoring for unusual cross-tenant context changes or access patterns.
Automated security review tools may help identify missing authorization checks, but
deployment-specific permission tests remain important.
