SurrealDB EUVD-2026-115951

Exploitation requires a specific deployment: SurrealDB with the MCP HTTP transport enabled and reachable (POST /mcp, built with the mcp/http features) AND a database-, namespace-, or root-level DEFINE ACCESS method of TYPE JWT or BEARER that serves more than one user. The attacker must hold (1) a valid token for that same access method - even the lowest role suffices - and (2) the victim's mcp-session-id (the very leak this defense was meant to neutralize, e.g. from HTTP logs, proxies, or shared observability). Limiting factors: deployments that authenticate MCP users via the user/password signin path are NOT affected because that path sets a per-user actor id; single-user access methods have no other victim to impersonate; and the stdio MCP transport is exempt (only the strict 'http' transport label triggers the networked subject check). The attacker cannot escalate beyond the roles/permissions the victim's session already holds.

This is a credible, above-average priority rather than a high-CVSS paper tiger, but its blast radius is narrowed by specific preconditions. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H, score 8.6) describes a network-reachable flaw of low complexity requiring low privileges and no user interaction, with high confidentiality and integrity impact and no availability impact - consistent with a cross-user authorization bypass that lets an attacker read and modify data. PR:L is accurate: the attacker must already hold a valid (even lowest-role) token for the same access method, so this is an authenticated privilege-escalation/lateral-movement issue, not anonymous RCE. The vuln'. today decision label is 'this_week' (not act_now/emergency), aligning with a serious-but-not-fire-drill posture. A full, self-contained reproduction script is published in the GHSA advisory and was confirmed end-to-end (7/7 checks) against the released v3.2.0 binary and the v3.3.0-nightly master build, so working exploit code is public. No EPSS score and no CISA KEV status were provided in the input; absence of KEV means there is no evidence of active exploitation, and the missing EPSS means probability-of-exploitation cannot be quantified here. The real limiter on risk is configuration specificity: only deployments exposing MCP over HTTP with a multi-user JWT/Bearer access method are affected, which is a narrow slice of all SurrealDB installs. Note a version-range discrepancy to verify: the CVE/package metadata says >= 3.1.0 < 3.3.0, while the GHSA advisory states the MCP HTTP transport is affected from >= 3.2.0 (MCP HTTP being a v3.x feature) - reconcile with the vendor before scoping.

A SurrealDB instance exposes the MCP HTTP transport (POST /mcp) with a database/namespace/root JWT access method serving multiple users. A low-privilege user (e.g. viewer-role 'bob') who obtains a higher-privilege victim's mcp-session-id - leaked via HTTP logs, a proxy, or shared observability - sends his own valid token together with that session id and executes MCP tools with the victim's roles, reading or writing records his own permissions forbid. A public, end-to-end-verified PoC reproduction script exists in the GHSA advisory; because AV:N/AC:L and the attacker uses only legitimate credentials, exploitation is straightforward once the session id is known.