Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#6,779 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@suantea がすでに取り組んでいます。

2026年10月10日 から。

  • #6788 @suantea による — マージされずにクローズ

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
22/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
go, kubernetes
領域
authorization, security

調査の方向性

Start in pkg/vmcp/session/internal/security/security.go, where sessionBindingDecorator overrides only CallTool, ReadResource and GetPrompt and delegates the list methods to the embedded MultiSession. Done means tools/list, resources/list, resources/templates/list and prompts/list reject a foreign caller with the same error as tools/call. Linked PR #6788 is already open, so check it first and coordinate before starting.

索引モデルが issue の本文から書いたものです。

説明

needs-triage
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.

主要言語
Go
スター
2.3k
フォーク
318
平均マージ
2日 1時間
マージ済み PR（30日）
84

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

stacklok/toolhive のほかの issue

stacklok/toolhive の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。