GHSA-8RW6-P7M8-63JP: Array Element-Level SELECT Permissions Leak in SurrealDB

SurrealDB is a multi-model cloud-native database engine written in Rust. It supports fine-grained access control policies, allowing administrators to define table-level and field-level permissions. These permissions are evaluated dynamically during query execution to ensure that users only access authorized data structures.

This specific vulnerability involves an improper authorization mechanism (CWE-285) in SurrealDB's permission evaluation engine. When field-level or element-level SELECT permissions are evaluated on arrays, the database engine can fail to apply restrictions to certain array elements. This failure allows unauthorized authenticated record users to read restricted elements from records they otherwise have access to.

The attack surface is exposed through standard ad-hoc query interfaces, such as the SurrealDB HTTP API or WebSocket endpoints. An attacker authenticated with a low-privilege record account can exploit this flaw by issuing standard SELECT queries against tables with array elements protected by restricted permissions. The vulnerability resides within the document reduction and output pipelines of the database engine.

The underlying security flaw stems from a logical index-shifting discrepancy during array mutation. When evaluating element-level SELECT permissions (e.g., using field.* or wildcard mappings like items[*]), SurrealDB expands these rules into distinct paths for each array index. The expansion produces sequential index-based target paths such as items[0], items[1], and items[2] using the Value::each function.

When an array element fails its corresponding permission check, the query engine removes it immediately from the active collection. This removal is executed by calling the Value::cut function, which internally invokes Rust's standard vector manipulation function, Vec::remove(index). The removal of an element from a dynamic array causes all subsequent elements in the vector to shift left by one index position.

Because the database engine processed array elements in an ascending, forward-iterating loop, the leftward shift invalidates the alignment of remaining indices. For example, if the element at index 0 is removed, the element at index 1 is immediately shifted to index 0. On the subsequent iteration, the loop counter advances to index 1, completely skipping the evaluation of the element that was just shifted to index 0. Consequently, this skipped element bypasses its permission checks entirely and is returned to the user.

The vulnerability was present in multiple files governing document processing: reduce.rs, output.rs, and pipeline.rs. In each of these modules, the permission evaluation loops iterated forward over paths generated by each(). The patch implements a simple yet critical change: reversing the iteration sequence (.rev()) so that elements are evaluated and removed from the highest index down to the lowest index.

By processing the vector in reverse order, any index-shifting side effects caused by Vec::remove only affect indices that have already been evaluated. Lower indices that are pending evaluation remain structurally undisturbed in their original positions. This ensures that every element is subject to the permission engine.

Additionally, in the output projection code (doc/output.rs), the patch introduces a lazy snapshot mechanism. It clones the projected output dynamically if element-level permissions are encountered. The engine then reads target values from this immutable snapshot while executing cuts on the active output value, preventing multi-pass alignment mismatches.

// Before the patch in doc/reduce.rs:
match &fd.select_permission {
    Permission::None => {
        for k in original.doc.as_ref().each(&fd.name).iter() {
            doc.doc.to_mut().cut(k);
        }
    }
}
 
// After the patch in doc/reduce.rs:
match &fd.select_permission {
    Permission::None => {
        // SECURITY: iterate in reverse so dynamic cuts do not shift indices
        for k in original.doc.as_ref().each(&fd.name).iter().rev() {
            doc.doc.to_mut().cut(k);
        }
    }
}

Exploitation of this vulnerability requires the attacker to hold valid, low-privilege credentials capable of executing SELECT queries on a target table. The target table must have element-level permissions configured on an array field. The attack is executed purely through standard SQL queries, making it highly reliable and independent of memory layout or operating system specifics.

Consider an array containing elements [{n: 0}, {n: 1}, {n: 2}, {n: 3}] where select permission is denied on all elements (WHERE false). In a vulnerable database version, the engine first processes index 0 ({n: 0}). Since it fails, index 0 is cut, shifting {n: 1} to index 0, {n: 2} to index 1, and {n: 3} to index 2.

The loop then advances to index 1, which now contains {n: 2}. It evaluates and cuts {n: 2}, shifting {n: 3} to index 1. The loop then advances to index 2, but the vector length is now 2, terminating the loop. The returned array contains [{n: 1}, {n: 3}]. These odd-indexed elements have completely bypassed the WHERE false restriction, leaking restricted data to the client.

The primary security consequence of this vulnerability is unauthorized data disclosure. Attackers with restricted table access can bypass element-level filters to read sensitive fields within records, violating confidentiality guarantees. In multi-tenant environments where shared tables use element-level filters to partition sensitive tenant data, this bypass can lead to cross-tenant data leaks.

The CVSS v3.1 score is evaluated as 6.5 (Medium severity) with the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N. Confidentiality impact is high because unauthorized database record elements can be systematically extracted. There is no impact on integrity or availability, as the logical error is confined to the read path and does not permit unauthorized data modification or denial-of-service states.

While this vulnerability does not allow remote code execution or full system compromise directly, it acts as a significant privilege escalation vector within the database's internal authorization framework. It can be chained with other application-level vulnerabilities to extract critical application state or configuration secrets stored in database tables.

The definitive remediation for this vulnerability is upgrading SurrealDB to a patched version that incorporates the reversed iteration logic. The official fix is applied in the codebase via commit 8f89b260bb9692e5b0d58930793d482a8207eedc. Database administrators must deploy this patch to all production and staging instances containing sensitive array configurations.

If an immediate upgrade is not feasible, administrators should modify their schema definitions to avoid element-level permission rules on arrays. Instead of using nested array structures with wildcard permissions (items[*]), developers can normalize the data schema by separating array elements into distinct tables. Standard row-level permissions can then be applied to these separate tables safely.

Another temporary workaround is to enforce filtering within the application layer. The database can be configured with strict table-level restrictions, and the application backend can query the database using administrative privileges and perform element-level filtering manually before delivering responses to end-users. This approach completely bypasses the vulnerable database output pipeline.