GoogleやRapid7のMCP関連ソフトウェアで、AIエージェントから受け取った値の検証不足による脆弱性が修正されました。問題となったのは、内部サービスへの不正な通信や、意図しないデータ問い合わせにつながる入力の扱いです。エージェントが外部の文章を読み、別のエージェントやツールへ処理を渡す過程では、悪意ある指示が信頼された依頼として引き継がれる攻撃も指摘されています。

MCPはツールへの接続、A2Aはエージェントへの仕事の委任

MCP（Model Context Protocol）は、AIアプリケーションやエージェントを外部のツール、データ、指示テンプレートに接続するためのプロトコルです。これに対し、A2A（Agent2Agent）は、あるエージェントが別のエージェントへ仕事を委任し、進捗や結果を受け取るためのプロトコルです。

両者を組み合わせる構成では、エージェント間の仕事の受け渡しにA2Aを使い、それぞれのエージェントが必要なツールやデータへアクセスする際にMCPを使います。別のエージェントをMCPサーバー経由で呼び出すこともできますが、その場合、MCP上では相手をツールとして扱います。

独立セキュリティ研究者のSyed Anas Mohiuddin氏は、異なるプロトコルの間にある信頼の前提を悪用し、別のプロトコルでのみ使える機能へ到達する攻撃を「protocol pivoting」と呼んでいます。同氏は、エージェントや上流サービスから届いた値を、システム内部から来たという理由で信頼する実装に、共通の問題があると評価しています。

Googleは通信先を検証、Rapid7は問い合わせの組み立てを修正

Googleの「MCP Toolbox for Databases」は、データベース向けのMCPツール群です。HTTP通信の初期化時に転送先を制御する設定がなく、接続先のIPアドレスも検証していなかったため、細工したパスの値によって内部の接続先へ通信を転送させられる状態でした。これはSSRFと呼ばれる、サーバーに本来認められていない宛先へのリクエストを送らせる脆弱性です。

Mohiuddin氏によると、Googleはこの問題にCVE-2026-14540を割り当て、深刻度を示すCVSSスコアを8.0としました。修正では、接続時に名前解決後のIPアドレスを検証し、IPアドレス範囲の許可リストと拒否リストを適用しています。危険なベースURLは、最初のリクエスト時ではなく起動時に拒否する仕組みになりました。

Rapid7の「Bulk Export MCP」で修正されたCVE-2026-97228は、SSRFとは異なる問題です。バージョン0.2.5から0.6.1では、エクスポートの状態を取得する処理が、未検証の識別子をAPIの問い合わせ言語であるGraphQLの文字列へ直接埋め込んでいました。引用符や波括弧を含む識別子を渡すと、意図した問い合わせに別の問い合わせを追加できました。

Rapid7は、この問い合わせが実行者の既存のAPIキーと認証済みの権限範囲内で動作し、別のテナントやアカウントの境界を越えるものではないと説明しています。想定される影響は、侵害された上流のMCPクライアントや、間接プロンプトインジェクションによって未検証の識別子が転送される場合に限られ、CVSSスコアは2.7です。修正版の0.6.2では、識別子を問い合わせ文字列に直接埋め込まず、GraphQLの変数として渡す方式に変更しました。

悪意ある指示は委任先や共有ツールにも伝わる

間接プロンプトインジェクションは、外部の文書やツールの応答に埋め込まれた指示によって、AIの処理を攻撃者の望む方向へ誘導する攻撃です。Rapid7のDouglas McKee氏は、エージェントが読み込んだ文章を通常の委任として別のエージェントへ渡し、受け手が依頼元を信頼して実行する経路を説明しています。

「protocol pivoting」という呼び方には、研究者の間で見方の違いもあります。X41 D-SecのMarkus Vervier氏は、これを間接プロンプトインジェクションの一種と捉え、悪意ある指示が異なるプロトコルを経由することは、攻撃が成立するための必須条件ではないと述べています。

共有ツールを経由する伝播も研究対象になっています。MCPを使う複数エージェントの連携を扱った研究では、エージェント同士が直接通信しなくても、共有データベースなどを介して悪意ある指示が別のエージェントへ届く経路をモデル化しました。研究では、外部サイトによって操作されたエージェントが共有データベースへ指示を混入させ、別のエージェントがそれを読み込む例を示しています。

この研究の実験では、モデル化した条件下で共有ツールとの結び付きが伝播を増幅し、ツール側の制御がエージェント側の強化より有効になる場合がありました。実装上の脆弱性を調べたMohiuddin氏の事例とは検証方法が異なりますが、エージェント間の直接の通信に加え、共有するツールやデータも攻撃経路になる点で関連しています。

認可されたアクセスでも入力の安全性は別に扱う

MCPの認可では、クライアントが提示するアクセストークンが、そのMCPサーバー向けに発行されたものかを検証します。検証対象には発行者、有効期限、利用できる操作の範囲などがあり、個々のツールでも、検証済みの利用者が対象のテナントやデータへアクセスできるかを判断する必要があります。

この認可と、ツールの応答に混ざった指示の扱いは別の制御です。ツールが返す文章は別の操作へモデルを誘導し得るため、アクセス権は文書の内容ではなく、検証された利用者の身元とポリシーによって決まります。MCPサーバーが下流のAPIを代理で利用する構成では、権限を持つプログラムが依頼者に誘導され、その権限を不適切に使う「confused deputy」という問題も生じます。

Mohiuddin氏は、米連邦政府向けのMCPサーバーについてもセキュリティ上の問題を報告していますが、それらは調査中として扱い、確認・修正済みの結果には含めていません。