GitHub Security Advisory: GHSA-9722-9j67-vjcr
Package: surrealdb-core (RUST)
Severity: HIGH (CVSS 6.5)
CWE: CWE-285: Improper Authorization
Vulnerable versions: < 2.0.4
Patched in: 2.0.4

Summary: Improper Authorization in Select Permissions

Details:
Due to the order in which permissions were processed, some statements, filters and computations could lead to leaking field values or record contents to users without the required permissions. This behavior could be triggered in different scenarios:

- When performing a `SELECT` operation on a table, the values that would be returned were iterated over, field permissions would be validated and any unauthorized value would be removed from the result returned. However, performing a `SELECT VALUE` operation (e.g. `SELECT VALUE private FROM data`) would result in a non-iterable value, which would not be removed from the returned result.

- When aliasing a field (e.g. `SELECT private AS public FROM data`) for which the user did not have `SELECT` permissions within a `SELECT` query, permissions would be checked against the field of the resulting document containing the aliased field instead of the original document containing the original field. As a consequence, the original field value would be returned as the returned field would not match the original field where permissions had been defined.

- When calling a function in the context of a `SELECT` query and passing a field with permissions as an argument to the function (e.g. `SELECT string::lowercase(private) FROM data`), the function would receive the field value before it had been removed from the document due to `SELECT` permissions. As a result, the function would have access to the value of the field regardless of field permissions. This case includes functions called from within events and other clauses that support function calling.

- When executing a query containing a `WHERE` clause filtering records by a field that the querying user does not have access to `SELECT` (e.g. `SELECT public FROM data WHERE private ~ "secret"`), the response of that query would still take the value of the field into account. Even though the value of the protected field would not be returned, this behavior could be used as a side channel by the querying user to infer information about the value of the field.

- When performing `UPDATE` or `DELETE` operations over a table with a user that had those permissions but no `SELECT` permission, the `RETURN BEFORE` clause could be used (e.g. `DELETE data RETURN BEFORE`) to read the contents of the records prior to the authorized update or the deletion despite the querying user not being authorized to perform `SELECT` operations.

- When performing `UPDATE` operations on a table for which the user had `SELECT` and `UPDATE` permissions, the `SET` clause could reference fields that the user had `UPDATE` but no `SELECT` permission for (e.g. `UPDATE data SET public = private`) in order to update the value of a field that the user had permission to `SELECT` to the value of another field for which the user did not.

### Impact

Clients that were authorized by table permissions to execute `SELECT` statements for a table but were not authorized by field permissions to run `SELE