SurrealDB CVE-2026-63755

The attacker must hold valid authentication to the target database at any privilege level (CVSS PR:L), including the lowest-trust Record or Scope users, and must be able to submit SELECT or update-variant (UPDATE/UPSERT/INSERT ON DUPLICATE KEY UPDATE/RELATE) statements with an attacker-controlled WHERE, SET, MERGE, CONTENT, or PATCH clause. Direct, high-bandwidth exfiltration additionally requires the server to be started with --allow-scripting / -A; without it, exploitation still works but is limited to lower-bandwidth THROW-based error leakage and timing side channels. Limiting factors: exploitation cannot cross the current database boundary - tables in other databases or namespaces are unreachable - and it requires the ability to run arbitrary queries, so deployments that proxy or template all queries and forbid user-supplied clauses substantially raise the bar.

The supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H) scores 7.1 and is internally consistent with the description: network-reachable, low complexity, requires low-privilege authentication (PR:L), and yields high confidentiality impact with no integrity or availability impact - matching a read-only permission-bypass that discloses arbitrary table data. There is no EPSS score, KEV entry, or public POC in the provided data, so this is a real but not yet mass-exploited priority: exploitation requires valid credentials on the target database, which caps opportunistic internet-wide abuse but makes it highly relevant for any multi-tenant deployment relying on table-level permissions to separate low-trust Record/Scope users. Signals are consistent with no conflicts; the main uncertainty is real-world exploitation likelihood, which cannot be quantified without EPSS. The scripting-enabled (--allow-scripting) path is the most direct, but the vendor confirms THROW-based and timing-based extraction work even in hardened configurations, so disabling scripting alone does not neutralize the risk.

A low-privilege Record or Scope user authenticated to a shared database submits a SELECT (or update-variant) statement whose WHERE clause embeds a side-effecting expression, causing the engine to leak record fields from a table they lack SELECT permission on. With --allow-scripting enabled they exfiltrate rows directly; otherwise they use THROW to surface data in error messages or measure query timing to reconstruct it row by row. No public POC is currently identified, but the advisory describes each primitive in enough detail to reproduce.