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.
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. …
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 …
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 …
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.
The span rendering would panic when handling failed parsing of queries where the error occurred on a line terminator character.
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 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 …
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.
The ID, DB and NS headers accepted by the SurrealDB HTTP REST API would fail to parse when containing some special characters. This would cause a panic which would crash the SurrealDB server, leading to denial of service. This issue only affects the SurrealDB binary; it does not affect the SurrealDB library.
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.
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 …