Model Context Protocol（MCP）の採用が急速に拡大する一方で、そのセキュリティ基盤に深刻な構造的欠陥が次々と明らかになっている。BlueRock Securityが2026年1月に発表した調査では、7,000超のMCPサーバのうち36.7%がSSRF（Server-Side Request Forgery）脆弱性に晒されていることが判明した。Anthropic公式のGit MCPサーバには3件のCVEが付与され、ツールポイズニング攻撃の成功率は主要LLMエージェントで平均60%を超える。本稿では、プロトコル設計レベルの問題から実装上の脆弱性、そしてCoSAI（Coalition for Secure AI）が提示する防御フレームワークまでを体系的に解析する。

MCP普及の裏に潜むセキュリティ負債

MCPは2024年11月にAnthropicが公開したオープンプロトコルであり、LLMエージェントが外部ツール・データソースと標準化された方法で接続するための基盤として設計された。2025年後半にはSDKの週間ダウンロード数が800万を超え、Claude Desktop、Cursor、Windsurf、VS Codeなど主要な開発環境が対応を進めた。

しかし、急速な普及はセキュリティ検証を追い越した。2026年1月に公開された論文「Breaking the Protocol」（arXiv: 2601.17549）は、847の攻撃シナリオを5つのMCPサーバ実装に対して実行し、MCPの設計上の選択が非MCP統合と比較して攻撃成功率を23〜41%増幅させることを実証した。この問題はプロトコルの「設計思想」そのものに起因しており、個別の実装バグの修正だけでは解決できない。

別の大規模調査（arXiv: 2506.13538）では、1,899のオープンソースMCPサーバ実装を分析した結果、7.2%に一般的な脆弱性、5.5%にMCP固有のツールポイズニング攻撃が確認された。さらに66%のサーバにコードスメルが存在し、セキュリティ以前のコード品質にも課題があることが示された。

主要MCPサーバで発見された脆弱性

2025年から2026年にかけて、広く利用されているMCPサーバで複数の重大な脆弱性が発見された。特に注目すべきは、プロトコル策定元であるAnthropic自身のサーバにも深刻な問題が含まれていた点である。

Anthropic公式 Git MCPサーバ（CVE-2025-68143/68144/68145）

2025年9月に報告され、同年12月に修正、2026年1月に公開された3件のCVEは、いずれも入力検証の不備に起因する。CVE-2025-68145はリポジトリパスのバイパスであり、--repositoryフラグがrepo_path引数を検証しないため、システム上の任意のリポジトリへのアクセスを許していた。CVE-2025-68143はgit_initツールが任意のファイルシステムパスを受け入れ、検証なしでGitリポジトリを作成する問題である。CVE-2025-68144はgit_diffおよびgit_checkoutがユーザー制御の引数をGitPythonにそのまま渡しており、--output=/path/to/fileのようなインジェクションによるファイル上書きが可能であった。ファイルシステムMCPサーバと併用された場合、リモートコード実行にまで至る可能性があった。

Microsoft MarkItDown MCPとSSRF脆弱性

BlueRock Securityが2026年1月23日に公開した「MCP fURI」調査は、MicrosoftのMarkItDown MCPサーバにおけるSSRF脆弱性を明らかにした。convert_to_markdownツールが任意のURIを無制限に呼び出せる設計であり、AWS環境のIMDSv1を通じてインスタンスメタデータからクレデンシャル（アクセスキー・シークレットキー）を取得し、AWSアカウントの完全な乗っ取りが可能であることが実証された。同調査で分析した7,000超のMCPサーバの36.7%が同様のSSRFリスクに晒されていた。

mcp-remote（CVE-2025-6514、CVSS 9.6）

43万7,000以上のダウンロード数を持つmcp-remoteパッケージには、悪意あるMCPサーバが細工したOAuth認証エンドポイントURLを返すことで、OSコマンドインジェクションを引き起こす脆弱性が存在した。Claude Desktop、Cursor、Windsurfの利用者が影響を受け、CVSSスコア9.6（Critical）が付与された。

