2026年1月20日、BlueRock Securityが公開した調査報告が、AIエージェントセキュリティの前提を根底から揺さぶった。Microsoft MarkItDown MCPサーバーに存在するSSRF（Server-Side Request Forgery）脆弱性──これ単体であれば古典的なWebセキュリティ問題に過ぎない。しかし、7,000超のMCPサーバーを横断分析した結果、36.7%が同様のSSRF露出リスクを抱えていたという事実は、問題の性質が個別の実装バグではなく、エコシステム全体の設計思想の欠陥であることを示している。テクノロジーの視点から分析すると、MCPという「AIの万能USBポート」が持つ構造的脆弱性は、従来のサプライチェーンセキュリティの枠組みでは捕捉できない新たな攻撃面を形成している。本記事では、プロンプトインジェクションの構造的限界とも深く連関するこの問題を、技術的メカニズムから防御設計まで掘り下げる。

MCP fURI脆弱性の技術的メカニズム ── MarkItDownが開いたパンドラの箱

Microsoft MarkItDown MCPサーバーは、GitHub上で85,000以上のスター、5,000以上のフォークを獲得した極めて人気の高いMCPサーバーである。その機能はシンプルで、PDF、Word、Excel、画像など多様なファイル形式をMarkdownに変換し、LLMが処理しやすい形にする。BlueRock Securityの主任ソリューションエンジニアDavid Onwukweが発見した脆弱性「MCP fURI」は、このサーバーのconvert_to_markdownツールに存在する。

技術的な問題の核心は、URI入力に対するバリデーションの完全な欠如にある。convert_to_markdownツールは任意のURI──HTTP、HTTPS、file://プロトコルを含む──を無制限に受け入れ、サーバーサイドでリソースを取得する。一般的なWebアプリケーションであれば、URLスキームの制限、プライベートIPレンジのブロック、ホワイトリスト方式のドメイン制限が実装されるべき箇所に、何のフィルタリングも存在しなかったのである。

この脆弱性がMCPの文脈で特に危険なのは、ツール呼び出しの主体がAIエージェントだからである。従来のSSRFは、攻撃者が明示的にリクエストを構築する必要があった。しかしMCPでは、プロンプトインジェクションを介してエージェントに悪意あるURIを渡すことで、エージェント自身がSSRFの実行主体となる。攻撃者はLLMの入力コンテキストにhttp://169.254.169.254/latest/meta-data/iam/security-credentials/というURLを紛れ込ませるだけでよい。エージェントはこれを「変換すべきリソース」として忠実に処理し、結果をLLMの出力コンテキストに返す。

脆弱性診断の実務でプロトコルやHTTPヘッダ一つの設定ミスが致命的な脆弱性になる事例を幾度も経験してきたが、MCPのSSRFは設定ミスではなく設計の不在が本質である。「ファイル変換ツール」をMCP経由でAIエージェントに公開した瞬間、それはネットワークプローブとして機能する攻撃兵器に変わった。

AWS EC2メタデータ窃取 ── クラウドインフラ全面崩壊のシナリオ

MarkItDown SSRFの最も深刻なエクスプロイトシナリオは、AWS EC2インスタンスメタデータサービス（IMDS）を標的とした認証情報の窃取である。EC2インスタンスには、http://169.254.169.254/というリンクローカルアドレスで、IAMロールに紐づく一時的な認証情報を含むメタデータサービスが提供されている。

攻撃チェーンは以下のステップで構成される。

  1. メタデータエンドポイントへのアクセス: MCPツールにhttp://169.254.169.254/latest/meta-data/iam/security-credentials/を渡し、インスタンスに紐づくIAMロール名を取得する
  2. 認証情報の抽出: 取得したロール名を使い、http://169.254.169.254/latest/meta-data/iam/security-credentials/{role-name}にアクセスし、AccessKeyId、SecretAccessKey、Tokenの3点セットを窃取する
  3. AWSアカウントの掌握: 取得した認証情報でAWS APIを呼び出し、ロールの権限範囲に応じてS3バケットの読み取り、EC2インスタンスの操作、IAMポリシーの変更まで実行可能になる

問題を深刻化させているのがIMDSv1の普及率である。AWSは2019年にIMDSv2をリリースしトークンベースの認証を追加したが、BlueRock Securityによれば「Amazonのインスタンスの大多数がまだIMDSv1を使用している」。IMDSv2ではPUTリクエストでトークンを取得し、カスタムヘッダX-aws-ec2-metadata-tokenとして付与する必要があるため、GETリクエストしか生成できないSSRFでは突破できない。しかしIMDSv1が残存するレガシー環境ではMCPサーバーのSSRFがクラウドインフラの全面侵害に直結する。

