vMCP: session identity binding is not enforced for tools/list (and other list methods) #6779

Summary

vMCP binds each MCP session to the identity that created it and rejects calls from a different identity (identity binding mismatch → caller identity does not match session owner → session terminated). This works as intended for tools/call.

However, tools/list on a foreign session is answered with HTTP 200 and the session owner's tool list. A caller with a valid token of a different user can therefore enumerate the tools (and thereby the backends/permissions) of another user's session, provided they know its Mcp-Session-Id.

Environment

• ToolHive operator / vMCP v0.51.4 (Kubernetes, VirtualMCPServer)
• Embedded auth server with upstream providers (Keycloak as primary, a second OAuth provider via upstreamInject), Redis session storage, 2 vMCP replicas
• Cedar authorization (MCPAuthzConfig) with per-group tool policies: user A is allowed 16 tools, user B 13 tools

Steps to reproduce

1. User A logs in (OAuth via the embedded auth server), sends initialize, receives Mcp-Session-Id: S.
2. User B logs in separately and obtains their own valid access token.
3. User B sends tools/list with their own Authorization: Bearer <token B> and Mcp-Session-Id: S.
4. User B sends tools/call (any allowed read-only tool) with the same headers.

Observed

• Step 3: HTTP 200, 16 tools – the list of user A, including tools from backends user B is not authorized for (B's own session lists 13).
• Step 4: rejected. Log:

  WARN identity binding validation failed: identity binding mismatch  reason=identity_binding_mismatch
  WARN caller authorization failed, terminating session  capability=<tool> error="caller identity does not match session owner"
  INFO Manager.Terminate: session terminated
  

• Afterwards user A's session is terminated (A gets 0 tools / errors and must re-initialize).

Expected

tools/list (and presumably resources/list, resources/templates/list, prompts/list) should validate the caller against the session binding just like tools/call, and reject a foreign caller before returning any session-scoped data.

Analysis

pkg/vmcp/session/internal/security/security.go: sessionBindingDecorator only overrides CallTool, ReadResource and GetPrompt; all other methods are delegated to the embedded MultiSession without validation (documented in the type comment). The list handlers therefore return the owner's session-scoped capabilities (which, with Cedar, are already filtered per user) to any authenticated caller.

Impact

Low to moderate: requires a valid token and the victim's session ID (random UUID, only transmitted in headers). No tool results or identity data are leaked; only tool names / descriptions / schemas of the owner's session. With per-user authorization this reveals which backends and tools another user may use.

Related observation (by design, mentioned for completeness): a foreign tools/call terminates the owner's session (terminateOnBindingFailure, hijack prevention). Combined with the missing check on list methods, it might be worth rejecting foreign callers consistently at the session lookup for all methods, so that the behaviour is the same regardless of the method used. Whether termination of the owner's session is the desired trade-off (vs. just rejecting the foreign request) could be reconsidered.

Possible fix

Validate the caller binding for the list methods as well (e.g. in the decorator or centrally when resolving the session for any request), returning the same error as for tools/call.