surrealdb-core

A scalable, distributed, collaborative, document-graph database, for the realtime web

View on Cargo

View on Github

Activity

Latest release: 1d ago
Total releases: 129
Cadence: ~5 days
Last 12 months: 57

Reach

Downloads: 1.6M
Stars: 33.2k

Details

License: unknown
First release: Jan 30, 2024

Releases

Version	Released
`3.3.5` patch	Oct 29, 2026
`4.0.0-beta.1` pre	Oct 28, 2026
`3.2.6` patch	Oct 19, 2026
`3.3.4` patch	Oct 13, 2026
`3.3.3` patch	Oct 10, 2026
`3.3.2` patch	Oct 08, 2026
`3.3.1` patch	Oct 07, 2026
`3.2.5` patch	Oct 05, 2026
`3.3.0` minor	Sep 24, 2026
`2.7.0` minor 1 CVE	Sep 23, 2026
`3.3.0-beta.4` pre	Sep 09, 2026
`3.1.6` patch 1 CVE	Sep 01, 2026
`3.3.0-beta.3` pre	Aug 20, 2026
`3.3.0-beta.2` pre	Aug 18, 2026
`3.3.0-beta.1` pre	Aug 14, 2026
`3.2.4` patch	Aug 03, 2026
`3.2.3` patch	Jul 21, 2026
`3.2.2` patch	Jul 21, 2026
`3.2.1` patch	Jul 10, 2026
`3.2.0` minor	Jul 02, 2026
`3.2.0-beta.3` pre 1 CVE	Jul 01, 2026
`3.2.0-beta.2` pre 1 CVE	Jun 26, 2026
`3.2.0-beta.1` pre 1 CVE	Jun 24, 2026
`3.1.5` patch 1 CVE	Jun 19, 2026
`3.1.4` patch 1 CVE	Jun 10, 2026
`3.1.3` patch 1 CVE	Jun 03, 2026
`3.1.2` patch 1 CVE	May 27, 2026
`3.1.1` patch 1 CVE	May 27, 2026
`3.1.0` minor 1 CVE	May 26, 2026
`3.1.0-beta.3` pre 1 CVE	May 14, 2026
`3.1.0-beta.2` pre 1 CVE	May 08, 2026
`3.1.0-beta.1` pre 1 CVE	May 01, 2026
`3.0.5` patch 1 CVE	Mar 27, 2026
`2.6.5` patch 1 CVE	Mar 24, 2026
`2.6.4` patch 1 CVE	Mar 17, 2026
`3.0.4` patch 1 CVE	Mar 13, 2026
`3.0.3` patch 1 CVE	Mar 10, 2026
`2.6.3` patch 1 CVE	Mar 04, 2026
`3.0.2` patch 1 CVE	Mar 03, 2026
`3.0.1` patch 1 CVE	Feb 24, 2026
`3.0.0` major 1 CVE	Feb 17, 2026
`3.0.0-rc.1` pre 1 CVE	Feb 16, 2026
`2.6.2` patch 1 CVE	Feb 16, 2026
`2.6.1` patch 1 CVE	Feb 12, 2026
`3.0.0-beta.4` pre 1 CVE	Feb 10, 2026
`3.0.0-beta.3` pre 1 CVE	Feb 05, 2026
`2.6.0` minor 1 CVE	Jan 27, 2026
`2.5.0` minor 1 CVE	Jan 22, 2026
`3.0.0-beta.2` pre 1 CVE	Jan 16, 2026
`2.4.1` patch 1 CVE	Jan 08, 2026

1–50 of 129

Repository

surrealdb/surrealdb

Forks: 1.4k
Open issues: 333
Language: Rust
: 5.9/ 10

database
distributed
distributed-database
document-database
realtime-database
cloud-database

Dependencies (107)

Depends on

3.3.5

Used by

Supply-chain exposure

15 tracked projects depend on this, <1% of every package we track.

A known CVE here directly exposes every one of them.

Vulnerable dependencies

2 of 103

rand_core critical 1 CVE
paste 1 CVE

These dependencies are still vulnerable in their latest release. Whether the exact version this package pins is affected isn't checked yet.

Known CVEs (9)

CVE-2026-63733 GHSA-66r2-5gwj-gxm2 Sep 04, 2026

SurrealDB: Writes in a PERMISSIONS clause bypass table permissions

4.3 / 10
Medium
Network Low Low None Unchanged None Low None

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:

DEFINE TABLE post PERMISSIONS FOR update WHERE (CREATE log SET at = time::now()) OR true;

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 unintended events, cascades, or data corruption on those tables.

What it can't do:

Escape the caller's own namespace and database — a permission clause cannot switch namespace or database.

Perform root- or namespace-level actions such as creating users; the caller's role still applies.

