Answer in brief
CVE-2026-63746 records a Medium severity (CVSS 6.5) vulnerability in SurrealDB: Graph traversal bypasses table SELECT permissions. The current sources do not mark it as known exploited. The current feed maps surrealdb (rust). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 6.5. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps surrealdb (rust). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| surrealdbrust | <3.1.0 | 3.1.0 |
Published upstream
Jul 1, 2026
Evidence: source:ghsa:source_dates:source-dates:recordSource modified
Sep 4, 2026
Evidence: source:ghsa:source_dates:source-dates:recordFirst seen by HOL
Jul 1, 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 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.
Quoted source text, attributed separately from HOL analysis.