Jun 20, 2026·6 min read·9 visits
A vulnerability in SurrealDB's streaming query planner allows authenticated, low-privileged users to bypass field-level SELECT permissions and access restricted data by using graph edge or reverse-reference traversals.
A security vulnerability exists in SurrealDB's streaming query planner where streaming graph edge traversals or reverse-reference traversals bypass field-level SELECT permissions. This vulnerability allows an authenticated database user with valid, low-privileged credentials holding table-level SELECT permissions to bypass field-level access controls and read highly confidential or restricted fields.
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.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N| Product | Affected Versions | Fixed Version |
|---|---|---|
surrealdb SurrealDB | >= 3.1.0, <= 3.1.4 | 3.1.5 |
| Attribute | Detail |
|---|---|
| CWE ID | CWE-862 |
| Attack Vector | Network |
| CVSS Score | 4.3 (Medium) |
| EPSS Score | N/A |
| Impact | Confidentiality Bypass (Read-only) |
| Exploit Status | Proof-of-Concept |
| KEV Status | Not Listed |
The software does not perform an authorization check when an actor attempts to access a resource or perform an action.
An argument injection vulnerability in GitPython allows remote or local attackers to execute arbitrary file reads or arbitrary file overwrites via unsafe command option forwarding. This occurs because the wrapper methods `IndexFile.checkout()` and `TagReference.create()` fail to validate parameters before passing them to system-level git invocations.
An argument injection vulnerability in GitPython allows remote or local attackers with control over repository archive configuration options to retrieve arbitrary local files via native git archive commands. During clone operations, a sibling missing validation vulnerability in the clone option engine allows attackers to perform Server-Side Request Forgery via the git clone bundle-uri mechanism.
GitPython prior to version 3.1.56 is vulnerable to argument injection in the Commit.count method. An attacker who controls keyword arguments passed to this method can inject arbitrary Git options, such as --output, leading to arbitrary file truncation on the host filesystem.
A critical SQL injection vulnerability was discovered in Sequelize when configured to use the Oracle database dialect. Due to a flawed optimization design in the SQL escaping subsystem (src/sql-string.js), strings that begin with native Oracle date functions bypass standard escaping. This allows unauthenticated remote attackers to execute arbitrary SQL commands on the target database.
CVE-2026-59881 is a protocol compliance and input validation vulnerability in the client-side WebSocket implementation of the aiohttp asynchronous HTTP client/server framework for Python. Prior to version 3.14.2, the framework's parser unexpectedly accepts and attempts to decompress frames containing the RSV1 bit, even when the permessage-deflate extension has not been negotiated during the initial WebSocket handshake. This violation of RFC 6455 allows a malicious or compromised server to bypass client configuration, forcing decompression routines that can lead to high CPU and memory consumption, resulting in a denial-of-service condition.
An asynchronous HTTP client/server framework for asyncio and Python, aiohttp prior to version 3.14.2 is vulnerable to HTTP Request Smuggling. The server-side HTTP parser immediately transitions the protocol state to 'upgraded' upon receiving a WebSocket upgrade request before consuming the accompanying request body. If the backend handler rejects the upgrade request while keeping the TCP connection alive, the unconsumed request body remains in the socket buffer and is parsed as a subsequent pipelined HTTP request. This allows an attacker to smuggle requests, bypass frontend reverse proxy controls, and perform unauthorized actions.