Summary
SurrealDB vulnerable to Improper Authentication when Changing Databases as Scope User
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.
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
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 = "[email protected]"), 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.
The application does not adequately verify the identity of a user, device, or process before granting access. Typical impact: unauthorized access to functions or data reserved for authenticated parties.
GHSA-GH9F-6XM2-C4J2 has a CVSS score of 6.3 (Medium). 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.4, 2.0.0-alpha.6, 1.5.1); 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
- 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.
Frequently Asked Questions
- What is GHSA-GH9F-6XM2-C4J2? GHSA-GH9F-6XM2-C4J2 is a medium-severity improper authentication vulnerability in surrealdb (rust), affecting versions <= 1.5.3. It is fixed in 1.5.4, 2.0.0-alpha.6, 1.5.1. The application does not adequately verify the identity of a user, device, or process before granting access.
- How severe is GHSA-GH9F-6XM2-C4J2? GHSA-GH9F-6XM2-C4J2 has a CVSS score of 6.3 (Medium). 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-GH9F-6XM2-C4J2?
surrealdb(rust) (versions <= 1.5.3)surrealdb-core(rust) (versions <= 1.5.0)
- Is there a fix for GHSA-GH9F-6XM2-C4J2? Yes. GHSA-GH9F-6XM2-C4J2 is fixed in 1.5.4, 2.0.0-alpha.6, 1.5.1. Upgrade to this version or later.
- Is GHSA-GH9F-6XM2-C4J2 exploitable, and should I be worried? Whether GHSA-GH9F-6XM2-C4J2 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-GH9F-6XM2-C4J2 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-GH9F-6XM2-C4J2?
- Upgrade
surrealdbto 1.5.4 or later - Upgrade
surrealdbto 2.0.0-alpha.6 or later - Upgrade
surrealdb-coreto 1.5.1 or later
- Upgrade