SurrealDB: Indexed ORDER BY leaks the value ordering of a SELECT-restricted field
Date: 2026-06
Affected: rust/surrealdb
Attack vector: info-disclosure
Category: vulnerability-disclosure
Severity: Medium
CWE: CWE-200
CVSS: 4.3 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N)

A field can be hidden from a user with a field-level SELECT permission (`DEFINE FIELD code ON secret PERMISSIONS FOR select WHERE owner = $auth.id`). When that field is indexed, a record user who cannot read it could still recover the relative ordering of its values across every record by issuing `ORDER BY <field>`: the field came back `null` as intended, but the rows were returned in the hidden values' true sorted order. To satisfy the sort, the planner selects the field's index and walks it in value order; the field-level permission is applied later, when the row is projected, so the value is nulled but the row order already encodes it. The guard that withholds restricted fields from the `WHERE` path was never applied to `ORDER BY`. ## Impact What an attacker **can** do: - As a record (scope) user with table SELECT, learn the relative ordering of a field hidden by a field-level SELECT permission, across other users' records, by ordering on it when an index covers the field — the value returns `null`, but the rows come back in the hidden values' order. - With rows they control in the same table, use that ordering to narrow the hidden values toward exact ones. What it **can't** do: - Read the field value directly — only its relative ordering leaks; the projected value is correctly redacted. - Cross table, record, or namespace/database boundaries — the table's SELECT permission and any row-level `WHERE` are still enforced, so only records the caller may already read are


Mitigations:

Architectural layers (MAESTRO):