CVE-2026-63755 in SurrealDB
Summary
by MITRE • 07/20/2026
SurrealDB before 3.1.0 evaluates user-supplied WHERE clauses in SELECT statements (and SET/MERGE/CONTENT/PATCH clauses in UPDATE, UPSERT, INSERT ON DUPLICATE KEY UPDATE, and RELATE update-variant statements) against full record data before enforcing PERMISSIONS FOR SELECT WHERE restrictions. An authenticated user — including Record and Scope users — can exploit this ordering flaw to read the full contents of any table in the database they are authenticated against, bypassing table-level permission checks. Exfiltration is most direct when scripting functions are enabled (--allow-scripting), but is also possible via SurrealQL's THROW statement and timing-based side channels without scripting. The vulnerability is confined to the attacker's current database and does not cross namespace or database isolation boundaries.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 07/20/2026
This vulnerability represents a critical authorization bypass in SurrealDB versions prior to 310 where the system fails to properly enforce permission restrictions during query execution. The flaw occurs due to an improper ordering of security checks that allows authenticated users to circumvent table-level access controls by exploiting the evaluation sequence of WHERE clauses in database operations. When processing SELECT statements and various update variants including SET, MERGE, CONTENT, PATCH, UPSERT, INSERT with ON DUPLICATE KEY UPDATE, and RELATE operations, the system evaluates user-supplied WHERE conditions against complete record data before applying the PERMISSIONS FOR SELECT WHERE restrictions that should normally limit access to authorized records.
The technical implementation of this vulnerability stems from a fundamental flaw in SurrealDB's query processing pipeline where the security validation occurs after data retrieval rather than before it. This ordering issue affects all authenticated user types including both Record and Scope level users, meaning any user with valid credentials can exploit this weakness regardless of their specific permission scope. The vulnerability manifests because the system processes the WHERE clause conditions against all available record data before enforcing the permission boundaries that should restrict access to only authorized records within a table. This creates a scenario where even if a user lacks explicit SELECT permissions on certain tables, they can still extract complete table contents by crafting appropriate WHERE clauses that bypass the normal permission enforcement mechanisms.
The operational impact of this vulnerability is severe as it enables unauthorized data exfiltration across all tables accessible to authenticated users within their current database context. Attackers can leverage this flaw to read full table contents without proper authorization, effectively bypassing the intended access control model that should protect sensitive information based on user permissions. The vulnerability is particularly concerning when scripting functions are enabled via the --allow-scripting flag, as this provides additional attack vectors for data extraction and manipulation. However, even without scripting capabilities, attackers can still exploit the vulnerability through SurrealQL's THROW statement functionality and timing-based side channel attacks that leverage the system's response characteristics to infer information about database contents.
Security professionals should note that this vulnerability aligns with CWE-284 (Improper Access Control) and maps to ATT&CK technique T1078 (Valid Accounts) and T1566 (Phishing). The flaw demonstrates a classic case of privilege escalation through improper authorization enforcement, where the system's access control mechanisms fail to properly validate user permissions at the appropriate stage in query processing. The vulnerability is confined to the attacker's current database context and does not cross namespace or database isolation boundaries, meaning it cannot be used to access data across different databases or namespaces within the same SurrealDB instance. However, this limitation does not reduce the severity of the impact, as authenticated users with access to a single database can still extract all available information from tables they are able to reach through their current authentication context.
Mitigation strategies should include upgrading to SurrealDB version 310 or later where this vulnerability has been addressed through proper ordering of security checks. Organizations should also implement additional monitoring for unusual query patterns that might indicate exploitation attempts, particularly those involving complex WHERE clauses against tables they normally wouldn't access. Database administrators should review and tighten permission settings, ensuring that users only receive the minimum necessary access rights to perform their legitimate functions. The implementation of database activity monitoring and alerting systems can help detect anomalous access patterns that may indicate exploitation of this vulnerability. Additionally, organizations should disable scripting capabilities unless absolutely required for operations, as this significantly reduces the attack surface available to potential exploiters.