MCP サーバーは新たな攻撃対象領域

Model Context Protocolにセキュリティデータベースができました。登録件数は50件です。¹

60日間で30件のCVEが登録されました。調査対象となった2,614件のMCP実装のうち、82%がパストラバーサルの影響を受けやすいファイル操作の脆弱性を抱えていました。38〜41%のサーバーは認証が一切ありませんでした。² 開発者がMCPサーバーのデバッグに使う公式のMCP Inspectorツールには、RCE脆弱性が存在しました。広く利用されているmcp-remoteパッケージには、OSコマンドインジェクションのバグがありました。¹

これは理論上の攻撃対象領域ではありません。現実のパッケージにある現実のCVEであり、開発者たちが今まさにClaude Code、Codex CLI、Cursorに接続しているものです。本稿ではエージェントセキュリティの領域をプロトコルレベルの脅威分析へと拡張します。

TL;DR

MCPサーバーは、エージェントエコシステムで最も急成長している統合面です。そして最も監査されていない領域でもあります。脆弱性データベースの登録件数は50件で、クリティカル13件、ハイ32件。入力検証の失敗とプロンプトインジェクションが50件のうち30件を占めています。今週だけで、3種類のMCPサーバーに3件のSSRF脆弱性が1日で浮上しました。³ パターンは明確です。コミュニティはMCPサーバーをレビューするよりも速く出荷しているのです。

要点

• Claude Codeユーザーの方へ： 接続するすべてのMCPサーバーは、あなたが拡張する信頼境界です。今すぐclaude mcp listを実行し、何を接続しているか監査してください。数カ月前にインストールしたコミュニティ製MCPサーバーを動かしているなら、それ以降にパッチが当たっているか確認しましょう。
• ハーネス開発者の方へ： PreToolUseフックは、MCPツール呼び出しが未監査のサーバーに届く前の最後の防衛線です。特にURL、ファイルパス、シェルコマンドを受け取るサーバーについては、実行前にMCPツールの入力を検証するフックの導入を検討してください。
• MCPサーバー作者の方へ： MCP仕様には「常にhuman in the loopがあるべき（SHOULD）」と書かれています。これをMUSTとして扱ってください。すべての入力を検証しましょう。ユーザー制御下の文字列を、文字列補間でシェルコマンドに渡してはいけません。OpenAPI仕様の$ref値をURL検証なしに信頼してはいけません。

数字で見る現状

Vulnerable MCP Projectは、文書化されたMCPセキュリティ問題のデータベースを運営しています。¹ 現時点の状況は次のとおりです。

深刻度： クリティカル13件、ハイ32件、ミディアム5件。¹ 32人のセキュリティ研究者が発見内容を提供しました。影響を受けたサーバーには、Anthropic自身のGit MCPサーバー、公式のMCP Inspector、Microsoft MarkItDown、GitHub Kanban、Figma、Jira、Grafana、Neo4j、Kubernetes、そして20以上のコミュニティ製サーバーが含まれます。¹

最も痛烈な調査結果は次のものです。2,614件のMCP実装のうち、82%がパストラバーサルの影響を受けやすいファイル操作の脆弱性を抱えていました。² 5台中4台のMCPサーバーは、攻撃者にアクセスすべきでないファイルの読み取りを許してしまうのです。

5つの攻撃パターン

60日間のCVEの波は、5つの繰り返し現れるパターンを明らかにしました。²

1. ツールポイズニング。 MCPツールの説明文に、悪意ある指示を埋め込む手口です。エージェントは説明を読み、それを信頼し、自身の認可済みツールを使って隠された指示に従ってしまいます。汚染されたツール自体は実行されません。攻撃を実行するのはエージェントの正規のツールなのです。このパターンはdeploy-and-defendパラドックスで取り上げました。信頼は推移的に広がる一方で、監査は広がらないのです。

2. 外部データを介したプロンプトインジェクション。 GitHubのissue、Slackメッセージ、メール、Webページからコンテンツを取得するMCPサーバーは、攻撃者の制御下にあるテキストをエージェントのコンテキストに持ち込みます。インジェクションが狙うのはMCPサーバーではなく、サーバーの出力を読むエージェントです。サイレントエグレス攻撃対象領域は一般的な事例であり、MCPサーバーはその最も一般的な経路となっています。

3. 初回承認後の信頼バイパス。 Claude CodeはMCPサーバーの初回承認をユーザーに求めます。その後、ツール定義はセッション間で再プロンプトなしに変わる場合があります。インストール時には安全だったサーバーが、更新時には異なる挙動をする可能性があるのです。再検証ギャップは構造的な問題です。プロトコルはツール説明の暗号的な署名を要求していません。²

4. サプライチェーン侵害。 バックドア入りのMCPサーバーがレジストリに公開される事例で、正規のサーバーを装うパッケージも含まれます。サプライチェーンは攻撃対象領域であるで文書化したのと同じサプライチェーンのパターンが、MCPエコシステムに適用されています。

5. テナント横断の露出。 複数のMCPサーバーが、実行前に互いの関数呼び出しを傍受できる共有ホスティング環境のことです。⁴ 外側からは堅牢に見える分離境界が、複数のサーバーがプロセスやコンテナを共有すると崩れてしまいます。

SSRFパターン

今週の1回のスキャンで、3種類のMCPサーバーに3件のSSRF脆弱性が浮上しました。³

• n8n-mcp： インスタンスホストインジェクションを介した認証済みSSRF
• mcp-from-openapi： OpenAPI仕様の$ref値を介したSSRF。内部URLを含む悪意ある仕様によって、サーバーは初期化中にそれらのリソースを取得してしまいます
• stata-mcp： ユーザー提供URLの検証不足

