MCPサーバーはどこが危ない?主要な脆弱性と導入前のチェックリスト【2026年版】

MCPサーバーの一般的な脆弱性を悪用される前に修正する方法

by Mohammed Mohsin Turki, 加藤龍彦 | May 14, 2026

翻訳者ノート

こんにちは!コンテンツチームの加藤です。

企業のAI活用が加速する昨今、MCPの本番環境導入を検討している方で「セキュリティはどこまで考えればいいの?」とお悩みの方は多いのではないでしょうか。本記事はその問いに正面から答えるもので、プロンプトインジェクションからクレデンシャル管理まで、6つの脆弱性クラスと具体的な対策を体系的に整理しています。本番リリース前のチェックリストと運用後の監視設定まで一通りカバーしているので、MCPセキュリティの設計指針としてご利用いただけます。

Mitigate MCP Server Vulnerabilitiesエンタープライズエージェントにとって、Model Context Protocol(MCP)は今やAIを重要なデータやツールに接続するための標準プロトコルになりつつあります。しかし、多くのチームが連携やワークフローの構築を優先し、セキュリティを後回しの設定作業として扱っているため、導入のスピードがセキュリティ対策を上回っています。

17の主要MCPサーバーを監査した結果、平均セキュリティスコアは100点中34点であり、すべてのサーバーでパーミッション宣言が一切実施されていませんでした。これはパッチ適用で解決できる問題ではなく、設計の問題です。MCPのセキュリティは、インシデント発生後に後付けするのではなく、実装初日から組み込む必要があります。

本記事では、MCPの6つの一般的な脆弱性を解説し、サーバーの堅牢化、アクセス制御、認証情報管理、そして本番稼働後も継続的にセキュリティを維持するための監視手法を紹介します。

MCPサーバーの主な脆弱性と対策

  • プロンプトインジェクション — 入力をツール呼び出し前にサニタイズし、人間による承認を必須にする

  • ツールポイズニング/ラグプル — 署名済みマニフェストとバージョン固定で未承認の変更を検出する

  • コマンドインジェクション — ユーザー文字列をシェルコマンドに渡さず、安全なAPIとスキーマ検証を徹底する

  • SQLインジェクション — パラメータ化クエリのみを使用し、ツールのDBアクセスを読み取り専用に限定する

  • クレデンシャル窃取 — 静的シークレットをマネージドボルトに移行し、セッションごとに最小権限のトークンを発行する

  • コンテキスト漏洩/クロスサーバーシャドーイング — エージェントごとにコンテキストウィンドウを分離し、ツール名の衝突を監視する

MCPサーバーの主な脆弱性を理解する

MCPのクライアント・サーバーアーキテクチャは、従来のセキュリティ制御が想定していなかった新たな攻撃経路を生み出します。AIエージェントとエンタープライズシステムの間に位置するMCPは、ツールの呼び出し、データフロー、アクセス管理を担います。AI生成の呼び出し、動的スキーマ、マルチエージェントのオーケストレーションは、WAFやSIEMが検出に最適化されていない新たなインジェクションと権限昇格のリスクを生み出します。

現在ベータ版のOWASP MCP Top 10は、最も重大なリスクカテゴリの分類体系を定義しています。文書化された攻撃の大部分を占めるのは、以下の6つの脆弱性クラスです。

脆弱性

定義

主なリスク

プロンプトインジェクション

AIへの入力に悪意ある指示を埋め込み、安全でないツール呼び出しやデータ漏洩を引き起こす

入力のサニタイズと人間による承認が主要な対策となる

ツールポイズニング/ラグプル

悪意あるツール記述子が隠れた動作をエージェントのコンテキストに注入し、承認後にツールが静かに動作を再定義する

自動承認が有効な場合、ツールポイズニング攻撃の成功率は84.2%に達する

コマンドインジェクション

信頼できない入力がシェルコマンドとして解釈され、OSレベルのアクセスが可能になる

