CVE-2026-63741

SurrealDB versions before 3.1.0 fail to validate DEFINE NAMESPACE or DEFINE DATABASE permissions when processing USE NS and USE DB statements. Unauthenticated attackers can create arbitrary namespaces and databases by issuing USE commands, bypassing authorization checks in the RPC use method and SurrealQL executor.

SurrealDB versions before 3.1.0 fail to validate DEFINE NAMESPACE or DEFINE DATABASE permissions when processing USE NS and USE DB statements. Unauthenticated attackers can create arbitrary namespaces and databases by issuing USE commands, bypassing authorization checks in the RPC use method and SurrealQL executor.

SurrealDB versions before 3.1.0 fail to validate DEFINE NAMESPACE or DEFINE DATABASE permissions when processing USE NS and USE DB statements. Unauthenticated attackers can create arbitrary namespaces and databases by issuing USE commands, bypassing authorization checks in the RPC use method and SurrealQL executor.

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.

SurrealDB versions before 3.1.0 fail to validate DEFINE NAMESPACE or DEFINE DATABASE permissions when processing USE NS and USE DB statements. Unauthenticated attackers can create arbitrary namespaces and databases by issuing USE commands, bypassing authorization checks in the RPC use method and SurrealQL executor.

SurrealDB versions before 3.1.0 fail to validate DEFINE NAMESPACE or DEFINE DATABASE permissions when processing USE NS and USE DB statements. Unauthenticated attackers can create arbitrary namespaces and databases by issuing USE commands, bypassing authorization checks in the RPC use method and SurrealQL executor.

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.