SurrealDB: USE NS/DB implicit creation bypasses DEFINE authorization

Overview

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.

Affected packages

• surrealdb < 3.1.0

Remediation

Upgrade to a patched release:

• surrealdb 3.1.0