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
9 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
A PERMISSIONS ... WHERE clause is evaluated with permission enforcement disabled, so it can't recurse into its own checks. But the clause could also contain data-modifying statements, and these ran with enforcement still off — so evaluating a permission check could write to tables the caller cannot write. For example: Any user allowed to update a post now also creates a log record, even with no permission on log. The clause is evaluated once per matched record, so one statement can cause several writes. Impact Only databases with a PERMISSIONS clause that contains a write are affected; FULL, NONE, and read-only clauses are not. What an attacker can do: - With permission to perform the guarded operation (a low-privileged or record user is enough), write to tables in their own database that their permissions would otherwise forbid, by triggering an operation the clause guards. - Cause several writes from a single statement — the clause is evaluated once per matched record. - Trigger…
Recommended action: Upgrade to 3.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 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 1.5.2 or later, 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 1.5.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.