SurrealDB EUVD-2026-97645

Requires a valid authenticated SurrealDB account at the namespace, database, or record level (PR:L) and a SurrealDB instance running a version before 3.3.0. Exploitation is only impactful where multiple tenants (namespaces/databases) share the same instance and where target tables carry permissive PERMISSIONS such as PERMISSIONS FULL that grant the operation to the switched session. Limiting factors: no unauthenticated access is possible, impact is bounded by each target table's PERMISSIONS clause (tables with restrictive permissions are not exposed), and single-tenant deployments have no cross-tenant victim to reach.

This is an authorization-bypass flaw (CWE-639) with a vendor/VulnCheck CVSS 4.0 score of 8.6 (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N). The signals are internally consistent: network attack vector, low complexity, and - critically - PR:L, meaning the attacker must already hold a valid authenticated SurrealDB account (namespace, database, or record user). It is therefore a post-authentication privilege/tenant-boundary escape, not a pre-auth remote compromise, which meaningfully lowers real-world urgency relative to the raw 8.6. No EPSS score, CISA KEV listing, or public POC was provided in the intelligence, so there is no public exploit identified at time of analysis and no evidence of active exploitation; the risk is currently theoretical/based on the advisory. The most serious real-world exposure is for multi-tenant SaaS deployments of SurrealDB where a single shared instance hosts multiple customers' namespaces/databases and where tables carry permissive PERMISSIONS (e.g. PERMISSIONS FULL) - in that configuration any one authenticated tenant can read and tamper with other tenants' data. Note the provided CVSS sets subsequent-system impact (SC/SI/SA) to N, i.e. it treats cross-tenant access as same-system impact rather than a scope change; given that tenant isolation is a security-authority boundary, the integrity/confidentiality impact across tenants is arguably understated, but the metric choice is defensible since all data lives within one database system.

An attacker who holds any legitimate low-privilege SurrealDB account on a shared multi-tenant instance (for example a customer-level namespace or database user, or a record user) connects over the network and issues a SurrealQL USE statement naming a different tenant's namespace/database. Because SurrealDB before 3.3.0 does not verify that the caller's authenticated level actually covers the target, the session switches tenants, and the attacker then reads, creates, updates, or deletes rows in any tables whose PERMISSIONS permit it (such as PERMISSIONS FULL). No public exploit is identified, but the attack requires only standard query access and no special tooling.