CVE-2026-109333 in SurrealDB
Summary
by MITRE • 10/12/2026
SurrealDB from 3.0.0 before 3.3.0 contains an authorization bypass vulnerability that allows authenticated record users to read records in other namespaces or databases by resolving record ids through FETCH. Attackers can switch to a foreign namespace/database and name a known record id in a RETURN … FETCH query to read another tenant's data when table PERMISSIONS allow reads.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/12/2026
The vulnerability identified in SurrealDB versions prior to 3.3.0 represents a critical authorization bypass flaw that undermines the fundamental isolation guarantees expected in multi-tenant database environments. This issue specifically affects authenticated record users, who are typically granted restricted access scopes based on their assigned permissions and namespace context. The core of the problem lies in how the database engine processes FETCH operations within query statements. When an attacker authenticates as a valid user with read permissions for specific tables, they can manipulate the query structure to resolve record identifiers that belong to different namespaces or databases than the one they are authorized to access. This capability effectively allows lateral movement across tenant boundaries without requiring elevated privileges or additional authentication steps.
From a technical perspective, the flaw exploits the parsing and resolution logic of the RETURN FETCH syntax. In SurrealDB, records are uniquely identified by their namespace, database, table, and record ID combination. The vulnerability arises because the engine does not sufficiently validate that the target record identifier in a FETCH operation is constrained to the current session's authorized scope before executing the read. By switching context within the query or leveraging known record IDs from other tenants, an authenticated user can trick the database into retrieving data associated with foreign namespaces. This bypasses the intended access control mechanisms because the authorization check likely occurs at the table level but fails to enforce strict namespace and database boundaries during the resolution of specific record references via FETCH commands.
The operational impact of this vulnerability is severe for any organization utilizing SurrealDB in a multi-tenant architecture or where data isolation between different logical groups is required. Attackers can exfiltrate sensitive information belonging to other tenants, leading to significant confidentiality breaches. This could include personal identifiable information, proprietary business data, or confidential credentials stored within the database. Since the attack relies on authenticated access, it may also evade certain perimeter-based security controls that assume internal users are trusted. The ability to read arbitrary records across namespaces compromises the integrity of the entire system's trust model, potentially leading to regulatory non-compliance and loss of customer trust if such data leaks occur in production environments.
This vulnerability aligns with CWE-269, which describes Improper Privilege Management, specifically where a user is able to perform actions beyond their assigned privileges due to flawed access control logic. Furthermore, it relates to CWE-732, concerning Incorrect Permission Assignment for Critical Resource, as the database fails to correctly restrict resource access based on the authenticated identity's scope. In terms of the MITRE ATT&CK framework, this behavior is consistent with techniques found under T1530, Data from Information Repositories, where an adversary accesses data stored in databases or other information repositories using valid credentials but exploiting misconfigurations or logic flaws to reach unauthorized datasets.
To mitigate this risk, organizations running SurrealDB versions between 3.0.0 and 3.2.x must upgrade immediately to version 3.3.0 or later, where the authorization checks for FETCH operations have been hardened to enforce strict namespace and database boundaries. Until an upgrade is possible, administrators should review table permissions carefully, ensuring that read access is granted only to necessary tables within specific namespaces. Additionally, implementing network-level segmentation can limit exposure if a compromise occurs, although this does not fix the underlying application logic flaw. Regular security audits of query patterns and strict validation of record ID scopes in custom applications interacting with SurrealDB are also recommended as defensive measures against similar exploitation attempts.