Advisory · CVE-2026-121419
SurrealDB MCP session hijack via BoundSubject fingerprint collision
SurrealDB 3.1.0 through before 3.3.0 lets any authenticated user of a JWT or Bearer access method hijack another users MCP session by presenting their own valid low-privilege token together with the victims session id, because the session fingerprint uses the access method name instead of a per-user identity.
- Vendor
- SurrealDB
- Product
- SurrealDB
- Identifier / CWE
- CVE-2026-121419
CWE-269 - Action timing
- Immediate
Explain it like I’m five
SurrealDB checks that the name on a session badge matches the person holding it, but for these login methods everyones badge just says the name of the login method itself. A low-privilege user can therefore borrow a victims session badge and be treated as the victim.
- 01Victim session opened
A victim user initializes an MCP session over HTTP and receives a session id.
- 02Attacker token obtained
An attacker holds their own valid token for the same JWT or Bearer access method, even with the lowest role.
- 03Session id reused
The attacker sends a tools call carrying their own token plus the victims session id, obtained for example from HTTP logs, a proxy, or shared observability data.
- 04Fingerprint collides
The per-request subject check compares fingerprints built from the access method name, which is identical for both users, so the check passes.
- 05Victim session executed
The MCP tools run on the victims bound session with the victims roles and permissions, and the activity is attributed to the victims session identity.
What happened
SurrealDB versions 3.1.0 through before 3.3.0 contain an improper authentication vulnerability in the MCP HTTP transport. The per-request subject re-check is meant to ensure that possession of a session id alone cannot let a different credential impersonate the original user, but for JWT and Bearer access methods the BoundSubject fingerprint is built from the access method name rather than a per-user identity. Any authenticated user of the same access method, even with the lowest role, who also holds a victims session id therefore passes the re-check with their own valid token and executes MCP tools on the victims bound session. The vendor advisory reproduces the issue end to end on the official 3.2.0 release, with a viewer-role user writing a record that its own permissions forbid. The record rates it high at CVSS 8.6 under version 4.0.
Users authenticated through the username and password path are not affected, because that path puts a per-user name into the actor identity. The exposure is limited to deployments that expose MCP over HTTP and serve more than one user through the same JWT or Bearer access method. SurrealDB 3.3.0 is outside the affected range stated in the NVD record, and the vendor advisory suggests building the actor identity from the tokens per-user identity claim so users of the same method get distinct fingerprints.
What to do
- Inventory SurrealDB deployments exposing MCP over HTTP and identify which use JWT or Bearer access methods serving more than one user.
- Upgrade to SurrealDB 3.3.0 or later, which is outside the affected range stated in the NVD record.
- Until upgraded, restrict MCP HTTP access to trusted networks and users, and treat session ids as sensitive credentials in logs, proxies, and observability pipelines.
- Review MCP audit logs for tool invocations whose subject identity is only an access method name, and for sessions used with more than one distinct token role.
- Rotate credentials and review data accessed through any MCP session where hijacking cannot be excluded.
- Verify the deployed version after updating.
Management note
A session binding check is only as good as the identity it binds. When every user of a login method shares one fingerprint, the check becomes a formality and the session id becomes the only credential that matters. Treat session id handling with the same care as token handling until the upgrade lands.