GHSA-HV6H-HC26-Q48P: Field-level SELECT permissions bypassed via graph and reference traversals in SurrealDB

SurrealDB incorporates a declarative authorization engine that allows administrators to enforce schema permissions at multiple hierarchical layers. Table-level permissions determine whether a specific authenticated session can read or write any record within a target table. Field-level permissions provide granular control, allowing specific fields to be designated as completely hidden (PERMISSIONS FOR select NONE) or dynamically restricted based on custom session-dependent predicates.

During query execution, the database engine must consistently route retrieved records through a processing pipeline. This pipeline evaluates read-time computed fields and filters out restricted fields before returning the payload to the client. The attack surface examined here involves the streaming query planner, which was designed to optimize execution times for complex relational queries.

Within this query planner, relational operations such as graph edge traversals and reverse-reference scans are executed using specialized streaming operators. This analysis explores how an optimization helper bypassed crucial stages of the standard record-filtering pipeline. This omission allowed authenticated database users with low-privilege access to read fields specifically designated as restricted or confidential.

The root cause of this vulnerability lies within the shared helper function resolve_record_batch, located in the file surrealdb/core/src/exec/operators/scan/common.rs. This function is responsible for materializing full database records during streaming relational traversals, specifically for graph-edge scans in FullEdge mode and reverse-reference scans in FullRecord mode. While the helper correctly validated table-level select permissions, it failed to perform any subsequent field-level verification.

In standard execution paths, such as direct SELECT queries, retrieved database records are routed through the pipeline function filter_and_process_batch. This pipeline constructs a FieldState object for the target table, evaluates dynamic read-time COMPUTED fields, and filters individual fields using filter_fields_by_permission. The resolve_record_batch helper completely omitted these three essential steps when processing materialized records during traversals.

Because of this architectural omission, the database engine pushed raw, unfiltered record payloads directly into the streaming output channel once table-level checks succeeded. Consequently, fields explicitly configured with PERMISSIONS FOR select NONE or constrained by session predicates remained fully visible within the returned traversal results. Additionally, legitimate computed fields were omitted entirely because the evaluation pipeline was bypassed.

In the vulnerable versions of SurrealDB (v3.1.0 through v3.1.4), the loop inside resolve_record_batch materialized full records by directly extracting data from the transaction store without invoking the field-level pipeline. The following code snippet demonstrates the vulnerable logic:

// Vulnerable logic in resolve_record_batch
if fetch_full {
    let value = match Arc::try_unwrap(record) {
        Ok(rec) => rec.data,
        Err(arc) => arc.data.clone(),
    };
    // The raw data is appended to values without field-level pipeline filtering or computed field evaluation
    values.push(value);
} else {
    values.push(Value::RecordId(rid.clone()));
}

The official patch integrated the missing processing pipeline by importing FieldState, build_field_state, compute_fields_for_value, and filter_fields_by_permission. To optimize performance and avoid redundant database lookups for each record in a batch, a local thread-safe field_state_cache was implemented. The code block below illustrates the corrected implementation:

// Patched logic in resolve_record_batch (surrealdb/core/src/exec/operators/scan/common.rs)
let mut field_state_cache: std::collections::HashMap<TableName, FieldState> =
	std::collections::HashMap::new();
let skip_fetch_perms = ctx.root().skip_fetch_perms;
 
// ... inside loop over records
if fetch_full {
	let mut value = match Arc::try_unwrap(record) {
		Ok(rec) => rec.data,
		Err(arc) => arc.data.clone(),
	};
 
	// Retrieve or build the FieldState cache for the table
	if !field_state_cache.contains_key(&rid.table) {
		let fs = build_field_state(ctx, &rid.table, check_perms, None).await?;
		field_state_cache.insert(rid.table.clone(), fs);
	}
	let field_state = &field_state_cache[&rid.table];
	
	// Evaluate computed fields and enforce field-level permissions
	compute_fields_for_value(ctx, field_state, &mut value, skip_fetch_perms).await?;
	if check_perms {
		filter_fields_by_permission(ctx, field_state, &mut value).await?;
	}
 
	values.push(value);
}

To visualize how the vulnerability bypasses security boundaries compared to a direct query, consider the following pipeline flow diagram:

Exploiting this vulnerability requires a low-privileged database session with table-level SELECT authorization on the target structures. No complex network state or memory manipulation is necessary; the attacker simply issues a syntactically valid SurrealQL traversal query. To demonstrate this behavior, a test database schema can be defined with table-level select enabled but critical fields blocked.

Consider a table named knows configured with a field named secret that is restricted using PERMISSIONS FOR select NONE. Additionally, a computed field named label is defined to concatenate table values dynamically. When the unprivileged user executes a direct scan using SELECT * FROM knows, the engine correctly omits the secret field and computes the label value as expected.

However, if the user issues a graph-edge traversal query such as person:bob->(SELECT * FROM knows), the streaming query planner routes the execution through the vulnerable helper. The engine returns the full, unfiltered edge record containing the raw secret value. In addition to the confidentiality breach, the returned payload completely lacks the computed label field because the computed-field processor is never invoked.

The direct security impact of this vulnerability is the unauthorized disclosure of sensitive data fields to low-privileged database users. Attackers who possess valid credentials but are restricted by field-level access control policies can reconstruct confidential records. This bypass undermines the multi-tenant or role-based access control designs implemented in applications that rely on SurrealDB's field-level constraints.

It is critical to note that this vulnerability does not allow database administrative bypass or arbitrary code execution. An attacker cannot use this flaw to write to the database, modify schemas, or access tables where they do not already possess table-level select permissions. The vulnerability is entirely restricted to read-only access within the boundaries of the authorized tables involved in the traversal.

This vulnerability has been assigned a CVSS v3.1 base score of 4.3 (Medium). The vector string is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N. Because of the low complexity and lack of user interaction requirements, security teams should prioritize identifying systems using field-level permissions that run vulnerable versions of the database engine.

The definitive remediation for this vulnerability is upgrading the SurrealDB server to version 3.1.5 or later. This release incorporates the updated resolve_record_batch implementation, which correctly processes database records through the field-level authorization and computed field pipeline. No schema changes or table modifications are required upon upgrading.

For deployments where an immediate database upgrade is not feasible, a temporary workaround can be applied by disabling the streaming query planner. Administrators can force SurrealDB to fall back to the legacy compute-only executor by starting the server with the --planner-strategy compute-only CLI parameter. Alternatively, the same behavior can be enforced by defining the environment variable SURREAL_PLANNER_STRATEGY=compute-only prior to starting the database service.

In addition to the software configuration changes, security teams can conduct a schema audit to minimize the exposure of sensitive fields. If field-level security must be maintained without upgrading, consider extracting highly confidential data into dedicated tables. These tables can then be secured using robust table-level permissions, which are correctly enforced across all query paths in all versions of the engine.