Read hidden data — this is an integrity issue, not disclosure.

Patches

Permission clauses must now be read-only: defining or importing one that contains a write is rejected, and any write attempted while a clause is evaluated is blocked at runtime, including writes reached through a called function. Read-only clauses are unaffected.

Versions 3.2.0 and later are not affected by this issue.

Workarounds

Users unable to patch should consider the following workarounds:

Review your PERMISSIONS clauses and remove any containing CREATE, UPDATE, DELETE, RELATE, INSERT, or UPSERT.

Limit who can define schema and vet imported data — such a clause must be defined before it can be triggered.

Resources

DEFINE TABLE … PERMISSIONS

DEFINE FIELD

fix(core): reject writes in PERMISSIONS clauses and block writes during permission evaluation (included in SurrealDB 3.2.0)

Acknowledgements

Thank you to sondt99 for reporting this issue.

Fixed in

3.2.0

References

https://github.com/surrealdb/surrealdb/security/advisories/GHSA-66r2-5gwj-gxm2
https://nvd.nist.gov/vuln/detail/CVE-2026-63733
https://github.com/surrealdb/surrealdb/commit/1e4c3d743e1591f14f340cb627e56d98b6bd7fd7
https://github.com/surrealdb/surrealdb/commit/afea699dfb3c8f274ab36861f8a95f5e98d82f1b
https://github.com/surrealdb/surrealdb
https://github.com/surrealdb/surrealdb/releases/tag/v3.2.0

Updated Sep 04, 2026 · Source: OSV.dev
CVE-2024-58356 GHSA-27vq-hv74-7cqp Dec 16, 2024

SurrealDB has Silent Failure to Overwrite Table Definition of Relation Type

Low
Network Low Low None

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 have been modified using the OVERWRITE clause in order to update permissions are advised to verify that the intended permissions are in place using the INFO FOR DB statement. Affected users who are unable to update and require updating permissions in a table with TYPE RELATION will be required to remove the table and define it from scratch with the intended permissions. Data can be preserved by backing it up to a temporary table.

References

#5260

Fixed in

2.1.4

References

https://github.com/surrealdb/surrealdb/security/advisories/GHSA-27vq-hv74-7cqp
https://nvd.nist.gov/vuln/detail/CVE-2024-58356
https://github.com/surrealdb/surrealdb/pull/5260
https://github.com/surrealdb/surrealdb/commit/2f9a58f830c24f107b4783da1f0704a502bc7734
https://github.com/surrealdb/surrealdb
https://www.vulncheck.com/advisories/surrealdb-before-permission-bypass-via-define-table-overwrite

Updated Sep 04, 2026 · Source: OSV.dev
CVE-2024-58359 GHSA-m52v-24p8-654f Nov 22, 2024

SurrealDB has an Uncaught Exception Sorting Tables by Random Order

6.5 / 10
Medium
Network Low Low None Unchanged None None High

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 re-started after a crash.

References

https://github.com/surrealdb/surrealdb/issues/4969

https://github.com/surrealdb/surrealdb/pull/4989

https://github.com/surrealdb/surrealdb/pull/4805

https://github.com/surrealdb/surrealdb/pull/4906

Fixed in

2.1.0

References

https://github.com/surrealdb/surrealdb/security/advisories/GHSA-m52v-24p8-654f
https://github.com/surrealdb/surrealdb/issues/4969
https://github.com/surrealdb/surrealdb/pull/4805
https://github.com/surrealdb/surrealdb/pull/4906
https://github.com/surrealdb/surrealdb/pull/4989
https://github.com/surrealdb/surrealdb

Updated Jul 19, 2026 · Source: OSV.dev
CVE-2024-58358 GHSA-jc55-246c-r88f Nov 22, 2024

SurrealDB has an Uncaught Exception Handling Nonexistent Role

4.9 / 10
Medium
Network Low High None Unchanged None None High

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 user, referencing unexistent roles will no longer result in a panic and will instead throw an InvalidRole error.

Version 2.1.0 and later are not affected by this issue.

Workarounds

Affected users who are unable to update may want to limit access to users with the owner role at any level to trusted parties only. 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.

Resourcess

#5079

#5092

Fixed in

2.1.0

References

https://github.com/surrealdb/surrealdb/security/advisories/GHSA-jc55-246c-r88f
https://nvd.nist.gov/vuln/detail/CVE-2024-58358
https://github.com/surrealdb/surrealdb/pull/5079
https://github.com/surrealdb/surrealdb/pull/5092
https://github.com/surrealdb/surrealdb
https://www.vulncheck.com/advisories/surrealdb-before-denial-of-service-via-nonexistent-role

