SurrealDB CVE-2026-109333

Exploitation requires: (1) a valid authenticated SurrealDB record-user session (PR:L - not anonymous); (2) a multi-tenant deployment with more than one namespace/database on the shared instance; (3) knowledge of a valid record id in the targeted foreign namespace/database; (4) the attacker switching to that foreign namespace/database and using a RETURN … FETCH query to resolve the record id; and (5) the target table's PERMISSIONS being configured to allow reads for the resolving context. Limiting factors that reduce realistic risk: the attacker must already be authenticated, must know or guess a specific record id, and the data is only exposed where table PERMISSIONS permit reads - single-tenant or strictly permissioned deployments are not affected. Impact is limited to data disclosure; no write/modify or availability effect.

The vendor CVSS 4.0 score of 7.1 (High) is driven by a network vector (AV:N), low attack complexity (AC:L), no attack requirements (AT:N), no user interaction (UI:N), and high confidentiality impact (VC:H) with no integrity or availability impact (VI:N/VA:N) and no subsequent-system/scope impact (SC:N). Critically, PR:L confirms this is NOT unauthenticated - the attacker must already hold a valid SurrealDB record-user credential, which meaningfully lowers real-world risk versus a pre-auth flaw. No EPSS score was provided, the CVE is not listed in CISA KEV, and no public proof-of-concept is referenced, so exploitation is currently theoretical/disclosure-stage rather than demonstrated. The impact is read-only cross-tenant data disclosure (classic CWE-862 Missing Authorization), not code execution or data tampering. Net assessment: a genuine multi-tenancy isolation flaw that matters for SurrealDB Cloud / shared-instance operators, but the authentication requirement, the need to know a valid target record id, and the dependency on permissive table PERMISSIONS make it a targeted-abuse issue rather than a mass-exploitation emergency. Note the input tag 'Authentication Bypass' conflicts with the description and CWE-862, which describe an AUTHORIZATION bypass - verify tagging.

A legitimately authenticated SurrealDB record user on a shared multi-tenant instance switches their session to another tenant's namespace/database and issues a RETURN … FETCH query naming a record id they know or can guess, causing the engine to resolve and return records belonging to that foreign tenant where table PERMISSIONS permit reads. No public exploit code is identified at time of analysis, so this requires the attacker to craft the query manually, but the low attack complexity means the technique is straightforward once a record id is known.