- Google、JP Morgan Chase、Rapid7など複数組織のAIエージェントでMCP関連の脆弱性が確認された
- エージェント同士が互いを無条件に信頼する設計が、攻撃の起点になっている
- Rapid7のCVEは深刻度2.7、Googleの脆弱性は8と、評価に大きな幅がある
複数組織で確認された脆弱性
独立研究者のSyed Anas Mohiuddin氏は、Google、JP Morgan Chase、Weviate、Rapid7、フランス政府の省庁間デジタル総局、米国連邦政府が運用するエージェントを検証し、MCPの信頼関係を突く概念実証の攻撃をまとめた。過去5か月の間に、Googleを含む5つの組織が、標的ネットワーク内の1つのエージェントを悪用して他の内部エージェントへ有害な指示を広める脆弱性を認めている。これらの組織に共通する点はAIエージェントを使っていることだけで、業種も規模も異なる。
この手法はLLMそのものではなく、翻訳やデータ分析といった特定用途向けのエージェントを狙う特殊なプロンプトインジェクションだとされる。そうしたエージェントには、そもそもガードレールが存在しないか、あっても緩いことが多く、受け取った指示をそのまま次のエージェントへ渡してしまう。次のエージェントは前段のエージェントを明示的に信頼しているため、その指示に従ってしまうという構図だ。
「プロトコル・ピボット」とは
MCPサーバーは各エージェントの認証情報を保持しており、エージェントは他の内部エージェントを信頼する前提で作られている。そのため、LLM単体であれば拒否されたはずの攻撃が成立してしまう。多くのケースでは、適切なエージェントを狙って巧妙に作られたプロンプトが、SSRF(サーバーサイドリクエストフォージェリ)につながる。SSRFは、Webサーバーに不正なネットワークリクエストを送らせる脆弱性を指す。
Mohiuddin氏はこの攻撃群を「プロトコル・ピボット」と呼んでいる。アプリやサーバーがMCPでエージェントにタスクを割り当て、そのエージェントがGoogleのA2A(Agent-to-Agent)や新興のAgent Network Protocolなど別の通信方式を使って悪意ある指示を別のエージェントへ転送すると成立する。同氏は、認可や信頼が実質的に「翻訳の過程で失われる」ことが問題だと説明している。
深刻度2.7と8の事例
Rapid7のネットワークで見つかったCVE-2026-97228の深刻度評価は10段階中2.7にとどまり、同社は先月修正した。一方、Googleの脆弱性は深刻度8と高い。原因は、データベース向けのMCPツールボックス(googleapis/mcp-toolbox)がHTTPクライアントをCheckRedirectポリシー無しで初期化していたことだ。CheckRedirectは、URLがエラーを返した場合や別のURLへリダイレクトした場合の扱いを制御する設定群を指す。GoogleのHTTPクライアントは、接続先IPアドレスの検証も行っていなかった。
このため、細工したパスパラメータによってツールボックスが内部エンドポイントへリダイレクトし、攻撃者の代理でリクエストを送信できたとMohiuddin氏は説明する。Googleの修正はIPレンジの許可リストとブロックリストの適用で、初回リクエスト時ではなく起動時に安全でないベースURLを拒否する方式だ。同氏はこれを「本物のSSRFガード」と評しつつ、多くのMCPサーバーがそこまでの対策をしていないと指摘している。
呼称をめぐる見解の相違
X41 D-Secの研究者Markus Vervier氏は、より適切な用語は依然として「プロンプトインジェクション」であり、今回の手法はその単純な亜種だと述べている。悪意あるプロンプトが別のプロトコル(A2Aなど)から来て、別のプロトコル上で発現することは、攻撃の成立に厳密には必要ないという立場だ。ただし、一般的に予期しにくく緩和が難しいこと自体は認めている。
5つの組織で同じ手法が成立した点は注目に値する。MCPは新しい技術でありながら、十分な検証と堅牢化を経ないまま広く使われている。記事は、組織がエージェント構成を急いで広げる中で、ネットワーク内のノードも感染し得ると想定するゼロトラストという基本原則が置き去りにされていると指摘する。
現時点の留意点
Rapid7側の脆弱性について、技術的な詳細は原文では明らかにされていない。また、各組織が実際にどこまで影響を受けたか、悪用が確認されたかは示されていない。被害の有無や範囲は現時点では公表されていないとみられる。
Rapid7の脆弱性インテリジェンス担当ディレクターであるDouglas McKee氏は、LLMからツールに渡されるものはすべて、インターネット上の見知らぬ人からの入力として扱うべきだと述べている。根本にあるのはインジェクションやSSRFといった20年前からある問題で、修正方法も変わっていないという。研究者がこの手法に名前を付けたことが、防御側や標準化団体が設計段階で対策を組み込むきっかけになると評価している。
| 項目 | Rapid7 | |
|---|---|---|
| 深刻度評価(10段階) | 2.7 | 8 |
| 修正の内容 | 先月修正済み(詳細は原文に記載なし) | IPレンジの許可リストとブロックリストを適用、起動時に安全でないベースURLを拒否 |
The bugs underneath are old friends like injection and SSRF, and the fixes haven't changed in 20 years.
その土台にあるバグは、インジェクションやSSRFといった昔なじみの問題であり、修正方法は20年間変わっていない。
今後の見通し
MCPはすでに広く導入されているため、今後も同種の脆弱性報告が続くとみられる。Mohiuddin氏が「プロトコル・ピボット」という名称を提唱したことで、防御側や標準化団体が設計段階から対策を組み込む動きが進む可能性がある。一方で、MCPの仕様そのものがどこまで改訂されるのか、A2AやAgent Network Protocolなど新興プロトコルとの間で認可情報や信頼関係をどう引き継ぐのかは、現時点では明らかになっていない。各組織が公表する修正内容の広がりや、関連するCVEの増加傾向が分かれば、対策が実効的に普及しているかを判断できるだろう。
日本の開発者・IT企業にとっての意味
日本企業でも、社内データを扱うAIエージェントをMCPで接続する事例が増えている。今回の指摘は、個々のエージェントのガードレールを強化するだけでは足りず、エージェント間の信頼関係そのものが攻撃面になることを示している。特に、MCPサーバーが各エージェントの認証情報を保持し、エージェントが内部の相手を無条件に信頼する設計は、SSRFや情報漏えいにつながり得る。実務では、エージェント間の委任にも認可を要求する、リダイレクト先や接続先IPを検証する、外部由来のテキストを未信頼の入力として扱うといった対策が求められる。ゼロトラストの考え方をエージェント構成にも適用することが、導入を進める上での前提になりつつある。
気になる点
- 日本企業が使うAIエージェントも同じ影響を受けるのか
- MCPでエージェント同士を接続している構成であれば、同様の信頼関係の隙は生じ得るとみられる。ただし、記事で検証されたのは特定組織の環境であり、国内企業の事例や被害は言及されていない。自社のエージェント連携で、委任先の信頼を前提にしていないかを確認する価値はある。
- MCPを使い続けるには何を対策すればよいか
- 記事ではGoogleの修正例として、IPレンジの許可リストとブロックリストを適用し、起動時に安全でないベースURLを拒否する方式が示されている。加えて、エージェント間の委任にも認可を要求し、リダイレクト先や接続先IPを検証することが有効とみられる。個々のエージェントのガードレール強化だけでは不十分とされる点に注意したい。
- 既存のプロンプトインジェクション対策で防げるのか
- 一部は防げる可能性があるが、不十分との見方が示されている。MCPサーバーが各エージェントの認証情報を保持し、エージェントが内部の相手を無条件に信頼する構造そのものが問題だからだ。Vervier氏は今回の手法をプロンプトインジェクションの亜種と位置づけており、対策の延長線上にあると考えられる。
用語解説
- MCP(Model Context Protocol)
- AIアプリやエージェントが内部ネットワーク上で相互に通信するための標準規格。MCPサーバーが各エージェントの認証情報を保持する。
- プロンプトインジェクション
- AIへの入力に悪意ある指示を混ぜ込み、意図しない動作をさせる攻撃。今回は特定用途のエージェントを狙う点が特徴。
- SSRF(サーバーサイドリクエストフォージェリ)
- Webサーバーに、攻撃者が意図した不正なネットワークリクエストを送らせる脆弱性。内部エンドポイントへの到達に悪用される。
- CVE
- 公開された脆弱性に付与される共通の識別子。記事ではCVE-2026-97228がRapid7の事例として挙げられている。
- ゼロトラスト
- ネットワーク内のノードも感染し得ると想定し、機密性の高い処理の前に都度認可を求める設計原則。
- A2A(Agent-to-Agent)
- Googleが提唱する、エージェント間のタスク委任に用いられるプロトコル。MCPとは別の通信方式として言及されている。
出典
MCP for agent-to-agent comms may be the riskiest protocol you've never heard of
AI導入も顧問も、お任せください
何から手をつけるか、どこまでAIに任せるか。自社の業務に合わせて整理し、導入から運用まで伴走します。相談だけでも構いません。
AI導入について相談する