SurrealDB vulnerabilities

SurrealDB before version 2.1.0 has a denial of service vulnerability in the sorting mechanism when using ORDER BY rand(). Authorized clients can execute queries with ORDER BY rand() to trigger a panic in the sorting function, crashing the server.

SurrealDB before version 2.1.0 contains a denial of service vulnerability in role conversion. A privileged user can define users with nonexistent roles, and signing in with such a user triggers an uncaught panic, crashing the server.

Vulnerability in SurrealDB before version 2.1.0 in the rand::time() function panics when unwrap is called on a None result from timestamp_opt. Authorized clients can repeatedly invoke rand::time() to trigger server panics and cause denial of service.

SurrealDB before 2.1.4 silently fails to overwrite table definitions when the DEFINE TABLE ... OVERWRITE clause is used on tables defined with TYPE RELATION. Because table definitions include the PERMISSIONS clause, an attempt to tighten a table's permissions via OVERWRITE does not take effect, and the administrator may incorrectly believe the change was applied. As a result, a client authorized to run queries may continue to access data in that table that the updated (but unapplied) permissions were intended to restrict.

SurrealDB before version 1.0.1 sets default table permissions to FULL instead of NONE, allowing SELECT, CREATE, UPDATE, and DELETE operations without explicit permissions. Attackers with database access or unauthenticated users on public instances can perform unrestricted operations on unprotected tables.

A vulnerability in SurrealDB before version 3.1.5 fails to apply field-level SELECT permissions to ORDER BY clauses. This allows authenticated users to leak the relative ordering of restricted field values.

In SurrealDB prior to version 3.1.0, when a node is deleted, the Document::purge_edges function automatically removes associated graph edges, bypassing the PERMISSIONS FOR delete and PERMISSIONS FOR select clauses defined on the edge table. This occurs because the operation runs with permissions disabled (opt.clone().with_perms(false)).