Listen to this Post
How GHSA-hv6h-hc26-q48p Works
SurrealDB enforces field‑level `SELECT` permissions via DEFINE FIELD ... PERMISSIONS FOR select. When a table is readable at the table level but contains a field with a restrictive permission (e.g. DEFINE FIELD secret ON knows PERMISSIONS FOR select NONE), a direct `SELECT FROM knows` correctly hides the `secret` field. However, an authenticated record user can bypass this field‑level filter by retrieving the same records through graph‑edge (->), back‑reference (<~), or target‑vertex traversals.
The root cause lies in the shared `resolve_record_batch` helper, which is used by both `GraphEdgeScan` (FullEdge) and `ReferenceScan` (FullRecord). This helper enforces only the table‑level `SELECT` permission and returns raw record data without invoking the field‑level filtering logic (build_field_state / filter_fields_by_permission) that ordinary table scans and `fetch_record` apply. As a result, traversals such as person:bob->(SELECT FROM knows), person:bob<~(SELECT FROM comment), or `->knows->(SELECT FROM person)` materialise full objects including fields that should be hidden.
The impact is confined to confidentiality: the caller can read hidden field values on tables they already have table‑level `SELECT` access to. The table’s own `SELECT` permission and any row‑level `WHERE` predicate are still enforced, so the attacker cannot access records they are not end to read. Root and record‑owner sessions are unaffected, and data cannot be modified. Versions before 3.1.0 also exposed whole records on tables the caller could not read, but that issue was addressed separately (GHSA‑vjjx‑rfw4‑rmfc). The fix in 3.1.5 ensures `resolve_record_batch` now applies field‑level `SELECT` permissions and read‑time `COMPUTED` fields, matching the behaviour of regular table scans.
DailyCVE Form:
Platform: SurrealDB
Version: 3.1.0 – 3.1.4
Vulnerability: Field‑level SELECT bypass via graph/reference traversals
Severity: Medium (CVSS v4)
date: 2026‑06‑19
Prediction: 2026‑06‑19 (fixed in 3.1.5)
What Undercode Say
Analytics & Detection
To identify whether your SurrealDB instance is vulnerable, check the version:
surreal version
If the output shows `3.1.0` through 3.1.4, the instance is affected. You can also audit query logs for traversals that materialise full objects on tables with field‑level permissions.
Reproduction (Proof of Concept)
Assuming a table `knows` with a hidden field secret:
-- Define the table and field-level permission
DEFINE TABLE knows PERMISSIONS FOR select FULL;
DEFINE FIELD secret ON knows PERMISSIONS FOR select NONE;
-- Insert a record
INSERT INTO knows (id, secret) VALUES ('knows:1', 'hidden_value');
-- Direct SELECT hides the field (correct)
SELECT FROM knows; -- returns { id: 'knows:1' }
-- Traversal via graph-edge exposes the hidden field (vulnerable)
SELECT FROM person:bob->(SELECT FROM knows);
-- returns { id: 'knows:1', secret: 'hidden_value' }
Exploit
An authenticated user with table‑level `SELECT` privileges can execute any of the following traversals to read hidden fields:
– Graph‑edge traversal:
`person:bob->(SELECT FROM knows)`
- Back‑reference traversal:
`person:bob<~(SELECT FROM comment)`
- Target‑vertex projection:
`->knows->(SELECT FROM person)`
These queries materialise full records without applying field‑level filters, leaking the values of fields that should be restricted.
Protection
Immediate Mitigation (Workarounds)
- Force the legacy (unaffected) executor by starting SurrealDB with:
--planner-strategy compute-only
or set the environment variable:
export SURREAL_PLANNER_STRATEGY=compute-only
– Do not rely on field‑level `SELECT` permissions to hide values on tables that are reachable via graph edges, references, or traversals. Instead, restrict access at the table level using DEFINE TABLE ... PERMISSIONS.
– Use namespace or database isolation as the primary security boundary where feasible.
Permanent Fix
Upgrade to SurrealDB 3.1.5 or later. The patch modifies `resolve_record_batch` to apply field‑level permissions and read‑time `COMPUTED` fields, ensuring traversals honour the same filters as direct table scans.
Impact
- Confidentiality breach: Hidden field values are exposed to users who have table‑level `SELECT` access.
- Scope: Limited to the field‑permission layer; no cross‑table, cross‑record, or cross‑namespace/database access is granted.
- No modification: The vulnerability is read‑only; data cannot be altered.
- No effect on root or record‑owner sessions: Only affects non‑privileged record users.
- Versions before 3.1.0: Already addressed by GHSA‑vjjx‑rfw4‑rmfc (table‑level bypass), which is a separate, more severe issue.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
