GHSA-98fx-66cf-fc7c

A vulnerability was discovered where the user-supplied `WHERE` clause in a `SELECT` statement is evaluated against the full record data before `PERMISSIONS FOR SELECT WHERE` determines whether the principal is authorised to access that record. A side-effecting expression in the `WHERE` clause can exfiltrate record contents before the permission check runs. The same ordering bug affects the `SET`, `MERGE`, `CONTENT` and `PATCH` clauses of update-variant statements (`UPDATE`, `UPSERT-update`, `INSERT ON DUPLICATE KEY UPDATE`, `RELATE-update`). This vulnerability is confined to the attacker's current database. It does not cross namespace or database isolation boundaries. ### Impact An authenticated user — including Record and Scope users — can read the full contents of any table in the database they are authenticated against, bypassing `PERMISSIONS FOR SELECT WHERE` restrictions on those tables. The most direct exfiltration method requires scripting functions to be enabled (`--allow-scripting` / `-A`). However, exfiltration via SurrealQL's `THROW` statement is also feasible without scripting functions, and timing-based side-channel extraction is possible in all configurations. All tables within the attacker's current database, regardless of table-level `PERMISSIONS FOR SELECT WHERE` restrictions on those tables, are vulnerable to this attack. Tables in other databases within the same namespace, or within other namespaces, are not vulnerable. ### Patches A patch has been introduced that runs `check_permissions_table` before any user-supplied expression is evaluated against the record. A new `check_pre_update` helper centralises this ordering on every update-variant code path. Regression tests covering `WHERE`, `SET`, `MERGE`, `CONTENT`, `INSERT ON DUPLICATE KEY UPDATE`, and `RELATE` with `THROW` side-effects are included. - Versions 3.1.0 and later are not affected by this issue. ### Workarounds Affected users who are unable to update may want to: - **Disable