Updated Sep 04, 2026 · Source: OSV.dev
CVE-2024-58357 GHSA-h4f5-h82v-5w4r Nov 22, 2024

SurrealDB has an Uncaught Exception in Function Generating Random Time

6.5 / 10
Medium
Network Low Low None Unchanged None None High

The rand::time() function in SurrealQL generates a random time from an optional range of two Unix timestamps. Due to the underlying use of timestamp_opt 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 security capabilities. 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

#5126

SurrealQL Documentation - Database Functions (rand::time)

SurrealDB Documentation - Security Capabilities (Functions)

Fixed in

2.1.0

References

https://github.com/surrealdb/surrealdb/security/advisories/GHSA-h4f5-h82v-5w4r
https://github.com/surrealdb/surrealdb/pull/5126
https://github.com/surrealdb/surrealdb

Updated Jul 19, 2026 · Source: OSV.dev
CVE-2024-58367 GHSA-9722-9j67-vjcr Oct 08, 2024

SurrealDB: Improper Authorization in Select Permissions

High
Network Low Low None

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 returned as the returned field would not match the original field where permissions had been defined.

When calling a function in the context of a SELECT query and passing a field with permissions as an argument to the function (e.g. SELECT string::lowercase(private) FROM data), the function would receive the field value before it had been removed from the document due to SELECT permissions. As a result, the function would have access to the value of the field regardless of field permissions. This case includes functions called from within events and other clauses that support function calling.

When executing a query containing a WHERE clause filtering records by a field that the querying user does not have access to SELECT (e.g. SELECT public FROM data WHERE private ~ "secret"), the response of that query would still take the value of the field into account. Even though the value of the protected field would not be returned, this behavior could be used as a side channel by the querying user to infer information about the value of the field.

When performing UPDATE or DELETE operations over a table with a user that had those permissions but no SELECT permission, the RETURN BEFORE clause could be used (e.g. DELETE data RETURN BEFORE) to read the contents of the records prior to the authorized update or the deletion despite the querying user not being authorized to perform SELECT operations.

When performing UPDATE operations on a table for which the user had SELECT and UPDATE permissions, the SET clause could reference fields that the user had UPDATE but no SELECT permission for (e.g. UPDATE data SET public = private) in order to update the value of a field that the user had permission to SELECT to the value of another field for which the user did not.

Impact

Clients that were authorized by table permissions to execute SELECT statements for a table but were not authorized by field permissions to run SELECT queries for a specific field could still have been able to gain knowledge of the value of that field. Additionally, clients that were authorized to execute UPDATE or DELETE statements for a table but not authorized to execute SELECT statements for the same table may have been able to gain knowledge of the contents of records in that table. This could only be exploited by users who were already authorized to execute queries on the database with the affected table or field.

Due to its relationship with table and field permissions, which apply mainly to record users rather than system users, this issue mostly affects users relying on SurrealDB as a backend-as-a-service rather than SurrealDB as a traditional database backend.

Patches

The behavior when evaluating table or field permissions and filtering records or fields as a result of those evaluations has been improved to consider permissions before any changes to the document have been made and, when relevant, permissions after changes to the document have taken place. When a user is unauthorized to view record contents and field values by permissions, the returned documents will behave as if the record or field did not exist in order to prevent leaking any information.

Version 2.0.4 and later are not affected by this issue.

Workarounds

Users affected by this issue and unable to update should not rely on the authorization provided by field permissions when it comes to the SELECT permission. Instead, read access to fields in affected versions should be restricted at the table level. When allowing the UPDATE or DELETE operations for records via table permissions, users should not rely of the authorization provided by the SELECT permission. Instead, users should not allow clients to UPDATE or DELETE records that they should not be able to view.

Fixed in

2.0.4

References

https://github.com/surrealdb/surrealdb/security/advisories/GHSA-9722-9j67-vjcr
https://nvd.nist.gov/vuln/detail/CVE-2024-58367
https://github.com/surrealdb/surrealdb/issues/2161
https://github.com/surrealdb/surrealdb/issues/3924
https://github.com/surrealdb/surrealdb/pull/4785
https://github.com/surrealdb/surrealdb/pull/4800

Updated Sep 04, 2026 · Source: OSV.dev
CVE-2024-58361 GHSA-qjrv-v6qp-x99x Oct 08, 2024

SurrealDB has an Uncaught Exception Handling Parsing Errors on Empty Strings

High
Network Low Low None

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 want to ensure that the SurrealDB process is running so that it can be automatically re-started after a crash.

Fixed in

2.0.4

References

https://github.com/surrealdb/surrealdb/security/advisories/GHSA-qjrv-v6qp-x99x
https://github.com/surrealdb/surrealdb/pull/4923
https://github.com/surrealdb/surrealdb/commit/709d6efe901dbf3e207b4fc2ebc30775595efc16
https://github.com/surrealdb/surrealdb

