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

> Unauthenticated attackers can create new namespaces and databases in SurrealDB, bypassing authorization checks and potentially exhausting storage resources.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 1 Jul 2026

## What is GHSA-wp87-mgvq-5j93?

GHSA-wp87-mgvq-5j93 is a missing authorization vulnerability in surrealdb, published on 1 Jul 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.

### Official description

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.

## Which versions are affected by GHSA-wp87-mgvq-5j93?

2 open source packages ship an affected version, including surrealdb.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `surrealdb` | crates.io | All versions | 3.1.0 |
| `surrealdb` | crates.io | All versions | 3.1.0 |

## How do I fix GHSA-wp87-mgvq-5j93?

Upgrade surrealdb to 3.1.0 or later.

## Is GHSA-wp87-mgvq-5j93 being exploited?

There is no known exploitation of GHSA-wp87-mgvq-5j93 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-wp87-mgvq-5j93 and fix it if it is affected.

What it is: GHSA-wp87-mgvq-5j93 is a missing authorization vulnerability in surrealdb, published on 1 Jul 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.
Exploitation: There is no known exploitation of GHSA-wp87-mgvq-5j93 in the wild and no public exploit code.

Affected packages and fixed versions:
- surrealdb (crates.io): affected all versions; fixed in 3.1.0
- surrealdb (crates.io): affected all versions; fixed in 3.1.0

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/GHSA-wp87-mgvq-5j93/ (Markdown: https://insights.sbomify.com/GHSA-wp87-mgvq-5j93/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-wp87-mgvq-5j93

---
From sbomify Insights: https://insights.sbomify.com/GHSA-wp87-mgvq-5j93/
Summaries are generated and may contain mistakes; the official description above is the record.