CVE-2026-109343 in SurrealDB
Summary
by MITRE • 10/12/2026
SurrealDB before 3.3.0 allows cross-tenant access because the SurrealQL USE statement switches a session to any namespace/database without checking that the caller's authenticated level covers it. Authenticated namespace, database, or record users can switch to another tenant and read, create, update, or delete rows in tables whose PERMISSIONS allow it, such as PERMISSIONS FULL.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/13/2026
The vulnerability identified in SurrealDB versions prior to 3.3.0 represents a critical failure in multi-tenant isolation mechanisms, specifically within the implementation of the USE statement used for context switching between namespaces and databases. In a properly secured multi-tenant database architecture, authentication and authorization checks must be rigorously enforced whenever a session changes its operational scope or target resource. However, this flaw allows an authenticated user to bypass these controls by simply issuing a SurrealQL command that switches their active namespace or database context without validating whether the current credentials possess sufficient privileges for the new environment. This architectural oversight effectively neutralizes the boundary between distinct tenants, as the system trusts the session's existing authentication token regardless of its scope limitations in the target tenant.
From a technical perspective, the core issue lies in the lack of permission verification during the context switch operation. When an authenticated user operates under namespace-level, database-level, or record-specific permissions, their access is typically restricted to specific resources within that defined boundary. The vulnerability exploits the fact that the USE statement modifies the session's internal state to point toward a different tenant without re-evaluating the caller's authorization level against the target environment's security policies. Consequently, if the target namespace and database have permissive settings, such as PERMISSIONS FULL which allows unrestricted read, write, update, and delete operations for any authenticated user, the attacker can immediately exploit this open configuration to manipulate data belonging to other tenants who share the same server instance but are logically separated by design.
The operational impact of this vulnerability is severe, leading directly to unauthorized cross-tenant access and potential data breaches. An adversary with valid credentials in one tenant can pivot into another tenant's environment without needing additional authentication steps or privilege escalation exploits beyond what was already granted for their original context. Once inside the target tenant's namespace, the attacker gains the ability to read sensitive information, create new records that could be used for further attacks, update existing data to cause integrity issues, or delete critical rows leading to denial of service conditions specific to those tenants. This breaks the fundamental trust model of multi-tenant systems where isolation is paramount, potentially exposing proprietary business logic, customer personal identifiable information, and other confidential assets stored within the compromised tenant's database tables.
This vulnerability aligns with CWE-269, which describes Improper Privilege Management, as it involves a failure to enforce proper authorization levels when changing operational contexts. Furthermore, from an offensive security perspective mapped to the MITRE ATT&CK framework, this behavior facilitates lateral movement within a compromised environment and can be categorized under techniques related to privilege escalation or unauthorized access via misconfigured permissions. The attack vector is particularly dangerous because it does not require complex exploitation chains; rather, it relies on standard database interaction commands that are often part of legitimate application workflows, making detection through simple signature-based monitoring difficult without deep behavioral analysis.
To mitigate this risk, organizations running SurrealDB must immediately upgrade to version 3.3.0 or later where the context switching logic has been corrected to enforce strict permission checks before allowing a session to switch namespaces or databases. Until an upgrade is feasible, administrators should implement network-level segmentation to isolate database instances for different tenants if possible, although this may not be practical in all shared hosting environments. Additionally, applying the principle of least privilege by configuring PERMISSIONS settings more restrictively than FULL can reduce the blast radius even if a tenant boundary is breached. Regular audits of authentication and authorization configurations are essential to ensure that no single authenticated user has broad access across multiple logical tenants unless explicitly required for specific administrative functions, which should be tightly controlled with multi-factor authentication and detailed logging.