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

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

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

これは理論上の攻撃対象領域ではありません。実際のパッケージに存在する実際のCVEであり、今まさに開発者たちがClaude Code、Codex CLI、Cursorに接続して使っているものです。

TL;DR

MCPサーバーはエージェントエコシステムにおいて最も急成長している統合インターフェースであると同時に、最も監査が行き届いていない領域でもあります。脆弱性データベースには50件が登録されており、内訳はCritical 13件、High 32件です。入力バリデーションの不備とプロンプトインジェクションが50件中30件を占めています。今週だけで、3つの異なるMCPサーバーから3件のSSRF脆弱性が1日で発見されました。³ パターンは明確です——コミュニティはMCPサーバーをレビューするよりも速くリリースしています。

重要ポイント

• Claude Codeユーザーの方へ： 接続するMCPサーバーの一つ一つが、信頼境界の拡張を意味します。今すぐclaude mcp listを実行して、何を接続しているか確認してください。数ヶ月前にインストールしたコミュニティ製MCPサーバーを使っている場合、その後パッチが適用されているか確認しましょう。
• ハーネス開発者の方へ： PreToolUseフックは、MCPツール呼び出しが未監査のサーバーに到達する前の最後の防衛線です。MCPツールの入力を実行前にバリデーションするフックの導入を検討してください——特にURL、ファイルパス、シェルコマンドを受け付けるサーバーに対しては重要です。
• MCPサーバー開発者の方へ： MCP仕様には「常に人間がループに入るべき（SHOULD）」と記載されています。これをMUST（必須）として扱ってください。すべての入力をバリデーションすること。ユーザーが制御可能な文字列を文字列補間でシェルコマンドに渡さないこと。OpenAPI仕様の$ref値はURLバリデーションなしに信頼しないこと。

データで見る現状

Vulnerable MCPプロジェクトは、MCPのセキュリティ問題を文書化したデータベースを運営しています。¹ 現在の状況は以下の通りです：

深刻度： Critical 13件、High 32件、Medium 5件。¹ 32名のセキュリティ研究者が調査結果を提供しています。影響を受けるサーバーには、Anthropic自身のGit MCPサーバー、公式MCP Inspector、Microsoft MarkItDown、GitHub Kanban、Figma、Jira、Grafana、Neo4j、Kubernetes、そして20以上のコミュニティ製サーバーが含まれます。¹

調査結果で最も衝撃的なのは、2,614のMCP実装のうち82%にパストラバーサルの危険があるファイル操作の脆弱性が存在していたという点です。² MCPサーバーの5台中4台が、攻撃者にアクセス権のないファイルの読み取りを許してしまう状態です。

5つの攻撃パターン

60日間のCVEラッシュから、5つの繰り返し発生するパターンが明らかになりました：²

1. ツールポイズニング。 MCPツールの説明文に悪意のある命令を埋め込む手法です。エージェントは説明文を読み取って信頼し、自身が認可されたツールを使って隠された命令を実行します。ポイズニングされたツール自体は実行されません——エージェントの正規ツールが攻撃を遂行するのです。このパターンはデプロイと防御のパラドックスで取り上げました。信頼は推移的ですが、監査はそうではありません。

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サーバーを公開します。サーバーはmcp-from-openapiを使用して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内、ノートPC上、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プロジェクトのデータベースと照合しましょう。¹ 積極的に使用していないサーバーは削除してください。

サーバーのバージョンを固定しましょう。 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

トランスポートの分離を検討しましょう。 HTTP MCPサーバーは独自のプロセスで動作し、明示的なネットワーク境界を持ちます。Stdioサーバーはエージェントのプロセスコンテキストを共有します。どちらのトランスポートも本質的に安全というわけではありません——より重要なのは、サーバーが認証情報、内部ネットワーク、機密ファイルパスへのアクセス権を持っているかどうかです。脅威モデルに必要な分離境界を提供するトランスポートを選択してください。

データベースを監視しましょう。 vulnerablemcp.infoのVulnerable MCPプロジェクトは、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プロジェクトのデータベースと照合しましょう。サーバーのGitHubリポジトリで最近のセキュリティアドバイザリも確認してください。