独立監査では、テスト対象MCPサーバーの43%に脆弱性が発見された

SQLインジェクション

不適切な引数処理により、クエリが操作されてデータの漏洩や改ざんが発生する

AI生成のクエリは、手動で記述されたパラメータ化クエリに比べてインジェクション対策が甘くなりやすい

クレデンシャル窃取

スコープが広いトークンや静的なシークレットにより権限昇格が可能になる

MCPサーバーの53%が長期間有効な静的シークレットを主要な認証手段として使用している

コンテキスト漏洩/クロスサーバーシャドーイング

エージェント間で意図せずデータが流出し、悪意あるサーバーが正規のツール呼び出しを横取りする

共有サービスアカウントを使うと追跡が困難になり、横断的な侵害(ラテラルムーブメント)を許してしまう


各脆弱性クラスには、それぞれ異なる対策が必要です。以下のセクションで個別に解説します。

MCP Server Vulnerabilities Attack Paths

プロンプトインジェクションと間接インジェクション

概要:攻撃者はAIへの入力、またはAIが後で処理するコンテンツに悪意ある指示を埋め込み、サーバーに安全でないツール呼び出しや機密データの漏洩を行わせます。間接インジェクションでは、ユーザーのプロンプトには直接触れず、エージェントがユーザーの代わりに読むドキュメント、メール、サポートチケットにペイロードを仕込みます。

実例:2025年7月、Supabaseへの特権アクセスを持つCursorエージェントが悪意あるサポートチケットによって乗っ取られる事例が研究者によって実証されました。埋め込まれたSQL命令がエージェントに機密トークンを読み取らせ、チケットスレッドに返信させました。行レベルのセキュリティを回避できたのは、特権アクセス、未検証の入力、外部出力チャネルという3つの条件が重なったためです。

主な対策:

  • ツール呼び出しを実行する前に、すべての入力をスキャンして正規化する

  • 呼び出せるツールとその条件を限定する許可リスト(allowlist)を強制適用する

  • 書き込み、削除、または機密スコープへのアクセスを伴う操作には、人間による明示的な承認を必須とする

  • メール、ドキュメント、Webページなどの外部コンテンツはすべてインジェクションの攻撃面として扱う

CData Connect AIの対応:Connect AIのスコープ付きMCPアーキテクチャは、ワークスペースとツールキットを使って各エージェントが参照・実行できる範囲を明確に定義します。インジェクションされた命令が実行できる操作は、そのエージェントに許可されたデータとアクションのみに限定されます。

ツールポイズニングとラグプル攻撃

概要:ツールポイズニングは、悪意あるツール記述子がエージェントのコンテキストに隠れた動作を注入する攻撃です。ツールのメタデータはユーザーには表示されないため、実行時に攻撃が見えません。特に危険なのがラグプルの亜種で、ツールが審査・承認を通過した後、数日後に静かに動作を再定義し、APIキーを別の場所に転送したり認証情報を外部に送り出したりします。再承認は必要ありません。

実例:Invariant Labsが実証した汚染された計算ツールは、SSHキーとMCP設定ファイル内のすべての認証情報を読み取り、関数のパラメータにエンコードして攻撃者に送信しました。ユーザーには正しい計算結果が返され、インターフェース上には何も異常が表示されませんでした。

主な対策:

  • すべてのツール連携に署名済みマニフェストとバージョン固定を必須とする

  • 初回承認後にツールの記述が変更された場合、MCPクライアントがユーザーに通知するよう設定する

  • 未検証または非公式レジストリのツールを自動承認しない

CData Connect AIの対応:Connect AIのツールキットモデルは、各エージェントに提供されるツールの種類を厳密に定義します。ワークスペースとツールキットの組み合わせごとに専用のMCPサーバーとしてデプロイされるため、エージェントは意図されたスコープ内でのみ動作し、未承認のツール置き換えはアーキテクチャレベルで防止されます。

