SurrealDB 3.1.0 through versions before 3.3.0 contains an authentication flaw tracked as CVE-2026-121419. The public record describes a collision in the MCP BoundSubject fingerprint: the fingerprint uses the access method name instead of the individual user identity for JWT or Bearer access. The result is described as an MCP session hijack.
That sentence describes a subtle identity-design error. A session-binding value is supposed to answer "which principal is making this request?" If it answers "which authentication method was used?" then two users who authenticate with the same method can collapse into the same bound identity.
Sessions need a principal, not a method
MCP connects a model or agent to tools and data sources. A server may keep a session across multiple requests. The session must be tied to the authenticated principal, the client, and the authorization context. If the binding key is only jwt or bearer, the key distinguishes the mechanism but not the user.
An attacker who can influence or reuse the binding may be able to continue a session under another user's context. The exact exploit path should be read from the vendor advisory and CVE record. The safe design principle is clear: identity binding must use a stable per-user value, not a label shared by every user of the same authentication method.
This is similar to a cache-key mistake. Two different requests produce the same key and the cache returns the wrong object. In an authorization system, the "object" may be a user's session, privileges, or MCP tool context.
Inventory MCP endpoints
Identify every SurrealDB deployment that exposes an MCP integration. Record the version, authentication method, user model, token issuer, token audience, and session storage. Include development and staging instances because an agent test environment may still hold production credentials.
Review how JWTs are validated. The server should check issuer, audience, expiry, signature, and token type. The session binding should include a per-user identifier that cannot be chosen by another user. If a token is anonymous or uses a shared service identity, the authorization model must say so explicitly.
Map the tools that MCP can invoke. A database session may be able to query namespaces, modify records, or invoke functions. A stolen session is more dangerous when the agent has broad write access or can call administrative operations.
Patch and rotate
Upgrade to SurrealDB 3.3.0 or later. Verify the running version and the MCP listener configuration. If a public or shared endpoint is not required, remove it from the network path rather than relying only on user authentication.
Rotate signing keys and sessions created during the exposure window. If the token issuer remains valid, an old token may continue to authenticate until it expires or is revoked. Review namespace and database permissions for the affected users.
Test with two different users who use the same authentication method. Confirm that each session resolves to the correct principal and that one user cannot resume the other's MCP session. Test token replay, an expired token, and a token for the wrong audience.
Monitor the agent boundary
SurrealDB logs should connect MCP sessions to a user, token issuer, and tool call. Alert on a session that changes user context, a tool invocation outside the normal workflow, or a token used from an unusual network location.
Do not put a long-lived administrative token in an agent's configuration. Use a dedicated service identity with narrow access. The MCP server is an authorization boundary between an automated client and the database, not a transparent proxy that should inherit every privilege.
The patch corrects the BoundSubject collision. The operational review should make sure that the next identity label is not another shared string.