GHSA-VJJX-RFW4-RMFC
Vulnerability from github – Published: 2026-07-01 20:10 – Updated: 2026-07-01 20:10An authenticated record or scope user could read records on any table reachable through a graph edge or REFERENCES TO back-reference, regardless of that table's PERMISSIONS FOR select clause.
Traversing SELECT * FROM source->edge->target returned full documents from target even when target was defined as PERMISSIONS FOR select NONE. The same bypass extended through multi-hop chains, so any table reachable by a sequence of edges from a readable starting point was exposed.
The root cause: GraphEdgeScan and ReferenceScan fetched records straight from storage without routing them through Document::pluck_select, so the target table's permission expression was never consulted.
Impact
An authenticated record or scope user can read records on any table reachable through a chain of graph edges or back-references from a table they have select on, regardless of the target's PERMISSIONS FOR select clause. Confidentiality-only and bounded to the caller's current database — namespace and database isolation are unaffected.
Patches
A new per-batch permission cache (exec::permission::CachedTableSelect) resolves each target table's SELECT permission once and filters yielded values through check_permission_for_value, matching the regular SELECT code path.
- Versions 3.1.0 and later are not affected.
Workarounds
- Remove
selectpermission on edge tables whose targets should be hidden. - Use namespace or database isolation as the primary boundary where feasible.
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "surrealdb"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.1.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-01T20:10:34Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "An authenticated record or scope user could read records on any table reachable through a graph edge or `REFERENCES TO` back-reference, regardless of that table\u0027s `PERMISSIONS FOR select` clause.\n\nTraversing `SELECT * FROM source-\u003eedge-\u003etarget` returned full documents from `target` even when `target` was defined as `PERMISSIONS FOR select NONE`. The same bypass extended through multi-hop chains, so any table reachable by a sequence of edges from a readable starting point was exposed.\n\nThe root cause: `GraphEdgeScan` and `ReferenceScan` fetched records straight from storage without routing them through `Document::pluck_select`, so the target table\u0027s permission expression was never consulted.\n\n### Impact\n\nAn authenticated record or scope user can read records on any table reachable through a chain of graph edges or back-references from a table they have `select` on, regardless of the target\u0027s `PERMISSIONS FOR select` clause. Confidentiality-only and bounded to the caller\u0027s current database \u2014 namespace and database isolation are unaffected.\n\n### Patches\n\nA new per-batch permission cache (`exec::permission::CachedTableSelect`) resolves each target table\u0027s `SELECT` permission once and filters yielded values through `check_permission_for_value`, matching the regular `SELECT` code path.\n\n- Versions 3.1.0 and later are not affected.\n\n### Workarounds\n\n- Remove `select` permission on edge tables whose targets should be hidden.\n- Use namespace or database isolation as the primary boundary where feasible.",
"id": "GHSA-vjjx-rfw4-rmfc",
"modified": "2026-07-01T20:10:34Z",
"published": "2026-07-01T20:10:34Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/surrealdb/surrealdb/security/advisories/GHSA-vjjx-rfw4-rmfc"
},
{
"type": "PACKAGE",
"url": "https://github.com/surrealdb/surrealdb"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "SurrealDB: Graph traversal bypasses table SELECT permissions"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.