CVE-2026-63735

SurrealDB versions prior to 3.2.0 fail to validate the namespace/database named in custom API requests, allowing an authenticated user scoped to one tenant to invoke another tenant's `DEFINE API` endpoint by simply naming the victim scope in the `/api/{namespace}/{database}/{endpoint}` URL path (or via the `surreal-ns`/`surreal-db` headers or `USE` when calling `api::invoke()`). Because the request path overwrote the caller's session scope without checking it against the caller's authenticated level, and custom API handlers run with permissions disabled (definer's rights), the endpoint's own `PERMISSIONS` clause was the only remaining gate. An attacker with valid credentials for any namespace/database — even a `VIEWER` — can read data returned by a cross-tenant endpoint (including from `PERMISSIONS NONE` tables) or trigger its writes and side effects on a `PERMISSIONS FULL` endpoint. Only multi-tenant shared deployments whose callers hold non-root credentials and that define custom APIs are affected; single-tenant deployments, root-scope callers, and unauthenticated access are not impacted. No public proof-of-concept or known exploitation exists (EPSS 0.4%, not in CISA KEV).

What to do: Upgrade to SurrealDB 3.2.0 or later, where the requested namespace/database is validated against the caller's authenticated level and cross-tenant requests are rejected with 403. If patching is not immediately possible, disable the custom API HTTP route via capabilities where it is not required, avoid treating namespace/database boundaries as the tenant isolation boundary on shared instances, and prefer `PERMISSIONS WHERE` clauses keyed on the authenticated identity over `PERMISSIONS FULL`. Administrators of multi-tenant instances should audit defined endpoints for `PERMISSIONS FULL`/`PERMISSIONS NONE` settings and review logs for cross-namespace API invocations.