エージェンティックAIの攻撃面産業化でも指摘されている通り、2026年2月にはEC2メタデータ窃取を狙ったSSRF攻撃キャンペーンが大規模に確認されている。MCPサーバーはこの既知の攻撃ベクトルに自動化された新たな入口を提供してしまった。

36.7%の衝撃 ── 7,000サーバー横断分析が暴いた構造的欠陥

BlueRock Securityは自社が運営するMCP Trust Registry（mcp-trust.com）を通じて、7,000を超えるMCPサーバーのセキュリティスキャンを実施した。その結果、36.7%のサーバーがSSRF脆弱性を潜在的に抱えていることが判明した。これは特定のソフトウェアのバグではなく、MCPサーバー開発におけるセキュリティ設計の体系的な欠落を意味する。

同時期に独立した研究者が実施した別の調査も、この構造的問題を裏付けている。公式MCPレジストリに登録された518サーバーを全数スキャンした結果、41%（214サーバー）がプロトコルレベルで認証を一切実装していないことが明らかになった。さらに、認証なしのサーバーのうち156サーバーが、接続した誰に対してもツールの呼び出しを許可していた。具体的には以下のような機能が無認証で公開されていた。

  • Senditプラットフォーム: ソーシャルメディアサーバー経由で131のツールが露出
  • Bitrise CI/CD: delete_appやregister_ssh_keyを含む67ツールが列挙可能
  • Supabaseデプロイメント: 匿名キーの設定ミスにより完全な実行権限を付与
  • その他、ツイート投稿、メール送信、決済処理、Webサイト作成が可能な32サーバー

MCPはAnthropicが2024年11月に公開したプロトコルであり、わずか1年で17,000以上のサーバーが登録されるまでに急拡大した。しかしその成長速度にセキュリティが追いついていない。レッドチーミング、コードレビュー、脅威モデリングは全てオプションであり、強制メカニズムが存在しない。あるセキュリティ専門家は「MCPサーバーのダウンロードは初期インターネット時代にソフトウェアをダウンロードするのに似ている」と評しており、npmやPyPIが経験したサプライチェーンセキュリティの課題と本質的に同一の問題がMCPに再来している。

プロンプトインジェクション連鎖 ── エージェント自律性がSSRFを「設計思想の欠陥」に昇格させた構造転換

MCPのSSRF問題を古典的なWebセキュリティの文脈から切り離しているのが、プロンプトインジェクションとの連鎖である。従来のSSRFは、攻撃者が直接HTTPリクエストを操作する必要があった。MCPでは、この操作がLLMのコンテキストウィンドウを介して間接的に行われる。

攻撃シナリオを具体的に描くと以下のようになる。

  1. 初期侵入: 攻撃者がMarkdownファイル、Webページ、PDF等のドキュメントに悪意あるプロンプトを埋め込む
  2. エージェント取り込み: AIエージェントがRAG（Retrieval-Augmented Generation）やWeb検索でこのドキュメントを取得し、コンテキストに取り込む
  3. ツール呼び出しの誘導: 埋め込まれたプロンプトがエージェントに「このURLをMarkdownに変換して」と指示する
  4. SSRF発火: エージェントがMarkItDown MCPツールを呼び出し、内部ネットワークリソースやクラウドメタデータにアクセスする
  5. 情報窃取: 取得した認証情報がLLMの出力に含まれ、攻撃者のコントロール下にあるチャネルに流出する

この連鎖の核心的な問題は、エージェントの自律性がSSRFのブラストレディアスを指数関数的に拡大させる点にある。人間がブラウザでWebアプリケーションのSSRFを突く場合、攻撃範囲は対象アプリケーションのネットワーク到達性に限定される。しかしAIエージェントは複数のMCPサーバーに同時接続し、ツールチェーンを自律的に構成する。一つのSSRFが引き金となり、ファイルシステムMCPサーバー経由でローカルファイルを読み取り、Git MCPサーバー経由でリポジトリを操作し──攻撃は水平方向に無制限に展開される可能性がある。

実際、2026年1月20日に同日公開されたCyataの研究では、Anthropic公式のGit MCPサーバーに3件の連鎖可能な脆弱性（CVE-2025-68143、CVE-2025-68144、CVE-2025-68145）が報告されている。パス検証バイパス、無制限のgit_init、git_diffへの引数インジェクションを組み合わせることで、悪意ある.git/configファイルを通じたRCE（リモートコード実行）が達成される。Microsoftのデータ変換ツールとAnthropicのバージョン管理ツール──異なるベンダーの異なる機能を持つMCPサーバーが、エージェントの自律的なツール選択を介して攻撃チェーンに組み込まれる。これは従来のサプライチェーン攻撃とは質的に異なる脅威モデルである。