Figma MCPサーバ（CVE-2025-53967、CVSS 7.5）

Impervaが2025年7月に発見したFramelink Figma MCPサーバの脆弱性は、child_process.execに未検証のURL入力が渡される古典的なコマンドインジェクションであった。同一ネットワーク上の攻撃者やDNSリバインディングを通じたリモートコード実行が可能であり、2025年9月にバージョン0.6.3で修正された。

ツールポイズニングとプロンプト注入の脅威

MCPの最も深刻なセキュリティ課題のひとつが、ツールポイズニング（Tool Poisoning）である。これはMCPツールの説明文やメタデータに、ユーザーには不可視だがLLMには解釈可能な悪意ある指示を埋め込む攻撃手法である。

MCPToxベンチマークが示す攻撃成功率

2025年8月に公開されたMCPToxベンチマーク（arXiv: 2508.14925）は、45の実稼働MCPサーバと353の実ツールを対象に、10カテゴリ・1,312のテストケースで攻撃を評価した。結果、o1-miniで72.8%、20の主要LLMエージェント全体で平均60%以上の攻撃成功率が記録された。一方、Claude-3.7-Sonnetの拒否率は3%未満と最も高く、モデル間の耐性に大きな差があることが示された。

攻撃手法の多様化

ツールポイズニングは複数の変種に進化している。Full-Schema Poisoning（FSP）はツール説明だけでなくスキーマ全体に悪意ある指示を拡張する手法であり、CyberArkが詳細に分析した。MCP Rug Pullは、初回登録時には正当なツール説明を提示し、承認後にサイレントに悪意あるバージョンへ差し替える手法である。Tool Shadowingでは、悪意あるサーバが他のツールの動作を変更する説明を注入し、エージェント全体の振る舞いを改変する。

より実践的な攻撃として、Log-To-Leak攻撃がある。これはエージェントに悪意あるロギングツールの呼び出しを強制し、機密情報を隠密に外部へ流出させる手法であり、GPT-4o、GPT-5、Claude-Sonnet-4を含む4つの主要エージェントで実証された。GitHub MCPサーバに対するToxic Agent Flow攻撃では、悪意あるGitHub Issueを処理させることでエージェントの乗っ取りに成功している。

プロトコル設計レベルの構造的問題

個別の実装脆弱性に加え、MCPプロトコルの設計そのものに内在するセキュリティ上の課題が指摘されている。これらは特定のサーバやクライアントの問題ではなく、プロトコル仕様に起因する構造的リスクである。

セッションIDのURL露出

MCP仕様はセッション識別子をURL内に配置することを規定している（例: GET /messages/?sessionId=UUID）。これはセキュリティのベストプラクティスに根本的に反する設計である。サーバログ、Refererヘッダ、ブラウザ履歴・キャッシュを通じてセッションIDが漏洩し、セッションハイジャックや不正アクセスのリスクが生じる。GitHub Issue #544でもこの設計上の問題が議論されている。

メッセージ署名の不在

MCPにはプロトコルレベルでのメッセージ署名・認証メカニズムが存在しない。これにより、悪意あるツールサーバが複数の会話ターンにわたって永続的な指示を注入できる。ツールメタデータに埋め込まれた隠し指示は、APIおよびUIの各層をシームレスに通過する。ツールを呼び出さずとも、ツールサーバを会話コンテキストに追加するだけで悪用が可能になるという深刻な設計上の問題がある。

能力証明の欠如と暗黙的信頼伝播

論文「Breaking the Protocol」は、3つの根本的なプロトコルレベルの脆弱性を特定した。第一に、能力証明（Capability Attestation）の不在により、サーバは任意の権限を主張できる。第二に、出所認証なしの双方向サンプリングがサーバサイドのプロンプトインジェクションを可能にする。第三に、マルチサーバ構成における暗黙的信頼伝播が、すべてのリスクを継承させる。同論文が提案するAttestMCPは、後方互換性を維持しつつ能力証明とメッセージ認証を追加する拡張であり、攻撃成功率を52.8%から12.4%に低減し、メッセージあたりのレイテンシオーバーヘッドは中央値8.3msにとどまる。

