SurrealDB versions prior to 3.3.0 have an authorization bypass vulnerability that allows users with table-level write permissions to access fields restricted by SELECT permissions. This is achieved by exploiting JSON Patch operations to copy or move hidden fields into readable locations or by using test mismatch errors to disclose sensitive information.
SurrealDB versions before 3.3.0 have an authorization bypass vulnerability that allows users to read fields protected by field-level SELECT permissions. This occurs through LIVE SELECT projections where restricted fields can be accessed via the unreduced $after or $before parameters under an alias during CREATE, UPDATE, and DELETE notifications. The issue is fixed in version 3.3.0.
SurrealDB versions prior to 3.2.0 contain a vulnerability where an authenticated user scoped to one namespace/database can invoke a custom API belonging to another namespace/database by manipulating the URL path. This allows the user to access or modify data in another tenant's scope if the endpoint permissions are permissive. The vulnerability does not allow unauthenticated access or affect single-tenant deployments. Versions 3.2.0 and later include a fix that validates the namespace/database against the caller's authenticated scope, rejecting unauthorized cross-tenant access.
SurrealDB versions prior to 3.1.4 contain a vulnerability where array element-level SELECT permissions (field.*) are not correctly enforced for record users. This causes denied array elements to be partially leaked in query results. The issue affects only element-level permissions for record users, not field-level permissions or root/record-owner sessions. The vulnerability impacts confidentiality but does not allow data modification or privilege escalation. A fix is available in SurrealDB 3.1.4.
SurrealDB versions before 3.1.0 silently downgrade the ES512 JWT algorithm to ES384 due to a limitation in the underlying jsonwebtoken crate. This causes authentication handshake failures when ES512 keys are used, as the expected cryptographic curve does not match. The issue does not allow token forgery or compromise data confidentiality or integrity because ES384 remains cryptographically strong.
SurrealDB versions before 3.1.0 contain a denial of service vulnerability in their JSON parser due to failure to enforce recursion depth limits when processing nested braces, brackets, or parentheses. An unauthenticated attacker can exploit this by sending deeply nested JSON payloads to the WebSocket /rpc endpoint, causing server memory exhaustion and process crashes.
SurrealDB versions before 3.1.0 have an authorization bypass vulnerability in the KILL statement. This flaw allows authenticated users to terminate other users' live query subscriptions without verifying ownership. The vulnerability can disrupt real-time data subscriptions of other users. It has a CVSS 3.1 score of 5.4, indicating medium severity.
SurrealDB versions before 3.1.0 contain a vulnerability where user-supplied WHERE clauses in various query statements are evaluated against full record data before permission checks are enforced. This flaw allows authenticated users to bypass table-level permissions and read the full contents of any table within their current database. Exploitation is easier when scripting is enabled but can also occur through other SurrealQL features. The issue does not affect cross-namespace or cross-database boundaries.
SurrealDB versions before 3.1.0 have an information disclosure vulnerability where authenticated users with UPDATE permissions can read field values that should be hidden by field-level SELECT permissions. This occurs because error messages leak raw operand values when arithmetic or extend operations are performed on hidden fields. The vulnerability allows bypassing of field-level access controls via error message content.
SurrealDB versions prior to 3.1.0 have a vulnerability that allows authenticated users to bypass field-level SELECT permissions via JSON Patch operations. Specifically, using UPDATE PATCH with an empty 'from' pointer in 'copy' or 'move' operations enables duplication of all record fields, including those protected by field-level permissions, into attacker-controlled destination fields. This vulnerability has been withdrawn as a duplicate advisory but remains relevant for versions before 3.1.0.
SurrealDB versions before 3.1.0 contain a vulnerability where table SELECT permissions are not enforced during graph traversal. Authenticated users can read records from any table reachable through graph edges, bypassing intended access controls. This issue allows unauthorized data disclosure without requiring elevated privileges beyond authentication.
SurrealDB versions before 3.1.0 have a vulnerability in HTTP redirect handling that allows authenticated users to bypass port-specific --deny-net rules. This occurs because the port information is dropped during redirect policy evaluation, enabling redirects from allowed hostnames to denied host:port combinations to be followed.
SurrealDB versions up to 3.1.3 contain a vulnerability where SELECT permissions on array elements (field.*) are not properly enforced for record users. This flaw causes denied array elements to be leaked instead of hidden, allowing attackers with record scope access to read data they should not be able to access. The issue arises from incorrect index handling during permission filtering. This vulnerability has a CVSS score of 6.5, indicating a high severity impact on confidentiality without affecting integrity or availability.
SurrealDB versions 3.1.0 before 3.1.5 have a vulnerability where field-level SELECT permissions are bypassed when accessing records via graph-edge or back-reference traversals. This allows attackers with table-level SELECT access to read fields that should be restricted by field-level permissions. The issue arises because permissions are not enforced correctly during these traversal queries.
SurrealDB versions before 3.2.0 contain a vulnerability where custom API routes do not properly validate namespace and database scope. This allows authenticated users to access or invoke endpoints across different namespaces or databases by manipulating the URL path. The flaw can lead to unauthorized data access or unintended operations within other tenants' scopes.
SurrealDB versions before 3.2.0 have a permissions bypass vulnerability where data-modifying statements embedded within PERMISSIONS clauses execute without enforcement. This allows attackers with limited permissions to write to tables they should not have access to, potentially causing unintended data writes and corruption. The advisory is a duplicate and has been withdrawn in favor of GHSA-66r2-5gwj-gxm2.
SurrealDB versions 3.0.0 and later before 3.1.5 have a vulnerability where field-level SELECT permissions are not enforced on ORDER BY clauses. This allows authenticated users to infer the relative ordering of restricted field values even though the field values themselves are returned as null.
SurrealDB versions prior to 3.1.0 silently downgrade the ES512 JWT algorithm to ES384 due to a limitation in the underlying jsonwebtoken crate, causing authentication handshake failures when using the correct P-521 key type. This does not allow token forgery or compromise data integrity, but results in failed authentication when external systems expect true ES512 signatures. The issue is fixed in SurrealDB 3.1.0, which blocks use of ES512 with clear errors and deprecation warnings. Users should update to 3.1.0 or later and reconfigure JWT access methods to supported algorithms such as ES384.
SurrealDB versions prior to 3.1.0 contain a vulnerability where port-specific --deny-net rules can be bypassed via HTTP redirects. An authenticated user with access to http::* functions can cause SurrealDB to follow redirects to denied host:port combinations because the redirect handling drops the port information when matching deny rules. This allows circumvention of port-scoped network restrictions, potentially exposing internal services or sensitive endpoints. The issue is fixed in version 3.1.0 and later.
SurrealDB versions prior to 3.1.0 contain a vulnerability in the JSON Patch `copy` and `move` operations used in `UPDATE … PATCH` statements. Specifically, using an empty `from` pointer causes the entire record to be copied, bypassing field-level SELECT permissions and exposing protected field values under new field names. This vulnerability allows an authenticated user with update patch permissions to read any field in the targeted record regardless of select restrictions. The issue is limited to confidentiality impact and does not expose data from other records. Versions 3.1.0 and later include a patch that rejects empty `from` pointers, mitigating this issue.