MCPサーバーにおけるSSRFが特に危険なのは、サーバーがエージェントにはないネットワークアクセス権を持っているのが通常だからです。1つの悪意あるOpenAPI仕様が、いかにして資格情報窃取につながるかを見ていきましょう。

ステップ1。 攻撃者は、外部APIをラップする正当に見えるMCPサーバーを公開します。このサーバーは、OpenAPI仕様からツールを生成するためにmcp-from-openapiを使用しています。

ステップ2。 OpenAPI仕様には、内部アドレスを指す$refが含まれています。

components:
  schemas:
    Config:
      $ref: "http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name"

ステップ3。 initialize()の際、MCPサーバーはURLを取得することで$refを解決します。サーバーはあなたのインフラ上で動いています。VPC内、ラップトップ上、CIコンテナ内のいずれかで。リクエストは信頼できる送信元からAWSメタデータエンドポイントへ送られます。

ステップ4。 メタデータエンドポイントは、一時的なIAM資格情報を返します。アクセスキー、シークレットキー、セッショントークンです。

ステップ5。 サーバーはあなたのクラウド資格情報を手にしました。ツールの応答に乗せて持ち出すことも、外部エンドポイントに記録することも、直接使うこともできます。

エージェントは悪意ある行為を何もしていません。ユーザーはMCPサーバーを承認しました。OpenAPI仕様は普通に見えました。$refの解決はライブラリレベルで、誰もレビューしない層で発生しました。SSRFは、MCPサーバーのネットワーク上の位置を、攻撃者のネットワーク上の位置へと変換してしまうのです。

Microsoftは2026年3月に、クリティカルなAzure MCP SSRF（CVE-2026-26118）にパッチを当てました。同じパターンがAzureにも適用されました。認証トークンを窃取し、Azureリソースへの不正アクセスを許す可能性のある、深刻度の高い権限昇格の脆弱性です。⁵

対策

接続済みサーバーを監査する。 claude mcp listを実行し、すべてのサーバーを確認してください。Vulnerable MCP Projectのデータベースと照合しましょう。¹ 積極的に使っていないサーバーは削除してください。

サーバーのバージョンを固定する。 npmやpipからMCPサーバーをインストールする場合、バージョンを固定してください。自動更新は避けましょう。アップグレード前にチェンジログをレビューしてください。信頼バイパスのパターンがあるため、更新によって再承認なしにツール定義が変わる可能性があるのです。

入力検証フックを追加する。 MCPツール呼び出しに対するPreToolUseフックにより、サーバーに届く前に入力を検証できます。

#!/bin/bash
# .claude/hooks/validate-mcp-input.sh
INPUT_JSON=$(cat)
TOOL_NAME=$(echo "$INPUT_JSON" | jq -r '.tool_name // empty')

# Block MCP tools that accept URLs from passing internal addresses
if echo "$TOOL_NAME" | grep -q "^mcp__"; then
  TOOL_INPUT=$(echo "$INPUT_JSON" | jq -r '.tool_input | tostring')
  if echo "$TOOL_INPUT" | grep -qiE '(169\.254\.|10\.|172\.(1[6-9]|2|3[01])\.|192\.168\.|localhost|127\.0\.0\.1|metadata\.google|169\.254\.169\.254)'; then
    echo "Blocked: MCP tool input contains internal/metadata address" >&2
    exit 2
  fi
fi
exit 0

トランスポート分離を検討する。 ツール拡張エージェントのランタイム防御パターンは、ここに直接適用できます。すべてのMCPサーバーはエージェントが呼び出すツールであり、防御アーキテクチャは侵害されたツールを考慮しなければなりません。HTTP MCPサーバーは、明示的なネットワーク境界を持つ独自のプロセスで動作します。stdioサーバーはエージェントのプロセスコンテキストを共有します。どちらのトランスポートも本質的に安全ではありません。より大きな要因は、サーバーが資格情報、内部ネットワーク、機密ファイルパスへのアクセス権を持っているかどうかです。脅威モデルに必要な分離境界を与えるトランスポートを選びましょう。

データベースを定期的に確認する。 vulnerablemcp.infoにあるVulnerable MCP Projectは、MCPエコシステムにおいてCVEトラッカーに最も近い存在です。新しいサーバーをインストールする前に、必ず確認してください。

MCPエコシステムは急速に拡大しています。インデックス済みサーバーは3,000以上、月間ダウンロード数は1億回に達しています。⁶ しかしセキュリティ態勢はそれに追いついていません。1年前には存在しなかったデータベースに、50件の脆弱性。問題はプロトコルではありません。実装のほうです。そしてあなたのエージェントには仲介者がいるで書いたように、エージェントのツールチェーンにあるすべての中間層は、大半の開発者が監査しない傍受の機会なのです。

出典

よくある質問

Claude Codeに同梱されているMCPサーバーは影響を受けますか？

今回の脆弱性が主に影響するのは、コミュニティ製およびサードパーティのMCPサーバーであり、Claude CodeのコアMCPインフラではありません。ただし、公式のMCP InspectorツールにもかつてはインシデントとなるRCE脆弱性が存在しました。「公式」だからといって「無傷」とは限らないのです。

MCPサーバーの利用はやめるべきですか？

いいえ。MCPは強力な統合レイヤーです。ただし、すべてのMCPサーバーを信頼境界として扱ってください。接続しているものを監査し、バージョンを固定し、URL、ファイルパス、シェルコマンドを受け取るサーバーには入力検証フックを追加しましょう。

自分のMCPサーバーが脆弱かどうかを確認するには？

claude mcp listを実行して、接続済みサーバーを確認してください。Vulnerable MCP Projectのデータベースと1つずつ照合しましょう。サーバーのGitHubリポジトリで、直近のセキュリティアドバイザリもチェックしてください。