GHSA-c8jx-96c9-8xrp: SurrealDB Field-level SELECT Permissions Bypassed Vulnerability

MODERATE
CVSS 4.3
CWE-863
Published
Advisory Summary

GHSA-c8jx-96c9-8xrp is a MODERATE (CVSS 4.3) field-level select permissions bypassed vulnerability (CWE-863: Incorrect Authorization) affecting SurrealDB libraries in the crates.io ecosystem. The issue involves field-level select permissions bypassed via indexed count fast paths. Remediation is available by upgrading affected packages to version 3.1.0.

GHSA-c8jx-96c9-8xrp at a Glance

CVE Identifier N/A
GHSA Identifier GHSA-c8jx-96c9-8xrp
Severity MODERATE
CVSS v3.1 Base Score 4.3
CWE Classification CWE-863: Incorrect Authorization
Affected Product SurrealDB
Package Ecosystem crates.io
Published Date
Last Updated

Security Impact

CVSS: 4.3

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required Low (PR:L)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality Low (C:L)
Integrity None (I:N)
Availability None (A:N)

How to Fix GHSA-c8jx-96c9-8xrp

To remediate this vulnerability, upgrade all affected SurrealDB dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

surrealdb fixed: 3.1.0
Upgrade surrealdb to 3.1.0
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for surrealdb

How to Check if You Are Affected

To determine whether your application is affected by GHSA-c8jx-96c9-8xrp, inspect your project dependencies for SurrealDB:

inspect dependencies for surrealdb

Analyze the terminal output to locate any version of SurrealDB in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 3.1.0), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-863: Incorrect Authorization, where the product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check. In SurrealDB, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

A record user could learn the value of a hidden field by counting how many records match a guess. When `DEFINE FIELD ... PERMISSIONS FOR select WHERE ...` hides a field's contents from a caller, and that field is indexed, running `SELECT count() FROM t WHERE hidden_field = "guess" GROUP ALL` returned a count greater than zero whenever a record actually had that value — even though the caller was never allowed to read the field directly. The query planner used an indexed-COUNT shortcut (`Index::Count`, `IndexCountScan`, or the legacy `Iterate Index Count` / `Iterate Index Keys` paths) that counts matching index entries and skips the permission check that would normally hide the value. The same query with `WITH NOINDEX` correctly returned `[]`, confirming the gap. By repeating the count query with different guesses, an attacker can confirm or recover the contents of any restricted field they could not read through a normal `SELECT`. ### Impact What an attacker **can** do: - Confirm or recover values of a field protected by field-level SELECT permissions on any table they hold table-level SELECT on, provided the field is indexed. - Repeat the query with different guesses to read restricted field contents one value at a time. What it **can't** do: - Read fields that are not indexed (the shortcut only fires when an index covers the predicate column). - Cross table, database or namespace isolation boundaries. - Modify data, escalate privileges, or affect availability. ### Patches The legacy planner (`surrealdb/core/src/idx/planner/tree.rs`) and the streaming planner (`surrealdb/core/src/exec/planner/select/mod.rs`) now both refuse the indexed fast path when the WHERE / ORDER tree references a field governed by a non-`Full` SELECT permission: - `resolve_indexes` skips any B-tree / unique index whose columns are governed by such a permission. - A new `cond_touches_restricted_field` flag is propagated; `eval_count` refuses a dedicated `Index::Count` when set. - The streaming planner adds `cond_touches_restricted_select_field`, a `RestrictedIdiomChecker` visitor that matches each idiom against the table's field-permission prefixes (loaded via the plan-time txn), and gates `IndexCountScan` emission on it. - The fast paths are preserved for root / owner sessions via `should_check_perms_for_view`. Versions 3.1.0 and later are not affected. ### Workarounds Users unable to patch are advised to consider the following workarounds: - Avoid `DEFINE INDEX` on fields whose values are protected by field-level SELECT permissions. The class of attack is specific to the indexed fast paths. - Restrict the ability of record users to issue arbitrary `SELECT count() … GROUP ALL` queries against tables containing field-protected columns. - Use namespace / database isolation as the primary boundary where feasible.

GHSA-c8jx-96c9-8xrp Affected SurrealDB Versions

1 component(s)
Fixed Versions:
3.1.0
Product / Package Ecosystem Affected Versions Fixed Version
surrealdb
crates.io
< 3.1.0
3.1.0

References

Frequently Asked Questions