コマンドインジェクションとOSレベルの侵害

概要:コマンドインジェクションは、信頼できない入力がシェルコマンドとして解釈され、システムへの不正アクセスが発生する攻撃です。MCPの環境では、AIエージェントがユーザーのコンテキストから動的にツール引数を生成するため、ほとんどのツール開発者が想定しない入力に対して自然なインジェクション経路が生まれます。

実例:GitHub Kanban MCP Serverで報告されたCVE-2025-53818はこのパターンの典型例です。add_commentツールがユーザー指定のIssue番号をサニタイズせずNode.jsのexec()に渡していたため、攻撃者はシェル文字を注入してサーバー上で任意のコマンドを実行し、データ層からOS全体への侵害につなげることができました。

主な対策:

  • ユーザーの文字列をシェルコマンドに直接渡さない

  • 安全なAPIを使用する(Pythonならsubprocessshell=False、NodeならExecではなくexecFile

  • 実行前にすべての引数を厳格なスキーマで検証する

  • ツールの実行をサンドボックス化し、突破された場合の影響範囲を最小化する

SQLインジェクションとデータベースへの不正アクセス

概要:SQLインジェクションは攻撃者がクエリを操作し、データを漏洩・改ざんする攻撃です。MCPの環境では新たなリスクが加わります。エージェントが自然言語からクエリを生成するため、手動で記述されたパラメータ化クエリほど厳密な処理が行われません。パラメータ化されていない文字列が1つあるだけで、5,000以上のフォークに影響が及ぶことがあります。

実例:Trend Micro Researchが発見したAnthropicのリファレンスSQLite MCPサーバーの脆弱性では、攻撃者が悪意あるプロンプトを注入してデータを窃取し、エージェントのワークフローを乗っ取ることができました。このリポジトリはアーカイブされる前にすでに5,000回以上フォークされており、パッチも提供されませんでした。

主な対策:

  • 文字列を結合したクエリは使わず、パラメータ化クエリのみを使用する

  • 書き込みアクセスが不要な場合、ツールのDBアクセスを読み取り専用に制限する

  • 本番公開前に、ツールからDBへの引数マッピングをすべて監査する

CData Connect AIの対応:Connect AIはコネクタ層でソースレベルのパーミッションを強制します。エージェントはDBの生の認証情報に直接アクセスするのではなく、定義されたアクセススコープ内でクエリを実行するため、侵害されたツールやクエリが到達できる範囲が限定されます。

クレデンシャル窃取と不正アクセス

概要:トークンやシークレットは権限昇格への最も直接的な経路です。スコープが広いクレデンシャルが侵害されると、そのエージェントがアクセスを許可されているすべてのシステムが危険にさらされます。マルチエージェント環境では、そのスコープが意図より広くなりがちであり、長期間有効な静的シークレットを使っていると、手動でローテーションするまで侵害状態が続きます。

実例:Invariant Labsが2025年5月に記録した「GitHub MCPデータ窃取事件」では、GitHub MCPサーバーがすべてのリポジトリをカバーする広範な個人アクセストークン(PAT)で設定されていたことが悪用されました。悪意あるGitHub Issueがプロンプトインジェクションを通じてエージェントにプライベートリポジトリの読み取りと給与データ・プロジェクト詳細のパブリックコメントへの書き込みを指示し、特別なアクセス権は一切不要でした。過剰な権限を持つトークンが唯一の原因です。

主な対策:

  • すべてのシークレットをリポジトリの外部にあるマネージドボルトに保管し、APIキーやトークンをコードにハードコードしない

  • ツールごと・セッションごとに、必要最小限の権限にスコープしたクレデンシャルを使用する

  • 2025年6月のMCP仕様はOAuth 2.1を必須とし、トークンバインディングをベースラインとして定めています。オプションの強化策ではなく、最低限の要件として扱ってください

CData Connect AIの対応:Connect AIはパススルー認証を採用しており、プラットフォーム上に静的シークレットを保持しません。認証情報がマネージドレイヤーに保存されないため、インフラレベルでクレデンシャル窃取を排除します。詳しくはAIエージェントのセキュアな接続設計をご参照ください。

コンテキスト漏洩とクロスサーバーシャドーイング

概要:コンテキスト漏洩は、共通の名前空間、メタデータの衝突、コンテキストウィンドウの重複を通じて、エージェントやツール間で意図せず情報が流出する現象です。クロスサーバーシャドーイングは能動的な攻撃で、悪意あるサーバーが正規サービスへの呼び出しを横取りするツール記述子を注入し、パラメータをログに記録したり動作を変更したりしながら呼び出しを透過的に転送します。

実例:研究者が実証したクロスサーバーシャドーイング攻撃では、悪意あるサーバーが正規のメールツールより優先されるよう設計されたsend_emailというツールを登録しました。エージェントは攻撃者のバージョンに呼び出しをルーティングし、メール本文と宛先リストをすべてログに記録してから転送しました。ユーザー側には正常な動作に見えました。

主な対策:

  • タスクごとにコンテキストウィンドウを分離し、ツールごとに厳格なパーミッション境界を設ける

  • マルチエージェント環境では各エージェントに固有のIDを割り当てる。共有サービスアカウントは追跡を不可能にする

  • マルチサーバー環境でツール名の衝突を監視し、予期しないツール選択パターンを検知した際にアラートを上げる

6つの脆弱性クラスを把握したら、次はサーバーが本番環境に到達する前に具体的なコントロールへと落とし込みます。

本番リリース前のセキュリティチェックリスト

本番環境に到達する前にMCPの攻撃の大部分をブロックするには、厳格な事前チェックリストが欠かせません。多くのインシデントは、「対策済みと思っていた部分が実は未検証だった」というギャップから始まります。

MCPサーバーとツールのインベントリ整備と許可リスト管理

連携を本番に投入する前に、稼働中のすべてのMCPサーバーとツールを棚卸しし、審査済みの許可リストに含まれるものだけを使用します。MCPサーバーの約38%は非公式チャネルから入手されており、非公式サーバーの約3%にはハードコードされた認証情報が意図的に含まれ、開発者が本番キーを接続するよう誘導しています。登録済みのすべてのエンドポイントで証明書検証を強制し、承認プロセスを迂回した追加がないか定期的に監査します。

MCPサーバーの設計・運用の詳細については、MCPサーバーの設計と運用ガイドも参照してください。

静的スキャンとコードレビューの実施

サーバーとプラグインのアーティファクトを登録する前に、MCP専用のスキャナーとスキーマリンターを実行します。外部URLを参照したりシェルコマンドを実行したりするツール記述子にはフラグを立てます。npm auditやSnykなどのツールで依存パッケージの既知の脆弱性を本番環境に持ち込む前に検出できます。

ツールバージョンの固定と署名

すべてのツール連携に署名済みマニフェストとバージョン固定を必須とします。未署名または未固定のツールはラグプル攻撃の主要な経路です。今日の審査を通過したツールが、再承認なしに翌日悪意ある更新を配信できてしまいます。

合成データを使ったサンドボックステスト

新規または更新されたツールは、本番環境へのアクセスを許可する前に、合成データを使った隔離環境で実行します。サンドボックステストでは静的なコードレビューでは検出できない動作が表面化します。予期しない外部呼び出し、権限昇格の試み、スキーマの改ざんなどを、ライブデータを未検証のツールにさらすことなく確認できます。

最小権限の原則によるパーミッション設定

ツールごと・セッションごとに最小権限を適用します。承認前の迅速なパーミッションレビューの確認項目:

  • 各ツールは必要なリソースのみにスコープした固有のクレデンシャルを持つ

  • 組織全体または共有のトークンを使用していない

  • 書き込みアクセスには明示的な根拠があり、デフォルトは読み取り専用

  • トークンの有効期限が設定され、テスト済みである

  • すべてのツール権限が記録され、特定の承認者に紐づいている

事前対策はエントリポイントを堅牢にします。ランタイム対策は抜け漏れへの対応です。

ランタイム堅牢化とポリシー適用の実装

静的な対策はデプロイ時に既知の脆弱性を捕捉します。ランタイム対策は、ゼロデイ攻撃、ツールのドリフト、本番環境でのみ現れる攻撃パターンから守ります。

ガードレール付きMCPゲートウェイの導入

ゲートウェイは許可リストを一元管理し、リスクのあるツール呼び出しがソースシステムに到達する前にインターセプトし、機密操作に明示的な承認を必須とします。ゲートウェイレベルの拒否は、プロンプトインジェクションとツールポイズニングに対して最も効果的な制御手段です。個々のツールの動作に関係なく、ポリシーが一律に適用されます。

入力検証と承認制御の強制

すべての外部入力は検証をパスするまで信頼できないものとして扱います。入力を正規化し、インジェクションパターンをスキャンし、ツール呼び出しを実行する前に引数の制約を厳格に適用します。レコードの削除、本番システムへの書き込み、機密スコープへのアクセスなど影響の大きい操作には、人間によるレビューと承認を必須とします。

安全なAPIの使用と実行サンドボックス化

すべてのツール呼び出しに安全なAPIを使用し、許可リストで検証できない入力は拒否します。ツールの実行をサンドボックス化して影響範囲を限定します。サンドボックス化されたプロセスは、OSレベルへのアクセス昇格や許可されたスコープ外へのデータ持ち出しができません。

異常な動作の監視と検知

各ツールの動作ベースラインを設定し、逸脱を検知してアラートを上げます。悪用が進行中であることを示す早期シグナル:

  • 異常に長い、または構造化された入力を持つツール呼び出し(プロンプトインジェクションのシグネチャ)

  • 通常の使用パターンを逸脱したツールやスコープへのアクセス

  • ベースラインを超えた認証失敗の急増

  • ファイルパス、環境変数、または外部URLを予期せず参照するツール引数

ランタイム堅牢化は進行中の攻撃を遅らせます。次に紹介する対策は最も一般的な根本原因、認証情報の不適切な管理を防ぎます。

クレデンシャルとセッション管理のベストプラクティス

認証情報の不適切な管理は、MCPのインシデント事例で最も多く見られる根本原因です。以下の3つの対策が、最も一般的な障害パターンに対処します。

シークレットの安全な保管と定期的なローテーション

APIキー、トークン、認証情報を設定ファイルやソースコードにハードコードしないでください。ランタイムへの注入にはマネージドシークレットボルトを使用します。Astrix SecurityのオープンソースMCP Secret Wrapperは起動時にAWS Secrets Managerからシークレットを取得するため、ホストマシン上に静的な認証情報が一切存在しません。

検証済みIDへのセッションバインド

セッションIDを認証の代わりに使わないでください。すべてのセッションを検証済みのユーザーまたはサービスアカウントに照合して認証します。有効期限が短いセッション(15〜30分)、暗号学的に安全なセッションID生成、認証境界が変わった際の即時ローテーションを採用してください。

トークン再利用の禁止とリプレイ攻撃の検知

ツールごと・セッションごとに必要最小限の権限にスコープしたトークンを発行します。組織全体のトークンは使わないでください。複数のIPから同一トークンが使用されるアクセスログを監視します。リプレイ攻撃は自動的なログ分析で早期に検出できるパターンを残します。

クレデンシャル管理が厳密でも、継続的な監視なしには劣化します。最後のレイヤーは継続的なオブザーバビリティです。

継続的な監視とインシデント対応の構築

継続的な監視がなければセキュリティ態勢は劣化します。MCPサーバーの設定はドリフトし、上流APIは変わり、新たな攻撃手法は静的なチェックリストより速く登場します。

MCPアクティビティのロギングとオブザーバビリティの有効化

すべてのプロンプト、ツール呼び出し、レスポンス、認証イベントを構造化・クエリ可能な形式でキャプチャします。非構造化または不完全なログはインシデント後の分析を大幅に困難にし、コンプライアンス監査要件を満たせないことがあります。

SIEMと異常検知ツールの連携

MCPサーバーのテレメトリをSIEMに送信し、以下の重要度の高いトリガーにアラートを設定します。

アラートルール

検知対象

ツールバージョンのドリフト

登録バージョンと稼働バージョンの不一致。ラグプルの主要な指標

異常な権限付与

承認済み変更ウィンドウ外でのスコープ拡張

認証失敗の急増

クレデンシャルスタッフィングやリプレイ攻撃の試み

時間外または地域外アクセス

定義された時間帯または地域外からのアクセス

引数サイズの異常

確立されたベースラインより著しく大きな入力を持つツール呼び出し

脆弱性管理とパッチ適用サイクルの維持

MCPサーバーとそのツール依存関係は、本番サービスと同等のパッチ管理が必要です。定期的なレビューサイクルを設定し、各パッチ後にデプロイメントを検証し、スタックに関連するCVEの公開情報を追跡します。CVE-2025-6514(mcp-remote、CVSS 9.6)は437,000以上のインストールに影響しましたが、公開から数週間経っても多くが未パッチのままでした。

MCPセキュリティアーキテクチャの全体像については、CDataのMCPセキュリティ分析でマネージドとセルフホスト両方のデプロイメントにおける脅威モデルを解説しています。また、Microsoft Copilot StudioでMCPを安全に使う方法についてはCopilotのMCP OAuth接続設定をご参照ください。

CData Connect AIでMCPデプロイメントを保護する

MCPのセキュリティ障害の多くは共通の原因を持ちます。アーキテクチャが固まった後からセキュリティコントロールを追加する設計です。CData Connect AIはパススルー認証、ソースレベルのパーミッション、監査ログ、スコープ付きエージェント境界を350以上のエンタープライズソースにわたってデフォルトで組み込んでいます。

無料トライアルを開始するか、無料のライブデモを試すことで、ガバナンスの効いたMCP接続の実際の動作を確認できます。

よくある質問

MCPサーバーの侵害を早期に察知するには?

不正なSQL、予期しないツールの動作、許可されていないコマンドに注意してください。プロンプトインジェクションはログ上で異常に長いまたは構造化された入力として現れることが多いです。認証失敗の急増や使用されていないツールへのアクセスも重要なシグナルです。CData Connect AIはすべての接続ソースにわたる集中型の監査ログでこれらのパターンを表面化します。

MCP環境でOAuthトークンを安全に管理するベストプラクティスは?

OAuthトークンはコードリポジトリ外のマネージドボルトに保管してください。ツールごと・セッションごとに狭いスコープのトークンを発行し、組織全体のトークンは使いません。定期的にトークンをローテーションし、侵害が疑われる場合は即時ローテーションします。2025年6月のMCP仕様ではOAuth 2.1準拠とトークンバインディングがベースラインとして必須化されています。詳しくはConnect AIのMCPセキュリティ機能もご覧ください。

サンドボックステストはMCPサーバーのセキュリティをどのように向上させますか?

サンドボックステストでは、新規または更新されたツールを本番アクセスを許可する前に合成データを使った隔離環境で実行します。これにより、静的なコードレビューでは検出できない動作(予期しない外部呼び出し、権限昇格の試み、スキーマの改ざんなど)を表面化できます。

あなたの企業データをAIに対応

Connect AIは、AIアシスタントやエージェントに対し、350以上のエンタープライズシステムへのリアルタイムかつ管理されたアクセス権を提供します。これにより、AIは単に学習データだけでなく、実際のビジネスデータに基づいて推論を行うことが可能になります。

トライアルをスタート