Advisoriesby IbisSurrealDB: USE NS/DB implicit creation bypasses DEFINE authorization
An anonymous caller could create new namespaces and databases on a running SurrealDB instance without holding DEFINE NAMESPACE or DEFINE DATABASE permission.
USE NS <name> and USE DB <name> 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 DATABASEpermission. 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 <dropped> 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...
Affected versions
| Package | Affected | Fixed in |
|---|---|---|
| surrealdb crates.io | < 3.1.0 | 3.1.0 |
Details and references
An anonymous caller could create new namespaces and databases on a running SurrealDB instance without holding `DEFINE NAMESPACE` or `DEFINE DATABASE` permission. `USE NS <name>` and `USE DB <name>` 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 <dropped> 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.
More SurrealDB advisories
All SurrealDB
SurrealDB: Edge PERMISSIONS FOR delete bypassed when a connected node is deletedCVE-2026-49997fixed in 3.1.0SurrealDB: ES512 silently downgraded to ES384 due to jsonwebtoken crate limitationCVE-2026-63761fixed in 3.1.0SurrealDB: Field-level SELECT permissions bypassed via indexed COUNT fast pathsCVE-2026-63742fixed in 3.1.0SurrealDB: Port-specific --deny-net rules silently bypassed on HTTP redirectCVE-2026-63743fixed in 3.1.0SurrealDB: Authenticated subscribers can read records hidden by SELECT permissions via LIVE subscriptionsCVE-2026-63749fixed in 3.1.0SurrealDB: `RELATE` overwrites existing edge records without `UPDATE` permissionCVE-2026-63752fixed in 3.1.0