SurrealDB CVE-2026-109337

Requires an authenticated SurrealDB record user (PR:L) with the ability to register LIVE SELECT queries; it does not require admin or root credentials. Exploitation specifically targets tables protected by field-level SELECT permissions - the attacker abuses WHERE predicates referencing $before or $after and uses notification delivery on CREATE/UPDATE/DELETE as an inference oracle. Limiting factors: the attacker must already have a valid record-user session, the target data must be governed by field-level permissions (otherwise there is nothing hidden to infer), disclosure is incremental rather than bulk (requiring repeated crafted predicates and observed record changes), and only values of restricted fields are exposed - no write, deletion, or service-availability impact. Patched in SurrealDB 3.3.0.

This is a genuine but modest-severity information-disclosure issue, not a top-tier priority. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N) scores 5.3 and the signals are internally consistent: network-reachable but requiring an authenticated record user (PR:L), with only low confidentiality impact (VC:L) and no integrity or availability impact. CWE-203 (observable discrepancy / inference oracle) matches the described mechanism - attackers infer hidden field values by observing whether LIVE SELECT notifications fire, rather than directly reading data. No EPSS score, no CISA KEV listing, and no public POC were provided, so there is no evidence of active exploitation; this reads as a logic/isolation flaw disclosed responsibly via a GHSA advisory and VulnCheck, not an actively weaponized bug. The main caveat is that exploitation is an incremental inference oracle requiring an already-authenticated principal and repeated observation, which limits real-world urgency. Treat as a scheduled-patch item (upgrade to 3.3.0+) rather than an emergency, prioritizing instances where untrusted record users share tables containing field-level-restricted sensitive data.

A low-privileged authenticated record user who is denied field-level SELECT access to a sensitive column (e.g., another user's salary or email) registers LIVE SELECT queries whose WHERE predicates reference $before or $after and test guesses about the hidden value. By watching whether a notification is delivered when records are created, updated, or deleted, the attacker confirms or narrows the restricted value. No public exploit code was identified at time of analysis, but the technique requires only standard query access and the network attack vector (AV:N) makes it reachable by any legitimate record user.