SurrealDB: Scraping a TABLE with no available PERMISSIONS to current auth level (CVE-2026-63755)

CVE-2026-63755 in SurrealDB allows an authenticated user to bypass 'PERMISSIONS FOR SELECT WHERE' restrictions on tables within their current database. The vulnerability arises because the user-supplied WHERE clause in SELECT statements, as well as SET, MERGE, CONTENT, and PATCH clauses in update-variant statements, is evaluated against full record data before the permission check is performed. This ordering bug enables side-effecting expressions to exfiltrate record contents prior to authorization enforcement. The vulnerability is confined to the current database and does not cross namespace or database boundaries. The most straightforward exfiltration requires scripting functions enabled, but alternative methods using the THROW statement or timing side-channels exist. A patch in SurrealDB version 3.1.0 and later fixes the issue by running permission checks before evaluating user expressions.

An authenticated user with any level of access to a SurrealDB database can read the full contents of any table within that database, bypassing table-level SELECT permission restrictions. This compromises confidentiality of data within the affected database. The vulnerability does not affect other databases or namespaces. The impact is limited to confidentiality; integrity and availability are not affected. The CVSS v3.1 base score is 6.5 (medium severity), reflecting network attack vector, low attack complexity, and no user interaction required.

A patch is available in SurrealDB version 3.1.0 and later that fixes the permission check ordering issue. Users should upgrade to version 3.1.0 or newer to fully remediate this vulnerability. If upgrading is not immediately possible, disabling scripting functions (removing the --allow-scripting or -A flag) will block the most direct exfiltration method, though THROW-based and timing side-channel exfiltration remain possible. Additionally, restricting untrusted principals from running arbitrary SELECT queries with user-controlled WHERE clauses can reduce risk. Employing namespace or database isolation as the primary security boundary is recommended since the vulnerability affects only table-level permission enforcement.