セキュリティ戦略はビジネスの制約を理解した上でないと絵に描いた餅になる。MCPでも「全URIを制限する」正しい解は、「あらゆるリソースをAIに処理させたい」というMCPの存在意義と矛盾する。この設計レベルのトレードオフに対する明確な解答がエコシステム全体として存在しない。

サプライチェーン防御設計 ── MCPエコシステムに必要な多層防御アーキテクチャ

MCPサーバーのSSRF問題に対する防御は、単一のパッチやバリデーションの追加では解決しない。エコシステム全体での多層防御設計が必要である。以下に、テクノロジーの視点から具体的な防御レイヤーを提示する。

レイヤー1: ネットワークレベルの制約

MCPサーバーのアウトバウンドネットワークアクセスを最小権限原則に基づいて制限する。具体的には以下の対策を実装する。

  • プライベートIPレンジのブロック: 169.254.0.0/16（リンクローカル）、10.0.0.0/8、172.16.0.0/12、192.168.0.0/16への発信リクエストをネットワークレベルで遮断する
  • IMDSv2の強制: AWS環境ではIMDSv2をインスタンスレベルで必須化し、IMDSv1を完全に無効化する。HttpTokens=requiredの設定をOrganizations SCPで全アカウントに強制する
  • DNSリバインディング対策: MCPサーバーからの名前解決結果がプライベートIPに解決される場合、リクエストをブロックする

レイヤー2: MCP プロトコルレベルの認証と認可

現在のMCPプロトコル仕様には、ツール呼び出し単位の認可モデルが存在しない。認証があるサーバーでも、有効なAPIキーがあれば全ツールにアクセスできてしまう。必要なのは以下である。

  • ツール単位のスコープ制御: 各ツールに必要な権限スコープを定義し、接続クライアントのスコープに基づいてツール呼び出しを制御する
  • 入力スキーマの厳格な定義: convert_to_markdownのようなツールでは、許可するURIスキーム（例: https://のみ）とドメインのホワイトリストをツール定義に含める
  • レート制限と異常検知: ツール呼び出しの頻度、ターゲットURIのパターン、レスポンスサイズの異常を検知する

レイヤー3: エージェントランタイムのサンドボックス化

MCPサーバーをコンテナ化し、ネットワーク名前空間とファイルシステムの分離を強制する。具体的には以下が有効である。

  • gVisorやFirecrackerによるmicroVM隔離: MCPサーバーごとにカーネルレベルで分離し、横方向の攻撃展開を遮断する
  • 読み取り専用ファイルシステム: MCPサーバーの実行環境を不変（immutable）にし、永続化攻撃を防止する
  • Egress制御: 明示的に許可したエンドポイント以外へのアウトバウンド通信を遮断する

レイヤー4: サプライチェーン検証と組織ガバナンス

MCPサーバーの信頼性検証にはBlueRock SecurityのMCP Trust Registry（mcp-trust.com）のような仕組みが有効である。組織レベルでは、MCPサーバーのSBOM管理、パッケージの署名検証、AIエージェント統治のフレームワークに基づく定期的な脆弱性評価を実施すべきである。さらに、MCPサーバー導入の承認プロセスを策定し、ツールポイズニング検出（ツール記述への悪意ある指示の埋め込み検知）とインシデント対応計画の整備が不可欠である。

Microsoftの「低リスク」分類が示すセキュリティ認識のギャップ

本件で看過できないのが、Microsoftの対応である。BlueRock Securityの報告に対し、Microsoftは「通常の使用パターン外での意図的な悪用が必要であるため、重大なリスクにはならない」と分類した。この判断は、従来のソフトウェアセキュリティの文脈では一定の合理性がある──ユーザーが意図的に悪意あるURLを入力する必要があるからだ。

しかし、MCPの文脈ではこの前提が崩壊する。ツールの入力を決定するのは人間ではなくAIエージェントであり、そのエージェントの挙動はプロンプトインジェクションによって外部から操作可能である。「意図的な悪用」は人間のユーザーではなく、汚染されたコンテキストを持つエージェントによって自動的に行われる。Microsoftの分類は、AIエージェントが介在する新たな脅威モデルを評価基準に組み込んでいない。

この認識ギャップはMCPエコシステム全体に共通する。開発者の多くはツールが善意で使用される前提で設計しているが、エージェントの自律性が高まるほど「意図された使い方」と「実際に可能な使い方」の乖離は拡大する。セキュリティは意図ではなく能力に基づいて評価されるべきであり、この原則がMCPの文脈では特に重要となる。

