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.
References
An anonymous caller could create new namespaces and databases on a running SurrealDB instance without holding
DEFINE NAMESPACEorDEFINE DATABASEpermission.USE NS <name>andUSE DB <name>automatically create the target when it does not exist. The three placesUSEis handled — the RPCusemethod,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:
DEFINE NAMESPACE/DEFINE DATABASEpermission. An unauthenticated guest is enough under default capabilities.USE NS <dropped> DB anything.What it can't do:
auth_enabled=false.Patches
All three
USEentry points now check whether the caller hasDEFINE NAMESPACE/DEFINE DATABASEauthority before creating a missing target. Sessions still update their context regardless of authorization, so SDKs that sendusebeforesignincontinue 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
--deny-arbitrary-query *for guest principals to remove the entry point.--authand require all callers tosigninbefore issuinguse.References