CoSAIホワイトペーパーに基づく防御フレームワーク

2026年1月27日、Coalition for Secure AI（CoSAI）は「Securing the AI Agent Revolution: A Practical Guide to MCP Security」を公開した。このホワイトペーパーは12の脅威カテゴリにわたる約40の脅威を体系化し、5つの重要なセキュリティ優先事項を提示している。

1. アイデンティティとトレーサビリティ

エンドツーエンドのエージェントアイデンティティの確立が不可欠である。MCPサーバとエージェントは最小権限の原則に従って運用し、きめ細かな認可制御を実装する必要がある。

2. 入力検証とスキーマ保護

信頼境界における入力・データのサニタイズと厳格なホワイトリストの適用が必須である。すべてのLLM/MCP出力を信頼されていないものとして扱い、プロンプトインジェクション検出と厳密なスキーマ検証を実装する。

3. サンドボックスと分離

MCPサーバにはサンドボックス化・分離が必須であり、LLM生成コードの実行は必ず隔離環境で行う。コンテナ単体ではセキュリティ境界として不十分であるとCoSAIは明確に警告している。

4. ログと可観測性

MCPホスト・クライアント・サーバ間でログを一元化し、ツール決定・パラメータ・プロンプトを記録する。ゲートウェイやプロキシを活用した集中的な監視機能の実装が推奨される。

5. サプライチェーン管理

ライフサイクルとサプライチェーンの管理を徹底し、必須のコード署名検証、ソフトウェア構成分析（SCA）、承認済みMCPサーバのホワイトリスト、ハッシュ付きの依存関係ピニング、そしてセキュアなソフトウェア開発ライフサイクル（SSDLC）の実践を義務化する。

これらの対策に加え、Trail of Bitsが2025年7月に公開したmcp-context-protectorのように、Trust-on-First-Use方式のピニングやANSI制御文字のサニタイズなど、実装レベルで防御層を追加するツールの活用も有効である。また、Invariant Labs（現Snyk）が開発したMCP-Scanのようなセキュリティスキャナーを継続的に実行し、ツールポイズニングの早期検出を行うことが推奨される。

FAQ

MCPのSSRF脆弱性とは何か？

MCPサーバがツール呼び出しを通じて任意のURIにアクセスできる設計上の問題である。BlueRock Securityの調査では7,000超のサーバの36.7%が影響を受け、AWS環境ではクレデンシャル窃取によるアカウント乗っ取りのリスクがある。

ツールポイズニング攻撃はどう防げるか？

MCPツールの説明文やスキーマに悪意ある指示が埋め込まれていないかを検証するセキュリティスキャナー（MCP-Scan等）の導入、承認済みサーバのホワイトリスト運用、そしてツール出力を信頼しない設計原則の徹底が有効である。

Anthropic公式MCPサーバにも脆弱性があったのか？

2025年9月に報告され12月に修正された3件のCVE（CVE-2025-68143/68144/68145）により、パスバイパス、引数インジェクション、無制限の初期化が可能であった。プロトコル策定元のサーバにも脆弱性があった事実は、エコシステム全体のセキュリティ課題を象徴している。

CoSAIの防御フレームワークの要点は？

2026年1月に公開されたCoSAIホワイトペーパーは、アイデンティティ管理、入力検証、サンドボックス化、ログの一元化、サプライチェーン管理の5つを重要な優先事項として挙げている。約40の脅威に対する実践的な防御指針を提供している。

MCPを安全に利用するためにまず何をすべきか？

承認済みMCPサーバのみをホワイトリストで管理し、すべてのツール出力を信頼されていないものとして扱い、ネットワークレベルでのサンドボックス化を実装することが最優先である。CoSAIの防御フレームワークを参照し、段階的にセキュリティ対策を強化することを推奨する。

参考文献