What is GHSA-c8jx-96c9-8xrp?
GHSA-c8jx-96c9-8xrp is a security vulnerability in SurrealDB involving Field-level SELECT permissions bypassed via indexed COUNT fast paths under CWE-863: Incorrect Authorization.
Which SurrealDB versions are affected?
Affected versions include releases prior to 3.1.0 across affected packages: surrealdb.
What version fixes GHSA-c8jx-96c9-8xrp?
Upgrading to 3.1.0 (or the latest patched release for your respective branch) resolves the vulnerability.
Is surrealdb affected?
Yes, surrealdb is affected in releases prior to 3.1.0. Upgrade your dependency to 3.1.0 or later.
What is the CVSS score of GHSA-c8jx-96c9-8xrp?
GHSA-c8jx-96c9-8xrp has a CVSS v3.1 base score of 4.3 (MODERATE) with vector string CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N.
What CWE is associated with GHSA-c8jx-96c9-8xrp?
GHSA-c8jx-96c9-8xrp is classified under CWE-863: Incorrect Authorization (The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check.).
How can I check crates.io dependencies for GHSA-c8jx-96c9-8xrp?
Run the dependency tree command: 'inspect dependencies for surrealdb'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-c8jx-96c9-8xrp",
  "modified" : "2026-07-01T20:22:06Z",
  "published" : "2026-07-01T20:22:06Z",
  "aliases" : [ ],
  "summary" : "SurrealDB: Field-level SELECT permissions bypassed via indexed COUNT fast paths",
  "details" : "A record user could learn the value of a hidden field by counting how many records match a guess.\n\nWhen `DEFINE FIELD ... PERMISSIONS FOR select WHERE ...` hides a field's contents from a caller, and that field is indexed, running `SELECT count() FROM t WHERE hidden_field = \"guess\" GROUP ALL` returned a count greater than zero whenever a record actually had that value — even though the caller was never allowed to read the field directly. The query planner used an indexed-COUNT shortcut (`Index::Count`, `IndexCountScan`, or the legacy `Iterate Index Count` / `Iterate Index Keys` paths) that counts matching index entries and skips the permission check that would normally hide the value. The same query with `WITH NOINDEX` correctly returned `[]`, confirming the gap.\n\nBy repeating the count query with different guesses, an attacker can confirm or recover the contents of any restricted field they could not read through a normal `SELECT`.\n\n### Impact\n\nWhat an attacker **can** do:\n\n- Confirm or recover values of a field protected by field-level SELECT permissions on any table they hold table-level SELECT on, provided the field is indexed.\n- Repeat the query with different guesses to read restricted field contents one value at a time.\n\nWhat it **can't** do:\n\n- Read fields that are not indexed (the shortcut only fires when an index covers the predicate column).\n- Cross table, database or namespace isolation boundaries.\n- Modify data, escalate privileges, or affect availability.\n\n### Patches\n\nThe legacy planner (`surrealdb/core/src/idx/planner/tree.rs`) and the streaming planner (`surrealdb/core/src/exec/planner/select/mod.rs`) now both refuse the indexed fast path when the WHERE / ORDER tree references a field governed by a non-`Full` SELECT permission:\n\n- `resolve_indexes` skips any B-tree / unique index whose columns are governed by such a permission.\n- A new `cond_touches_restricted_field` flag is propagated; `eval_count` refuses a dedicated `Index::Count` when set.\n- The streaming planner adds `cond_touches_restricted_select_field`, a `RestrictedIdiomChecker` visitor that matches each idiom against the table's field-permission prefixes (loaded via the plan-time txn), and gates `IndexCountScan` emission on it.\n- The fast paths are preserved for root / owner sessions via `should_check_perms_for_view`.\n\nVersions 3.1.0 and later are not affected.\n\n### Workarounds\n\nUsers unable to patch are advised to consider the following workarounds:\n\n- Avoid `DEFINE INDEX` on fields whose values are protected by field-level SELECT permissions. The class of attack is specific to the indexed fast paths.\n- Restrict the ability of record users to issue arbitrary `SELECT count() … GROUP ALL` queries against tables containing field-protected columns.\n- Use namespace / database isolation as the primary boundary where feasible.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "crates.io",
      "name" : "surrealdb"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "3.1.0"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/surrealdb/surrealdb/security/advisories/GHSA-c8jx-96c9-8xrp"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/surrealdb/surrealdb/pull/240"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/surrealdb/surrealdb/commit/0c6dd021bb55b32a78a553c72bb9c0cdd414825f"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/surrealdb/surrealdb"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-863" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-07-01T20:22:06Z",
    "nvd_published_at" : null
  }
}