SurrealDB versions before 2.0.4 fail to properly enforce field permissions during SELECT, UPDATE, and DELETE operations, allowing authorized users to access unauthorized field values through various query techniques. Attackers can exploit SELECT VALUE operations, field aliasing, function arguments, WHERE clause filtering, RETURN BEFORE clauses, and SET clause references to leak protected field contents despite lacking SELECT permissions.

Affected: crates.io: surrealdb, crates.io: surrealdb-core

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…