Untrusted Query Object Evaluation in RPC API — surrealdb
Failure to Sanitize Special Elements into a Different Plane (Special Element Injection)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
| Software | From | Fixed in |
|---|---|---|
surrealdb
|
- | 1.5.5 |
|
surrealdb-core
|
- | 1.5.2 |
|
surrealdb
|
2.0.0-beta.1 | 2.0.0-beta.3 |
- https://github.com/surrealdb/surrealdb/commit/b7583a653a2c495a60630dffd663f506426db330
- https://github.com/surrealdb/surrealdb/commit/eab7ef5354168d4039f7f7b77042c99a52f770a6
- https://github.com/surrealdb/surrealdb/security/advisories/GHSA-64f8-pjgr-9wmr
- https://surrealdb.com/docs/surrealdb/integration/rpc#signin
- https://surrealdb.com/docs/surrealdb/integration/rpc#signup
- https://surrealdb.com/docs/surrealdb/security/authentication#record-users
Deep Security Visibility Without the Complexity
SynScan provides clear, real-time security insights so you can monitor your attack surface, spot risks early, and act fast—without extra complexity.
- No setup fees
- 5-min deployment
- Cancel anytime
Frequently Asked Questions
A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.
CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.
A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.
Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.
Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.
SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.