GHSA-wp87-mgvq-5j93 SurrealDB: USE NS/DB implicit creation bypasses DEFINE authorization

• crates.io surrealdb: < 3.1.0 → fixed in 3.1.0

An anonymous caller could create new namespaces and databases on a running SurrealDB instance without holding `DEFINE NAMESPACE` or `DEFINE DATABASE` permission. `USE NS ` and `USE DB ` automatically create the target when it does not exist. The three places `USE` is handled — the RPC `use` method, `Datastore::process_use`, and the SurrealQL executor — did not check whether the caller was allowed to create the resource. Under default capabilities any session reached this path, including an unauthenticated guest. Impact What an attacker can do: • Create new namespaces and databases without `DEFINE NAMESPACE` / `DEFINE DATABASE` permission. An unauthenticated guest is enough under default capabilities. • Recreate a parent namespace that an operator deliberately dropped, using a stale namespace-Editor token, by running `USE NS DB anything`. • Exhaust catalog storage by repeatedly creating new resources. What it can't do: • Read or modify data inside any pre-existing namespace or database. • Escalate to root or namespace-owner privileges on existing resources. • Affect deployments running with `auth_enabled=false`. Patches All three `USE` entry points now check whether the caller has `DEFINE NAMESPACE` / `DEFINE DATABASE` authority before creating a missing target. Sessions still update their context regardless of authorization, so SDKs that send `use` before `signin` continue to work — only the catalog creation step is gated. The parent-namespace side-effect path is closed by the same check. Versions 3.1.0 and later are not affected. Workarounds • Set `--deny-arbitrary-query *` for guest principals to remove the entry point. • Run with `--auth` and require all callers to `signin` before issuing `use`. • Revoke namespace-level tokens promptly when a namespace is dropped.