Summary
Untrusted Query Object Evaluation in RPC API
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.
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
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.
GHSA-64F8-PJGR-9WMR has a CVSS score of 8.8 (High). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (1.5.5, 1.5.2, 2.0.0-beta.3); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
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.
Frequently Asked Questions
- What is GHSA-64F8-PJGR-9WMR? GHSA-64F8-PJGR-9WMR is a high-severity security vulnerability in surrealdb (rust), affecting versions < 1.5.5. It is fixed in 1.5.5, 1.5.2, 2.0.0-beta.3.
- How severe is GHSA-64F8-PJGR-9WMR? GHSA-64F8-PJGR-9WMR has a CVSS score of 8.8 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which packages are affected by GHSA-64F8-PJGR-9WMR?
surrealdb(rust) (versions < 1.5.5)surrealdb-core(rust) (versions < 1.5.2)
- Is there a fix for GHSA-64F8-PJGR-9WMR? Yes. GHSA-64F8-PJGR-9WMR is fixed in 1.5.5, 1.5.2, 2.0.0-beta.3. Upgrade to this version or later.
- Is GHSA-64F8-PJGR-9WMR exploitable, and should I be worried? Whether GHSA-64F8-PJGR-9WMR is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-64F8-PJGR-9WMR is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-64F8-PJGR-9WMR?
- Upgrade
surrealdbto 1.5.5 or later - Upgrade
surrealdb-coreto 1.5.2 or later - Upgrade
surrealdbto 2.0.0-beta.3 or later
- Upgrade