Advisories for Cargo/Surrealdb package

2026

SurrealDB: USE NS/DB implicit creation bypasses DEFINE authorization

An anonymous caller could create new namespaces and databases on a running SurrealDB instance without holding DEFINE NAMESPACE or DEFINE DATABASE permission. USE NS <name> and USE DB <name> automatically create the target when it does not exist. The three places USE is handled — the RPC use method, Datastore::process_use, and the SurrealQL executor — did not check whether the caller was allowed to create the resource. Under default capabilities …

SurrealDB: Scraping a TABLE with no available PERMISSIONS to current auth level

A vulnerability was discovered where the user-supplied WHERE clause in a SELECT statement is evaluated against the full record data before PERMISSIONS FOR SELECT WHERE determines whether the principal is authorised to access that record. A side-effecting expression in the WHERE clause can exfiltrate record contents before the permission check runs. The same ordering bug affects the SET, MERGE, CONTENT and PATCH clauses of update-variant statements (UPDATE, UPSERT-update, INSERT ON …

SurrealDB: Port-specific --deny-net rules silently bypassed on HTTP redirect

SurrealDB offers http::* functions that can access external network endpoints, with the –allow-net and –deny-net capabilities used to restrict the set of network targets that can be reached. An authenticated user of SurrealDB can bypass a port-scoped –deny-net <host>:<port> rule by chaining an HTTP redirect: the initial request goes to an –allow-net-permitted hostname, the response's 3xx Location header points at the denied host:port, and the redirect is followed even though …

SurrealDB: LIVE query subscriptions survive session state changes, bypassing access controls

A LIVE SELECT subscription records the user's auth state ($auth, $token, $session, $access) when it is registered, and the server uses that recorded state to evaluate the table- and row-level PERMISSIONS clauses for every subsequent notification. The recorded state is never refreshed. When something changes the user's effective auth state — the originating session is invalidated, the session's TTL expires, or the user signs in, signs up, or authenticates as …

SurrealDB: HTTP RPC Session Race Condition Allows Privilege Escalation

The HTTP /rpc endpoint has a time-of-check/time-of-use (TOCTOU) race condition on internal session state. When authenticated and unauthenticated requests are processed concurrently, the unauthenticated request can inherit the authenticated user's session and privileges. The /rpc endpoint is the primary interface used by all official SurrealDB SDKs. The HTTP /rpc handler does not bind each incoming request to an isolated session context. Instead, concurrent requests share mutable authentication state. When an …

SurrealDB: HTTP /rpc `sessions` method leaks attached session UUIDs, enabling full session hijack by anonymous callers

The HTTP /rpc sessions method returned every attached session UUID without authentication, and the /rpc handler accepted an arbitrary session field with no ownership check. An anonymous caller could enumerate UUIDs and impersonate any authenticated session. "Attached" means sessions registered via {"method":"attach"} — the only writer to the HTTP session map. Ordinary stateless /rpc requests use ephemeral per-request sessions that are filtered from sessions() and destroyed at end-of-request, so they …

SurrealDB: Graph traversal bypasses table SELECT permissions

An authenticated record or scope user could read records on any table reachable through a graph edge or REFERENCES TO back-reference, regardless of that table's PERMISSIONS FOR select clause. Traversing SELECT * FROM source->edge->target returned full documents from target even when target was defined as PERMISSIONS FOR select NONE. The same bypass extended through multi-hop chains, so any table reachable by a sequence of edges from a readable starting point …

SurrealDB: Field-level SELECT permissions bypassed via indexed COUNT fast paths

A record user could learn the value of a hidden field by counting how many records match a guess. When DEFINE FIELD … PERMISSIONS FOR select WHERE … hides a field's contents from a caller, and that field is indexed, running SELECT count() FROM t WHERE hidden_field = "guess" GROUP ALL returned a count greater than zero whenever a record actually had that value — even though the caller was …

SurrealDB: ES512 silently downgraded to ES384 due to jsonwebtoken crate limitation

When a user configures ALGORITHM ES512 for any JWT access method (DEFINE ACCESS … TYPE JWT ALGORITHM ES512), SurrealDB silently substitutes ES384 at all four internal algorithm conversion points. This occurs because the underlying jsonwebtoken crate (v10.x) does not include an ES512 algorithm variant, so the mapping defaults to ES384 without raising an error, warning, or log message. Users who provide the correct P-521 key type for ES512 will experience …

SurrealDB: Edge PERMISSIONS FOR delete bypassed when a connected node is deleted

In SurrealDB, records can be connected as a graph: a RELATE statement creates an edge record between two node records. If either endpoint node is deleted, SurrealDB automatically removes the edge row to keep the graph consistent. A user with permission to delete a node could also delete the edges connected to that node, even when the edge table's PERMISSIONS FOR delete clause should have stopped them. The automatic edge …

SurrealDB: Crafting malicious LIVE queries writes to the database, resulting in DoS, without permission to the table required

A LIVE query whose WHERE clause evaluates to an error caused the source data modifier (the user creating, updating, or deleting a record on the watched table) to fail instead. Calling any arbitrary SurrealQL function with a typed parameter and passing a value of the wrong type — for example LIVE SELECT * FROM t WHERE string::trim(deny) — triggered an evaluation error inside the LIVE notification path. That error then …

SurrealDB: Authorization Bypass in KILL Statement Allows Termination of Other Users' Live Queries

The KILL statement is used to terminate LIVE SELECT subscriptions that capture real-time changes to data within a table. The KILL statement implementation in core/src/expr/statements/kill.rs verifies that the requesting user has database-level access, but does not verify that the requesting user is the owner of the live query being terminated. After passing the valid_for_db() check, the KILL statement resolves the live query UUID, looks up the corresponding live query entry, …

SurrealDB: Authenticated callers can read fields hidden by field-level SELECT permissions via error messages

A record user with UPDATE access could read field values that field-level SELECT permissions hid from them. Arithmetic operators and extend embedded the raw operand into their error messages, and UPDATE permission checks evaluate against the unreduced document — so triggering such an error against a hidden field returned its value in the resulting error.

SurrealDB: `RELATE` overwrites existing edge records without `UPDATE` permission

RELATE creates an edge record between two existing records, and SurrealDB enforces the CREATE permission on the edge table for this operation. When the statement included a SET id = edge:existing clause, however, the new edge's id ended up pointing at an record that was already in storage. Rather than failing because the target already existed — which is what a create operation should do — the storage layer silently …

SurrealDB vulnerable to pre-auth memory amplification via unbounded `/sql` WebSocket frames

An anonymous caller could degrade /sql availability by streaming WebSocket frames many times larger than the operator-configured per-connection limit. The /sql upgrade handler accepted anonymous connections and did not propagate SURREAL_WEBSOCKET_MAX_MESSAGE_SIZE to the WebSocket protocol layer — incoming bytes accumulated in the per-connection read buffer before check_anon could reject the query, so the memory cost was incurred regardless of whether the caller could ever execute SurrealQL. The same upgrade path …

SurrealDB vulnerable to Denial of Service due to nested types annotations

The SurrealDB type/kind parser did not enforce the configured recursion depth limit when parsing nested type annotations. The expression parser already enforced the limit for analogous constructs; the kind parser omitted it. An authenticated attacker could send a query with deeply nested type annotations (e.g., array<option<array<option<…>>>>) and exhaust server memory, crashing the process.

SurrealDB has unauthenticated remote DoS via malformed RPC `use` call

A single unauthenticated WebSocket message to /rpc crashed the SurrealDB server. Sending use { db: "x" } without first selecting a namespace hit .expect("namespace should be set") in the use handler; because surrealdb-core is built with panic = 'abort', the panic terminated the process. use is callable before signin, and the per-method capability check passes by default for guest callers — so no credentials, token, or –allow-guests flag are required.

SurrealDB has Denial of Service in JSON parser due to nested objects

The SurrealDB value and JSON parser did not enforce the configured recursion depth limit when parsing nested {, [, or ( tokens. The expression parser already enforced the limit for these tokens; the value/JSON parser omitted it. An unauthenticated attacker could send a deeply nested JSON payload to the WebSocket /rpc endpoint and exhaust server memory, crashing the process.

SurrealDB has bypass of field-level SELECT permissions through JSON Patch `copy` and `move` with empty `from`

SurrealDB lets callers modify records using JSON Patch operations via the UPDATE … PATCH statement (and SDK equivalents such as db.patch()). One of those operations is copy, which duplicates one field's value into another field of the same record. A PATCH with an empty from — for example, UPDATE thing:1 PATCH [{ op: 'copy', from: '', path: '/leak' }] — was treated as "copy the entire record" and duplicated every …

SurrealDB has an Authorization Bypass via Composite Record-id Paths

An authenticated user could bypass permission rules that gated access on parts of a record's id — most commonly tenant-isolation rules of the form PERMISSIONS FOR select WHERE id.tenant = $auth.id.tenant. The same defect also let UNIQUE constraints defined on parts of an id admit duplicate entries. When a query referenced part of a composite record id (id.tenant, id.uid, …), SurrealDB read the value from the record's editable body fields …

SurrealDB: SSRF via JWKS URL — Redirect Following in JWT Key Fetch

SurrealDB fetches the JWKS document for a JWT or record access method using a bare reqwest client that follows HTTP redirects by default. The network capability check in core/src/iam/jwks.rs (check_capabilities_url) is applied only to the originally configured URL; redirect targets are not re-validated. An –allow-net-permitted JWKS host that returns a 3xx Location can therefore redirect the request to an address the allowlist was meant to block, resulting in a server-side …

SurrealDB: Indexed ORDER BY leaks the value ordering of a SELECT-restricted field

A field can be hidden from a user with a field-level SELECT permission (DEFINE FIELD code ON secret PERMISSIONS FOR select WHERE owner = $auth.id). When that field is indexed, a record user who cannot read it could still recover the relative ordering of its values across every record by issuing ORDER BY <field>: the field came back null as intended, but the rows were returned in the hidden values' …

SurrealDB: Field-level SELECT permissions bypassed via graph and reference traversals

A record user could read field values hidden from them by field-level SELECT permissions by reaching the records through a graph-edge (->) or back-reference (<~) traversal instead of a direct SELECT. When a table was readable at the table level but carried a field hidden by a field-level permission (DEFINE FIELD secret ON knows PERMISSIONS FOR select NONE), a direct SELECT * FROM knows hid secret — but reaching the …

SurrealDB: Denial of Service via deep operator chains

An authenticated user could crash a SurrealDB server with a single query containing a long chain of operators. Such a query — for example RETURN 1 + 1 + 1 + … with tens of thousands of terms — is parsed into an expression tree one level deep per operator. Because the chain is flat and the pratt parser appends to it iteratively, the configured query- and object-recursion limits never …

SurrealDB: Arbitrary file read via DEFINE ANALYZER mapper() filter

SurrealDB's full-text search lets you define a text analyzer whose mapper filter loads a term-mapping file from disk (DEFINE ANALYZER … FILTERS mapper('<path>')). A database user with the EDITOR or OWNER role could point that filter at any file the SurrealDB process can read and have its content returned in the query's error message. File access is meant to be restricted by the SURREAL_FILE_ALLOWLIST setting, but an empty allowlist applied …

SurrealDB vulnerable to Denial of Service through scripting function memory edge case

In SurrealDB instances with the scripting capability enabled (–allow-scripting), users with the ability to run arbitrary queries can trigger a server crash due to a memory-safety bug in the underlying JS engine. The SurrealDB instance terminates instantly, requiring a manual restart. The query consists of using built-in string functions to construct a large string and passing it to the JavaScript runtime for compilation. The exact string size required to trigger …

SurrealDB Affected by Confused Deputy Privilege Escalation through Future Fields and Functions

Unprivileged users (for example, those with the database editor role) can create or modify fields in records that contain functions or futures. Futures are values which are only computed when the value is queried. The query executes in the context of the querying user, rather than the user who originally defined the future. Likewise, fields containing functions or custom-defined logic (closures) are executed under the privileges of the invoking user, …

2025

Duplicate Advisory: SurrealDB is Vulnerable to Unauthorized Data Exposure via LIVE Query Subscriptions

Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-7vm2-j586-vcvc. This link is maintained to preserve external references. Original Description A flaw was found in the live query subscription mechanism of the database engine. This vulnerability allows record or guest users to observe unauthorized records within the same table, bypassing access controls, via crafted LIVE SELECT subscriptions when other users alter or delete records.

SurrealDB is Vulnerable to Unauthorized Data Exposure via LIVE Query Subscriptions

LIVE SELECT statements are used to capture changes to data within a table in real time. Documents included in WHERE conditions and DELETE notifications were not properly reduced to respect the querying user's security context. Instead the leaked documents reflect the context of the user triggering the notification. This allows a record or guest user with permissions to run live query subscriptions on a table to observe unauthorised records within …

SurrealDB server-takeover via SurrealQL injection on backup import

The SurrealDB command-line tool allows exporting databases through the export command. It was discovered that table or field names are not properly sanitized in exports, leading to a SurrealQL injection when the backup is reimported. For the injection to occur, an authenticated System User with OWNER or EDITOR roles needs to create tables or fields with malicious names containing SurrealQL, subsequently exported using the export operation The attacker could achieve …

SurrealDB no JavaScript script function default timeout could facilitate DoS

Through enabling the scripting capability. SurrealDB allows for advanced functions with complicated logic, by allowing embedded functions to be written in JavaScript. These functions are bounded for memory and stack size, but not in time. An attacker could launch a number of long running functions that could potentially facilitate a Denial Of Service attack. This vulnerability can only affect SurrealDB servers explicitly enabling the scripting capability with –allow-scripting or –allow-all …

SurrealDB memory exhaustion via string::replace using regex

An authenticated user can craft a query using the string::replace function that uses a Regex to perform a string replacement. As there is a failure to restrict the resulting string length, this enables an attacker to send a string::replace function to the SurrealDB server exhausting all the memory of the server due to string allocations. This eventually results in a Denial-of-Service situation for the SurrealDB server. This issue was discovered …

SurrealDB CPU exhaustion via custom functions result in total DoS

SurrealDB allows authenticated users with OWNER or EDITOR permissions at the root, database or namespace levels to define their own database functions using the DEFINE FUNCTION statement A custom database function comprises a name together with a function body. In the function body, the user programs the functionality of the function in terms of SurrealQL. The language includes a FOR keyword, used to implement for-loops. Whilst the parser and interpreter …

SurrealDB bypass of deny-net flags via redirect results in server-side request forgery (SSRF)

SurrealDB offers http functions that can access external network endpoints. A typical, albeit not recommended configuration would be to start SurrealDB with all network connections allowed with the exception of a deny list. For example, surreal start –allow-net –deny-net 10.0.0.0/8 will allow all network connections except to the 10.0.0.0/8 block. An authenticated user of SurrealDB can use redirects to bypass this restriction. For example by hosting a server on the …

SurrealDB vulnerable to memory exhaustion via nested functions and scripts

In order to prevent DoS situations due to infinite recursions, SurrealDB implements a limit of nested calls for both native functions and embedded JavaScript functions. However, in SurrealDB instances with embedded scripting functions enabled, it was found that this limit can be circumvented by utilizing both at the same time. If a native function contains JavaScript which issues a new query that calls that function, the recursion limit is not …

SurrealDB has local file read of 2-column TSV files via analyzers

An authenticated system user at the root, namespace, or database levels can use the DEFINE ANALYZER statement to point to arbitrary file locations on the file system, and should the file be tab separated with two columns, the analyzer can be leveraged to exfiltrate the content. This issue was discovered and patched during an code audit and penetration test of SurrealDB by cure53, the severity defined within cure53's preliminary finding …

2024

SurrealDB has an Uncaught Exception Handling Nonexistent Role

Roles for system users are stored as generic Ident values and converted as strings and into the Role enum whenever IAM operations are to be performed that require processing the user roles. This conversion expects those identifiers to only contain the values owner, editor and viewer and will return an error otherwise. However, the unwrap() method would be called on this result when implementing std::convert::From<&Ident> for Role, which would result …

SurrealDB has an Uncaught Exception Handling Parsing Errors on Empty Strings

The error rendering code from the parser would panic when handling failed parsing of queries where the error occurred when converting an empty string to a SurrealDB value. This would be the case when casting an empty string to a record, duration or datetime, as well as potentially when parsing an empty string to JSON or providing an empty string to the type::field and type::fields functions.

Improper Authorization in Select Permissions

Due to the order in which permissions were processed, some statements, filters and computations could lead to leaking field values or record contents to users without the required permissions. This behavior could be triggered in different scenarios: When performing a SELECT operation on a table, the values that would be returned were iterated over, field permissions would be validated and any unauthorized value would be removed from the result returned. …

Untrusted Query Object Evaluation in RPC API

During the sign in and sign up operations through the SurrealDB RPC API, an arbitrary object would be accepted in order to support a wide array of types and structures that could contain user credentials. This arbitrary object could potentially contain any SurrealDB value, including an object representing a subquery. For this to materialize, this object would need to be encoded using the bincode serialization format instead of the default …

SurrealDB vulnerable to Improper Authentication when Changing Databases as Scope User

Authentication would not be properly validated when an already authenticated scope user would use the use method or USE clause to switch working databases in a session. If there was a user record in the new database with identical record identifier as the original record that the user authenticated with in the original database, this could result in the user being able to perform actions under the identity of the …

Uncaught Exception in Macro Expecting Native Function to Exist

The query executor would panic when executing a query containing a call to a built-in SurrealDB function that did not exist. This could occur accidentally in situations where the version of the SurrealDB client was newer than the SurrealDB server or when a pre-parsed query was provided to the server via a newer version of the SurrealDB SDK.

Externally Controlled Format String in Scripting Functions

The rquickjs crate used by SurrealDB implements Rust bindings to the QuickJS C library and is used to execute SurrealDB scripting functions. The rquickjs function Exception::throw_type takes a string and returns an error object. Prior to version 0.4.2 of the crate, this string would be fed directly into printf, which will receive the error string as a format string with no additional arguments, leading to undefined behavior. This issue triggers …

SurrealDB vulnerable to Uncontrolled CPU Consumption via WebSocket Interface

SurrealDB depends on the tungstenite and tokio-tungstenite crates used by the axum crate, which handles connections to the SurrealDB WebSocket interface. On versions before 0.20.1, the tungstenite crate presented an issue which allowed the parsing of HTTP headers during the client handshake to continuously consume high CPU when the headers were very long. All affected crates have been updated in SurrealDB version 1.1.0. From the original advisory for CVE-2023-43669: "The …

Uncontrolled Recursion in SurrealQL Parsing

In some specific instances, the SurrealQL parser will attempt to recursively parse nested statements or idioms (i.e. nested IF and RELATE statements, nested basic idioms and nested access to attributes) without checking if the depth limit established by default or in the SURREAL_MAX_COMPUTATION_DEPTH environment variable is exceeded. This can lead to the stack overflowing when the nesting surpasses certain levels of depth.

Uncaught Exception in surrealdb

Although custom parameters and functions are only supported at the database level, it was allowed to invoke those entities at the root or namespace level. This would cause a panic which would crash the SurrealDB server, leading to denial of service.

2023

Full Table Permissions by Default

Default table permissions in SurrealDB were FULL instead of NONE. This would lead to tables having FULL permissions for SELECT, CREATE, UPDATE and DELETE unless some other permissions were specified via the PERMISSIONS clause. We have decided to treat this behaviour as a vulnerability due to its security implications, especially considering the lack of specific documentation and potential for confusion due to the INFO FOR DB statement previously not displaying …