MCP公式Python SDKに認証情報窃取の脆弱性、修正版への更新と設定変更が呼びかけ

要点

• AIツール連携規格「Model Context Protocol（MCP）」の公式Python SDKに、接続先サーバーがOAuth認証情報を窃取できる脆弱性が判明した。

• 認可サーバーの応答検証不備により、クライアントシークレットや認可コード、PKCE証明キーが攻撃者側のエンドポイントへ送信される恐れがある。

• セキュリティ企業Cycodeがアカウント乗っ取りの実証に成功しており、修正版としてバージョン1.30.0および2.2.0が公開された。

• マシン間通信を行う一部のプロバイダでは、SDKの更新に加えて「issuer=」引数の明示的な設定が必要となる。

• AIアプリケーションと外部ツールを接続するオープン標準「Model Context Protocol（MCP）」の公式Python SDKに、悪意あるサーバーへOAuth認証情報が漏洩する脆弱性が存在することが明らかになった。本SDKの開発チームは2026年9月28日にセキュリティアドバイザリを公開し、修正版へのアップデートと適切な設定の実施を案内している。本脆弱性を報告したセキュリティ企業Cycodeの検証により、悪意あるサーバーがクライアントの権限を持つアクセストークンを不正に取得できることが実証された。

脆弱性の仕組みと情報漏洩のリスク

MCP（AIモデルと外部のツールやデータを接続するためのオープン標準規格）の公式Python SDKでは、HTTP経由で接続を行うクライアントが認証を必要とする際、接続先サーバーへ認証窓口となる認可サーバーの所在を問い合わせる仕様になっている。

しかし、影響を受けるバージョンではサーバーからの応答が十分に検証されていなかった。そのため、悪意のあるMCPサーバーは攻撃者が管理するログインサービスを指定したり、正規のサービス名を装いつつ認証情報の送信先を別のエンドポイントへ向けさせたりすることが可能になっていた。

これにより、クライアントは正規の認証情報であるクライアントシークレットや認可コードに加え、PKCE（認可コードの不正再利用を防ぐための一時的な証明キー）までも攻撃者側のサーバーへ送信してしまう。PKCEによる保護も同時に無効化されるため、攻撃者は奪った情報を用いて正規のログインサービスへ有効なアクセストークンを要求できるようになる。

検証を行ったCycodeによると、発行されるアクセストークンにはクライアントアプリに許可されていたすべての権限が含まれるという。また、クライアントシークレットは長期間有効であるため、再発行などが行われない限り攻撃者がアクセス権を維持し続ける危険性がある。

深刻度を示すスコアは、人間の操作を介さずに動作する2種類のマシン間プロバイダで「7.5（High）」、ユーザー自身がサインインを承認する対話型プロバイダで「6.5」と評価されている。対話型の場合でも、承認時に表示されるログイン画面自体は正規のものであるため、利用者が不審点に気づくのは困難だと説明されている。なお、2026年9月29日時点でCVE番号は割り当てられていない。

影響を受けるバージョンと対象環境

本脆弱性の対象となるのは、公式Python SDKをHTTP経由のMCPクライアントとして使用し、特定のOAuthプロバイダ（OAuthClientProvider、ClientCredentialsOAuthProvider、PrivateKeyJWTOAuthProvider、または非推奨の1.x RFC7523OAuthClientProvider）を利用している環境である。自身が完全に管理していない外部サーバーへ接続可能で、かつ正規サービスの認証情報を保持している場合に悪用のリスクが生じる。

一方で、本SDKを用いて構築されたMCPサーバー側の実装や、標準入出力（stdio）で通信を行うローカルクライアント、自身であらかじめトークンを付与して送信するクライアントなどは本脆弱性の影響を受けない。

影響を受けるバージョンと修正版は以下のとおりである。

• 1.x系：バージョン1.9.1 〜 1.29.1（バージョン1.30.0で修正）
• 2.x系：バージョン2.0.0 〜 2.1.1（バージョン2.2.0で修正）

修正版への更新と必須となる追加設定

開発チームは、1.x系を利用している場合はバージョン1.30.0へ、2.x系を利用している場合はバージョン2.2.0への速やかなアップデートを推奨している。修正版では、クライアントが詳細情報を取得する前に想定されるログインサービスを特定し、異なるサービスが指定された場合には処理を拒否する検証ロジックが追加された。

ただし、一部のプロバイダではSDKを更新するだけでは脆弱性を解消できない点に注意が必要である。アドバイザリによると、「ClientCredentialsOAuthProvider」または「PrivateKeyJWTOAuthProvider」を使用している場合、コード上で認証情報が属するログインサービス名を指定する「issuer=」引数を明示的に渡す必要がある。この引数を設定しない限り、修正版を導入していてもサーバー側から指示された任意の認可サーバーへ接続してしまう動作が続くという。

なお、バージョン1.30.0ではこの仕様変更に関する警告がPythonの標準的な非推奨警告（DeprecationWarning）として出力されるため、デフォルト設定では非表示となり見落とされやすいと指摘されている。また、すでに非推奨となっている「RFC7523OAuthClientProvider」には「issuer=」オプションが存在しないため、他のプロバイダへの移行が求められている。

さらに、過去に保存されたOAuthクライアントの登録情報はログインサービスに紐付いていないため、更新後に一度クリアする必要がある。信頼できないサーバーへ接続した可能性がある場合は、ログインサービス側でクライアントシークレットの再発行（ローテーション）と発行済みトークンの失効を行うことが案内されている。旧バージョンにおける一時的な回避策としては、自身が信頼できるMCPサーバーにのみ接続を限定する方法以外に存在しない。

修正および情報開示の経緯

本脆弱性への対策となる発行元検証の処理は、2026年9月7日にリリースされたバージョン1.30.0および2.2.0のリリースノートに含まれていたが、当時のリリースノートではセキュリティ修正ではなく「動作の変更（behavior changes）」として記載されていた。

その後、2026年9月28日に公式セキュリティアドバイザリが公開され、同日にCycodeによる調査レポートも発表された。アドバイザリでは、Cycodeの研究者を含む計8名の報告者に対して謝辞が示されている。