SurrealDB: Graph traversal bypasses table SELECT permissions
Medium6.5CVE-2026-63746 · Published Jul 1, 2026 · updated Sep 4, 2026
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 ...
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| Date | Advisory | Severity | Fixed in |
|---|---|---|---|
| Jul 1 | SurrealDB: Edge PERMISSIONS FOR delete bypassed when a connected node is deleted | Medium5.4 | 3.1.0 |
| Jul 1 | SurrealDB: ES512 silently downgraded to ES384 due to jsonwebtoken crate limitation | Medium4.3 | 3.1.0 |
| Jul 1 | SurrealDB: Field-level SELECT permissions bypassed via indexed COUNT fast paths | Medium4.3 | 3.1.0 |
| Jul 1 | SurrealDB: USE NS/DB implicit creation bypasses DEFINE authorization | Medium6.5 | 3.1.0 |
| Jul 1 | SurrealDB: Port-specific --deny-net rules silently bypassed on HTTP redirect | Medium6.4 | 3.1.0 |
| Jul 1 | SurrealDB: Authenticated subscribers can read records hidden by SELECT permissions via LIVE subscriptions | Medium4.3 | 3.1.0 |