SurrealDB versions before 3.2.0 contain a permissions bypass vulnerability where data-modifying statements within PERMISSIONS clauses execute with enforcement disabled. Attackers with permission to perform a guarded operation can write to tables they lack permission for by embedding CREATE, UPDATE, DELETE, or UPSERT statements in the PERMISSIONS clause, causing unintended writes and data corruption.

Affected: crates.io: surrealdb-core

A `PERMISSIONS ... WHERE` clause is evaluated with permission enforcement disabled, so it can't recurse into its own checks. But the clause could also contain data-modifying statements, and these ran with enforcement still off — so evaluating a permission check could write to tables the caller cannot write.

For example:

```surql DEFINE TABLE post PERMISSIONS FOR update WHERE (CREATE log SET at = time::now()) OR true; ```

Any user allowed to update a `post` now also creates a `log` record, even with no permission on `log`. The clause is evaluated once per matched record, so one statement can cause several writes.

### Impact

Only databases with a `PERMISSIONS` clause that contains a write are affected; `FULL`, `NONE`, and read-only clauses are not.

What an attacker **can** do:

- With permission to perform the guarded operation (a low-privileged or record user is enough), write to tables in their own database that their permissions would otherwise forbid, by triggering an operation the clause guards. - Cause several writes from a single statement — the clause is evaluated once per matched record. - Trigger unintended events, cascades, or data corruption on those tables.

What it **can't** do:

- Escape the caller's own namespace and database — a permission clause cannot switch namespace or database. - Perform root- or namespace-level actions such as creating users; the caller's role still applies. - Read hidden data — this is an integrity issue, not disclosure.

###…