Updated Jul 19, 2026 · Source: OSV.dev
CVE-2024-58362 GHSA-64f8-pjgr-9wmr Sep 11, 2024

Untrusted Query Object Evaluation in RPC API

High
Network Low Low None

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 editor role.

Impact

If a record access method was defined with a SIGNIN or a SIGNUP query and the SurrealDB RPC API was exposed to untrusted users, an attacker could be able to craft a binary object containing a subquery to provide in place of valid credentials when calling the signin and signup operations via the RPC API with the bincode serialization format. The attacker could use that subquery to select, create, update and delete resources in SurrealDB, but they would not be able to directly view the results of the query. This method cannot be used to create, update or delete IAM resources, as access to those kind of resources requires the owner role.

Patches

Objects provided as variables to the sign in and sign up methods are now recursively validated to ensure that they do not contain any non-computed values, which include subqueries and other data types that could potentially result in query execution.

Version 1.5.5 and later are not affected by this issue.

Version 2.0.0-beta.3 and later are not affected by this issue.

Workarounds

Users unable to update may want to disallow access to the SurrealDB RPC API using the affected binary serialization formats by conservatively allowing only requests to the /rpc endpoint of the SurrealDB HTTP server with the application/json content type. If the RPC API is not used at all or only used by trusted clients, disallowing or restricting access to the /rpc endpoint of the SurrealDB HTTP server will also prevent exploitation. Alternatively, if filtering HTTP requests is not possible, record access methods that define SIGNIN and SIGNUP clauses may be temporarily removed to completely prevent potential attacks leveraging this issue.

References

SurrealDB Documentation - Authentication (Record Users)

SurrealDB Documentation - RPC Protocol (Signup)

SurrealDB Documentation - RPC Protocol (Signin)

Fixed in

1.5.2

References

https://github.com/surrealdb/surrealdb/security/advisories/GHSA-64f8-pjgr-9wmr
https://github.com/surrealdb/surrealdb/commit/b7583a653a2c495a60630dffd663f506426db330
https://github.com/surrealdb/surrealdb/commit/eab7ef5354168d4039f7f7b77042c99a52f770a6
https://github.com/surrealdb/surrealdb
https://surrealdb.com/docs/surrealdb/integration/rpc#signin
https://surrealdb.com/docs/surrealdb/integration/rpc#signup

Updated Jul 19, 2026 · Source: OSV.dev
CVE-2024-58363 GHSA-gh9f-6xm2-c4j2 Jul 11, 2024

SurrealDB vulnerable to Improper Authentication when Changing Databases as Scope User

Medium
Network Low Low None

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 become authorized to query data under the identity of a specific scope user associated with an identical record identifier in a different database within the same SurrealDB instace if the PERMISSIONS clause would allow it due to relying exclusively on the $auth parameter, which would point to the impersonated user. The impact is limited to the single user with matching record identifier.

The impact of this issue is mitigated if the table PERMISSIONS clause explicitly checks for an scope that only exists in the specific database (e.g. $scope = "production") or certain claims of the authentication token (e.g. $token.email = "example@example.com"), both of which would remain unchanged in the session of the authenticated user after changing databases. Permissions will default to NONE if there is no PERMISSIONS clause, which also mitigates this impact of this issue.

Patches

Version 1.5.4 and later are not affected by this issue.

Version 2.0.0-alpha.6 and later will not be affected by this issue.

Workarounds

Users unable to update may want to ensure that table PERMISSIONS clauses explicitly check that the $scope parameter matches a scope that is uniquely named across databases in the same SurrealDB instance. Ensuring that record identifiers for users are automatically generated or explicitly generated to be unique across databases may also be sufficient to mitigate this issue, as the $auth parameter will not link to any user record and any PERMISSIONS clauses restricting authorization based on the authenticated user should fail to successfully evaluate.

References

https://github.com/surrealdb/surrealdb/pull/4335

Fixed in

1.5.1

References

https://github.com/surrealdb/surrealdb/security/advisories/GHSA-gh9f-6xm2-c4j2
https://github.com/surrealdb/surrealdb/pull/4335
https://github.com/surrealdb/surrealdb/commit/492f8378d57968dbdf5e63fad41b6ff59bba0b80
https://github.com/surrealdb/surrealdb

Updated Jul 19, 2026 · Source: OSV.dev

Insights

Releases per month

last 12 months

Release mix

major 2
minor 14
patch 74
pre 38

129 releases

Dependencies over time

per release

Release calendar

2026

Jan

Feb

Mar

Apr

May

Jun

Jul

Aug

Sep

Oct

Nov

Dec

Less More