何が起きたか
2026年10月2日（期間内）に公開されたWorkOS分析は、MCPエコシステムの3つの認証欠陥を詳細に説明しており、すべて1つの根本原因（未検証の認証入力を信頼すること）に由来する。これには、公式MCP Python SDKにおけるこのGHSA-qx49-fqc8-xw99問題が含まれる。SDKのOAuthクライアントはissuerを一貫して検証せず、資格情報を発行サーバーにバインドしなかった；1.30.0／2.2.0で修正され、CVEは割り当てられていない。関連するrmcp（Rust SDK）の欠陥CVE-2026-63127（CVSS 8.2、2.0.0で修正）およびLiteLLMヘッダー信頼の欠陥CVE-2026-59822（CVSS 8.8、1.84.0で修正、KEV 9月2日）が同じパターンを構成する。
なぜ重要か
MCPエコシステムは標準的なエージェントツール接続メカニズムである；クライアント側のOAuth欠陥は、エージェントを単一の悪意のあるMCPサーバーに接続するだけでアプリケーションのOAuthクライアント資格情報が漏洩し、攻撃者が正当なリソースのトークンを取得できることを意味する。無人で機械間エージェント接続を実行するAIデプロイメントにとって、これはユーザーが気付くことのない、エージェントから資格情報窃取への直接経路である。
攻撃経路
悪意のあるMCPサーバーがクライアントにログイン場所を指示し、SDKは使用されたアドレスに対してissuer（RFC 8414）を一貫して検証せず、クライアント登録／シークレットを発行したサーバーにバインドしない — そのため404（レガシーフォールバック）または403 insufficient_scopeをトリガーすると、SDKはクライアントシークレット、認可コード、PKCEベリファイアを攻撃者制御のトークンエンドポイントに送信する；攻撃者はその後、スコープ内の正当なリソースに対するトークンを保持する
影響を受けるシステム
MCP Python SDK mcp 1.9.1から1.29.1および2.0.0から2.1.1（公式Model Context ProtocolリファレンスSDK）
緩和策
mcp 1.30.0または2.2.0以降にアップグレード；ClientCredentialsOAuthProviderおよびPrivateKeyJWTOAuthProviderにissuer=を明示的に渡す（3.0では必須）；1.30.0より前に保存された登録をクリアし、期待されるissuerに対して再登録；脆弱なクライアントが信頼できないサーバーに接続したことがある場合はシークレットをローテーションする