Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
54 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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 same records through a traversal that yields full objects — person:bob-(SELECT FROM knows), person:bob<~(SELECT FROM comment), or a projected target vertex -knows-(SELECT FROM person) — returned it intact. The root cause: the shared resolverecordbatch helper used by GraphEdgeScan (FullEdge) and ReferenceScan (FullRecord) enforced only the table-level SELECT permission and pushed raw record data, never running the field-level filtering (buildfieldstate / filterfieldsbypermission) that ordinary table scans and fetchrecord apply. Impact A record user can read the values of…
Recommended action: Upgrade to 3.1.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 `: the field came back `null` as intended, but the rows were returned in the hidden values' true sorted order. To satisfy the sort, the planner selects the field's index and walks it in value order; the field-level permission is applied later, when the row is projected, so the value is nulled but the row order already encodes it. The guard that withholds restricted fields from the `WHERE` path was never applied to `ORDER BY`. Impact What an attacker can do: - As a record (scope) user with table SELECT, learn the relative ordering of a field hidden by a field-level SELECT permission, across other users' records, by ordering on it when an index covers the field — the value…
Recommended action: Upgrade to 3.1.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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(' ')`). 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 no restriction at all — and empty is the default. Impact The file is read with the privileges of the SurrealDB process, so a database `EDITOR` or `OWNER` user can disclose the contents of any file the process can access. Only the first line of the file is returned, except for files with no newlines. However recovering the process's command line and environment could expose startup root credentials (`--user` / `--pass`) and secret environment variables, escalating a single-database role toward full control of the instance. The read on…
Recommended action: Upgrade to 3.1.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 request forgery (SSRF). The protected `HttpClient` used by `http::*` functions re-checks every redirect hop and was hardened in 3.1.0, but the JWKS fetcher uses its own client and was not covered. Impact What an attacker can do: - With the Owner role at database level or above (the minimum required to run `DEFINE ACCESS ... TYPE JWT URL` or `TYPE RECORD ... WITH JWT URL`), point an access method at an allowlisted host they control and redirect the server's GET to an otherwise-blocked target —…
Recommended action: Upgrade to 3.1.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 the crash varies between SurrealDB versions. Whilst exploiting the vulnerability requires users to be able to run arbitrary queries, if guest access (--allow-guests), is enabled, then guests can perform this attack. Impact Any user able to execute queries on a SurrealDB instance with scripting enabled (--allow-scripting) can cause complete denial of service. The server process terminates immediately without graceful shutdown. The underlying cause of the vulnerability is a null pointer dereference in the QuickJS-NG v0.8…
Recommended action: Upgrade to 3.0.0-beta.3 (pre-release) or 2.6.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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, not the creator. This results in a confused deputy vulnerability: an attacker with limited privileges can define a malicious function or future field that performs privileged actions. When a higher-privileged user (such as a root owner or namespace administrator) executes the function or queries or modifies that record, the function executes with their elevated permissions. Impact An attacker who can create or update function/future fields can plant logic that executes with a privileged user’s context. If a privileged user performs a…
Recommended action: Upgrade to 3.0.0-beta.3 (pre-release) or 2.5.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 public internet which redirects to the IP addresses blocked by the administrator of the SurrealDB server via HTTP 301 or 307 response codes. When sending SurrealDB statements containing the http:: functions to the attacker controlled host, the SurrealDB server will follow the redirects to the blocked IP address. Because the statements also return the responses to the attacker, this issue constitutes a full SSRF vulnerability. This issue was discovered and patched during an code audit and penetration test of SurrealDB by…
Recommended action: Upgrade to 2.2.2, 2.1.5 or 2.0.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 constrain the number of iterations for a single for-loop, nesting several for-loops with a large number of iterations is possible. Thus, an attacker could define a function that comprises several nested for-loops with an iteration count of 1.000.000 each. Executing the function will consume all the CPU time of the server, timeouts configured will not break the CPU consumption, and the function execution monopolizes all CPU time of the SurrealDB server, effectively preventing the server from executing functions, queries, commands of…
Recommended action: Upgrade to 2.2.2, 2.1.5 or 2.0.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 and equivalent environment variables SURREALCAPSALLOWSCRIPT=true and SURREALCAPSALLOWALL=true. 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 is Low, matched by our CVSS v4 assessment. Impact An attacker can use the scripting capabilities of SurrealDB to run a series of long running functions to facilitate a Denial Of Service attack. Patches A default timeout for the scripting…
Recommended action: Upgrade to 2.2.2, 2.1.5 or 2.0.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 and patched during an code audit and penetration test of SurrealDB by cure53. Using CVSSv4 definitions, the severity is High. Impact An authenticated user can crash the SurrealDB instance through memory exhaustion Patches A patch has been created that enforces a limit on string length SURREALGENERATIONALLOCATIONLIMIT - Versions 2.0.5, 2.1.5, 2.2.2, and later are not affected by this issue Workarounds Affected users who are unable to update may want to limit the ability of untrusted clients to run the string::replace function in the affected…
Recommended action: Upgrade to 2.2.2, 2.1.5 or 2.0.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 a privilege escalation and root level access to the SurrealDB instance if a higher privileged user subsequently performs the import operation. Furthermore, applications using SurrealDB that allow its users to define custom fields or tables are at risk of a universal second order SurrealQL injection, even if query parameters are properly sanitized. 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 is Critical,…
Recommended action: Upgrade to 2.2.2, 2.1.5 or 2.0.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 is Low, matched by our CVSS v4 assessment. Impact Limited to unauthorised access to 2 column TSV files on the file system Patches A patch has been created that introduces a new environment variable, SURREALFILEALLOWLIST , which contains a list of allowed file paths. When a mapping file is processed, the mapper checks if the file’s path is within one of the allowed paths. - Versions 2.1.5, 2.2.2 and later are not affected by this issue. Workarounds Users unable to update may want to limit those with root, namespace, or database level users to trusted…
Recommended action: Upgrade to 2.2.2 or 2.1.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 triggered. Once executed, SurrealDB will follow the path of infinite recursions until the system runs out of memory, prior to the recursion limit being triggered. This vulnerability can only affect SurrealDB servers explicitly enabling the scripting capability with --allow-scripting or --allow-all and equivalent environment variables SURREALCAPSALLOWSCRIPT=true and SURREALCAPSALLOWALL=true. This issue was discovered and patched during an code audit and penetration test of SurrealDB by cure53, the severity defined within cure53's preliminary…
Recommended action: Upgrade to 2.2.2, 2.1.5 or 2.0.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability was found where an attacker can crash the database via crafting a HTTP query that returns a null byte. The problem relies on an uncaught exception in the net module, where the result of the query will be converted to JSON before showing as the HTTP response to the user in the /sql endpoint. Impact This vulnerability allows any authenticated user to crash a SurrealDB instance by sending a crafted query with a null byte to the /sql endpoint. Where SurrealDB is used as an application backend, it is possible that an application user can crash the SurrealDB instance and thus the supported application through crafted inputs that exploit this attack vector. Patches A patch has been introduced that ensures the error is caught and converted as an error. - Versions 2.2.2, 2.1.5 and 2.0.5 and later are not affected by this isssue Workarounds Affected users who are unable to update may want to limit the ability of untrusted clients to run arbitrary queries in the affected…
Recommended action: Upgrade to 2.2.2, 2.1.5 or 2.0.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The OVERWRITE clause of the DEFINE TABLE statement would fail to overwrite data for tables that were defined with TYPE RELATION. Since table definitions include the PERMISSIONS clause, this failure would result in permissions not being overwritten as a result, which may potentially lead users to believe they have changed the table permissions when they have not. Impact If a user attempted to update table permissions of a table defined with TYPE RELATION using DEFINE TABLE ... OVERWRITE, permissions for the table would not be changed. This may allow a client that is authorized to run queries in a SurrealDB server to access certain data in that specific table that they were not intended to be able to access after the specified change in permissions. Patches The DEFINE TABLE statement has been updated to appropriately overwrite data for tables defined with TYPE RELATION. - Version 2.1.4 and later are not affected by this issue. Workarounds Users of tables with TYPE RELATION that may…
Recommended action: Upgrade to 2.1.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Sorting table records using an ORDER BY clause with the rand() function as sorting mechanism could cause a panic due to relying on a comparison function that did not implement total order. This event resulted in a panic due to a recent change in Rust 1.81. Impact A client that is authorized to run queries in a SurrealDB server would be able to query a table with ORDER BY rand() in order to potentially cause a panic in the sorting function. This would crash the server, leading to denial of service. Patches The sorting algorithm has been updated to guarantee total order when shuffling records. - Version 2.1.0 and later are not affected by this issue. Workarounds Affected users who are unable to update may want to limit the ability of untrusted clients to run arbitrary SurrealQL queries in the affected versions of SurrealDB. To limit the impact of the denial of service, SurrealDB administrators may also want to ensure that the SurrealDB process is running so that it can be automatically…
Recommended action: Upgrade to 2.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 in a panic where a nonexistent role was used. Impact A privileged user with the owner role at any level in SurrealDB would be able to define a user with DEFINE USER with an nonexistent role, which would panic when being converted to a Role enum in order to perform certain IAM operations with that user. These operations included signing in with the user. This would crash the server, leading to denial of service. Patches Unexistent roles are no longer accepted during parsing when defining a user. Even when successfully associated with a…
Recommended action: Upgrade to 2.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The rand::time() function in SurrealQL generates a random time from an optional range of two Unix timestamps. Due to the underlying use of timestampopt from the chrono crate, this function could potentially return None in some instances, leading to a panic when unwrap was called on its result in order to return a SurrealQL datetime type to the caller of the function. Impact A client that is authorized to run queries in a SurrealDB server would be able to make repeated (in the order of millions) calls to rand::time() in order to reliably trigger a panic. This would crash the server, leading to denial of service. Patches The function has been updated in to guarantee that some datetime is returned or that an error is otherwise gracefully handled. - Version 2.1.0 and later are not affected by this issue. Workarounds Affected users who are unable to update may want to limit the ability of untrusted clients to run the rand::time() function in the affected versions of SurrealDB using…
Recommended action: Upgrade to 2.1.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. However, performing a SELECT VALUE operation (e.g. SELECT VALUE private FROM data) would result in a non-iterable value, which would not be removed from the returned result. - When aliasing a field (e.g. SELECT private AS public FROM data) for which the user did not have SELECT permissions within a SELECT query, permissions would be checked against the field of the resulting document containing the aliased field instead of the original document containing the original field. As a consequence, the original field value would be…
Recommended action: Upgrade to 2.0.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Impact A client that is authorized to run queries in a SurrealDB server would be able to execute a malformed query which would fail to parse when converting an empty string and cause a panic in the error rendering code. This would crash the server, leading to denial of service. Patches - Version 2.0.4 and later are not affected by this issue. Workarounds Affected users who are unable to update may want to limit the ability of untrusted clients to run arbitrary SurrealQL queries in the affected versions of SurrealDB. To limit the impact of the denial of service, SurrealDB administrators may also…
Recommended action: Upgrade to 2.0.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 JSON serialization format or the additionally supported CBOR serialization format. If a binary object containing a subquery were to be provided in this way, that subquery would be computed while executing the SIGNIN and SIGNUP queries defined by the database owner while defining a record access method. Since those queries are executed under a system user session with the editor role, an unauthenticated attacker may be able to leverage this behavior to select, create, update and delete non-IAM resources with permissions of a system user with the…
Recommended action: Upgrade to 2.0.0-beta.3 (pre-release) or 1.5.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 unrelated user in the new database. This issue does not affect system users at any level. By default, record identifiers are randomly generated with sufficient complexity to prevent the identifier collision required to trigger this issue. However, the issue may trigger in situations where multiple databases in the same SurrealDB instance are using explicitly defined or incremental record identifiers to identify users on an identically named table. Impact Under the circumstances described above, a user who has an authenticated session as a scope user in a database could…
Recommended action: Upgrade to 2.0.0-alpha.6 (pre-release) or 1.5.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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::throwtype 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 when a SurrealDB scripting function returns an error and its input contains a format string such as %s or %d. This vulnerability can only affect SurrealDB servers explicitly enabling the scripting capability with --allow-scripting or --allow-all and equivalent environment variables SURREALCAPSALLOWSCRIPT=true and SURREALCAPSALLOWALL=true. Impact An attacker with privileges to execute scripting functions with arbitrary inputs may be able to exploit this format string vulnerability in order read arbitrary memory from the remote SurrealDB process.…
Recommended action: Upgrade to 1.1.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Impact A client that is authorized to run queries in a SurrealDB server is able to craft and execute a pre-parsed query invoking a nonexistent built-in function, which will cause a panic. This will crash the server, leading to denial of service. Patches - Version 1.2.0 and later are not affected by this issue. Workarounds Concerned users unable to update may want to limit the ability of untrusted users to run arbitrary SurrealQL queries in the affected versions of SurrealDB. To limit the impact of the denial of service, SurrealDB administrators may also want to ensure that the SurrealDB process is running so that it can be automatically re-started…
Recommended action: Upgrade to 1.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The span rendering would panic when handling failed parsing of queries where the error occurred on a line terminator character. Impact A client that is authorized to run queries in a SurrealDB server is able to execute a malformed query which will fail to parse on a line terminator character and cause a panic in the span rendering code. This will crash the server, leading to denial of service. Patches - Version 1.2.1 and later are not affected by this issue. Workarounds Concerned users unable to update may want to limit the ability of untrusted users to run arbitrary SurrealQL queries in the affected versions of SurrealDB. To limit the impact of the denial of service, SurrealDB administrators may also want to ensure that the SurrealDB process is running so that it can be automatically re-started after a crash. References - #3527 - https://github.com/StarlaneStudios/Surrealist/issues/177
Recommended action: Upgrade to 1.2.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.