CVE-2025-6514──437,000ダウンロードのmcp-remoteに存在するOSコマンドインジェクション──も同じ構造を持つ。悪意あるMCPサーバーが不正なauthorization_endpointでクライアントRCEを達成し、未パッチのインストールが事実上のサプライチェーンバックドアとなる。「低リスク」と判断された脆弱性の集積がエコシステム全体を瓦解させる──これがMCPのサプライチェーンリスクの本質である。

今後の展望 ── MCPセキュリティの制度化とゼロトラストの必然性

MCPは「AIのための万能コネクタ」として急速に普及しているが、そのセキュリティモデルは2000年代初頭のWebアプリケーションと同程度の成熟度に留まっている。36.7%のSSRF露出率、41%の無認証サーバー率──これらの数字は、プロトコルの成長速度とセキュリティの成熟速度の致命的な乖離を可視化している。

今後のMCPセキュリティの制度化には、以下の方向性が不可避である。

第一に、プロトコル仕様レベルでのセキュリティ必須化。現在のMCP仕様では認証・認可はオプションである。ツール定義に対する入力制約の標準化、SSRF対策としてのURL検証要件の仕様組み込み、ツール呼び出し監査ログの標準出力形式の定義が求められる。

第二に、MCPレジストリのセキュリティゲート。npmがSocket.devと統合して悪意あるパッケージを検出するように、MCPレジストリにも登録時のセキュリティスキャンと継続的な監視が必要である。BlueRock SecurityのMCP Trust Registryはこの方向性の先駆けであるが、エコシステム全体をカバーする公的なレジストリ基盤の構築が急務である。

第三に、AIエージェントに対するゼロトラスト原則の適用。エージェントが接続するMCPサーバーは全て「信頼できない」と仮定し、各ツール呼び出しに対して権限・入力・出力の検証を個別に実施する。インシデント対応の最前線で一秒の判断遅れが被害を指数関数的に拡大させることを経験してきた立場から言えば、MCPのような自律システムでは「信頼のデフォルト」は許容されない。

MCPが「AIの万能USBポート」であるなら、USBの歴史が示す教訓は明確である。USBもAutoRun悪用やBadUSB攻撃を経て、セキュリティの後付けがいかに困難かを証明した。36.7%という数字は、MCPがその轍を踏む猶予がすでに失われつつあることを示している。

FAQ

MCP SSRFとは何ですか？なぜ従来のSSRFより危険なのですか？

MCPサーバーにおけるSSRFは、AIエージェントがMCPツールを通じて任意のURLにサーバーサイドからリクエストを送信できる脆弱性である。従来のSSRFとの決定的な違いは攻撃の実行主体がAIエージェントである点にある。プロンプトインジェクションと連鎖することでエージェントが自律的にSSRFを実行し、人間の操作なしに攻撃が自動化・横展開される。

36.7%のMCPサーバーが脆弱という数字の根拠は？

BlueRock Securityが運営するMCP Trust Registry（mcp-trust.com）による、7,000超のMCPサーバーを対象としたセキュリティルールベースの分析結果である。SSRF関連の「Unrestricted Network Fetch」セキュリティ所見に該当するサーバーをフィルタリングした結果、36.7%が潜在的なSSRF脆弱性を抱えていると判定された。別の独立調査でも、公式レジストリの518サーバーのうち41%が認証を未実装であることが確認されている。

自社がMCPサーバーを使っている場合、すぐにできる対策は？

最も即効性のある対策は3つある。第一に、AWS環境ではIMDSv2を全インスタンスで強制し、IMDSv1を無効化する。第二に、MCPサーバーのアウトバウンドネットワークをプライベートIPレンジ（169.254.0.0/16、10.0.0.0/8等）に対してブロックする。第三に、使用中のMCPサーバーの認証設定を確認し、無認証のサーバーは即座に利用を停止するか、認証レイヤーを追加する。中長期的にはMCPサーバーをコンテナ化し、ネットワーク分離を徹底することが推奨される。

Microsoftはこの脆弱性を修正していますか？

2026年1月時点で、Microsoftはこの脆弱性を「通常の使用パターン外での意図的な悪用が必要」として低リスクに分類し、パッチを提供していない。しかし、MCPエージェントの文脈ではプロンプトインジェクションを通じた自動的な悪用が可能であり、BlueRock Securityはこの分類に異議を唱えている。ユーザー側での緩和策（ネットワーク制限、IMDSv2強制等）の実装が推奨される。

MCPのサプライチェーンリスクを評価するにはどうすればよいですか？

MCP Trust Registry（mcp-trust.com）で使用中サーバーのセキュリティスコアを確認し、各MCPサーバーのソースコードでネットワーク制約・入力バリデーション・認証メカニズムの有無を評価する。組織レベルではMCPサーバーの導入承認プロセスを策定し、SBOM管理とセキュリティレビューを必須化すべきである。

参考文献