Summary
Full Table Permissions by Default
Default table permissions in SurrealDB were FULL instead of NONE. This would lead to tables having FULL permissions for SELECT, CREATE, UPDATE and DELETE unless some other permissions were specified via the PERMISSIONS clause.
We have decided to treat this behaviour as a vulnerability due to its security implications, especially considering the lack of specific documentation and potential for confusion due to the INFO FOR DB statement previously not displaying default permissions. Treating it as a bug fix provides justification for a change in default behavior outside of a major release.
Workarounds
In unpatched versions, this issue can be resolved by explicitly defining table permissions as shown in the following examples:
-- INSECURE EXAMPLE
-- DEFINE TABLE insecure;
-- SECURE EXAMPLE 1
DEFINE TABLE secure PERMISSIONS NONE;
-- SECURE EXAMPLE 2
DEFINE TABLE secure PERMISSIONS FOR SELECT, CREATE, UPDATE, DELETE NONE;
-- SECURE EXAMPLE 3
DEFINE TABLE secure PERMISSIONS FOR
SELECT WHERE user = $auth.id,
CREATE, UPDATE, DELETE NONE;
-- SECURE EXAMPLE 4
DEFINE TABLE secure PERMISSIONS
FOR select WHERE published = true OR user = $auth.id
FOR create, update WHERE user = $auth.id
FOR delete WHERE user = $auth.id OR $auth.admin = true;
References
Impact
Any client authorized to query data in a SurrealDB instance will have full access to any tables that were defined with no explicit permissions and that are within its authorization scope (i.e. namespace or database), including creating, reading, updating and deleting data. This is specially relevant for SurrealDB instances allowing guest access with publicly exposed interfaces (e.g. HTTP REST API or WebSocket API), since a remote unauthenticated user may gain full access to any tables that were defined without any explicit permissions. Tables that were defined with explicit permissions using the PERMISSIONS clause are not affected.
GHSA-X5FR-7HHJ-34J3 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.0.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.0.1includes a patch for this specific issue. Later releases will also include the patch. - Version
1.1.0-beta.1and latest nightly releases already include the patch for this issue.
In patched versions:
- Tables defined after the patch without explicit permissions have
NONEpermissions. - Table permissions are always explicitly displayed with the
INFO FOR DBstatement.
Frequently Asked Questions
- What is GHSA-X5FR-7HHJ-34J3? GHSA-X5FR-7HHJ-34J3 is a high-severity security vulnerability in surrealdb (rust), affecting versions < 1.0.1. It is fixed in 1.0.1.
- How severe is GHSA-X5FR-7HHJ-34J3? GHSA-X5FR-7HHJ-34J3 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 versions of surrealdb are affected by GHSA-X5FR-7HHJ-34J3? surrealdb (rust) versions < 1.0.1 is affected.
- Is there a fix for GHSA-X5FR-7HHJ-34J3? Yes. GHSA-X5FR-7HHJ-34J3 is fixed in 1.0.1. Upgrade to this version or later.
- Is GHSA-X5FR-7HHJ-34J3 exploitable, and should I be worried? Whether GHSA-X5FR-7HHJ-34J3 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-X5FR-7HHJ-34J3 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-X5FR-7HHJ-34J3? Upgrade
surrealdbto 1.0.1 or later.