Advisoriesby IbisSurrealDB: Graph traversal bypasses table SELECT permissions
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'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...
Affected versions
| Package | Affected | Fixed in |
|---|---|---|
| surrealdb crates.io | < 3.1.0 | 3.1.0 |
Details and references
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'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 `select` permission on edge tables whose targets should be hidden. - Use namespace or database isolation as the primary boundary where feasible.
More SurrealDB advisories
All SurrealDB
SurrealDB: Edge PERMISSIONS FOR delete bypassed when a connected node is deletedCVE-2026-49997fixed in 3.1.0SurrealDB: ES512 silently downgraded to ES384 due to jsonwebtoken crate limitationCVE-2026-63761fixed in 3.1.0SurrealDB: Field-level SELECT permissions bypassed via indexed COUNT fast pathsCVE-2026-63742fixed in 3.1.0SurrealDB: USE NS/DB implicit creation bypasses DEFINE authorizationCVE-2026-63741fixed in 3.1.0SurrealDB: Port-specific --deny-net rules silently bypassed on HTTP redirectCVE-2026-63743fixed in 3.1.0SurrealDB: Authenticated subscribers can read records hidden by SELECT permissions via LIVE subscriptionsCVE-2026-63749fixed in 3.1.0