GHSA-wp87-mgvq-5j93 is a medium-severity (CVSS 6.5) vulnerability in surrealdb. O3 Security confirms whether GHSA-wp87-mgvq-5j93 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
SurrealDB: USE NS/DB implicit creation bypasses DEFINE authorization
Real-World Exposure
surrealdbReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.
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 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 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
--authand require all callers tosigninbefore issuinguse. - Revoke namespace-level tokens promptly when a namespace is dropped.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🦀crates.io | surrealdb | all versions | 3.1.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for surrealdb. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update surrealdb to 3.1.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-wp87-mgvq-5j93 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-wp87-mgvq-5j93 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-wp87-mgvq-5j93. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-wp87-mgvq-5j93 in your dependencies?
O3 detects GHSA-wp87-mgvq-5j93 across crates.io dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.