SurrealDB CVE-2026-109334

Requires the attacker to already possess valid namespace-level or database-level SYSTEM user credentials on the target SurrealDB instance (PR:L) running a version before 3.3.0. The attacker then sets the Surreal-NS and/or Surreal-DB headers on the /sql endpoint or calls the RPC 'use' method to select a namespace/database other than the one they authenticated against. Exploitation is further limited by the target tenant's table PERMISSIONS clauses - cross-tenant read/create/modify/delete and DEFINE PARAM reads only succeed where those PERMISSIONS allow the operation. Practically, this is only impactful on shared multi-tenant deployments; a single-tenant instance has no other tenant to cross into.

This is a genuine authorization/multi-tenancy flaw (CWE-639, Authorization Bypass Through User-Controlled Key) rather than a merely high-scored paper issue. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) indicates a network-reachable, low-complexity attack requiring only low-level authentication - i.e., any legitimate namespace- or database-level SurrealDB user can pivot into other tenants. Impact is high on confidentiality and integrity (VC:H/VI:H) but none on availability (VA:N), consistent with the described read/create/modify/delete-rows capability. No EPSS score, CISA KEV listing, or public POC is present in the provided data, so there is no evidence of active exploitation - the risk is driven by severity and ease-of-exploit for an already-authenticated principal, not by observed in-the-wild activity. The real priority is high specifically for multi-tenant/SaaS deployments of SurrealDB where mutually distrusting tenants share an instance; for single-tenant deployments the practical exposure is much lower. One caveat: exploitation is explicitly gated by target table PERMISSIONS, so the blast radius depends on how permissively each tenant's tables are defined - a limiting factor the raw CVSS score does not capture.

An attacker holds valid namespace- or database-level credentials for one tenant on a shared SurrealDB (before 3.3.0) instance. They send a request to /sql with forged Surreal-NS/Surreal-DB headers (or invoke the RPC 'use' method) pointing at a different tenant, and because the server never verifies the selected namespace/database against the level the user authenticated at, they read and tamper with the other tenant's rows and DEFINE PARAM values wherever table PERMISSIONS allow. No public exploit code is identified at time of analysis, but the technique is trivially scriptable given the low complexity.