Executive brief
SurrealDB is a multi-model database engine commonly used in backend-as-a-service deployments. A flaw in how the database enforces field-level and table-level permissions allows authenticated users with limited access (e.g., SELECT on a table but not on specific fields) to read restricted field values through various query techniques including aliasing, function calls, filtering, and UPDATE/DELETE operations. This affects deployments relying on SurrealDB's permission system to protect sensitive data from application users.
Technical details
The vulnerability stems from improper permission evaluation ordering in SurrealDB's query processing. Affected versions (before 2.0.4) check field-level SELECT permissions after applying query transformations rather than before. This allows six distinct attack patterns: (1) SELECT VALUE operations bypass field filtering for non-iterable values; (2) field aliasing causes permission checks to apply to the aliased name instead of the original field; (3) functions passed protected field values receive them before permission filtering; (4) WHERE clauses on restricted fields leak information via side-channel filtering; (5) DELETE/UPDATE with RETURN BEFORE bypasses SELECT permission requirements; (6) UPDATE SET clauses can reference fields with UPDATE but not SELECT permission. The root cause is that permissions were evaluated on modified documents rather than original ones. The vulnerability requires the attacker to already be authenticated with some query privileges on the affected table or field. Version 2.0.4 and later fix this by evaluating permissions before document modifications occur.
Affected products
- SurrealDB surrealdb < 2.0.4
- SurrealDB surrealdb-core < 2.0.4
Timeline
- 2024-10-08: disclosed
- 2024-10-08: patched: Version 2.0.4 released with fixes