外部公開された MCP サーバの最新動向：脅威はクラウドへと拡大

2025年7月に公開した「公開状態のMCPサーバが機密データのバックドアとして悪用されるリスク」では、外部公開された MCP サーバに潜むセキュリティリスクを初めて指摘しました。当初の調査では、クライアント認証も通信の暗号化もない、基本的なセキュリティ制御を一切備えないインスタンスが492件確認されました。これらのサーバは AI エージェントの汎用コネクタとして設計されたものでありながら、企業の機密データへの開かれた入口と化しており、看過できない事態でした。

それから数か月後、状況は悪化するにとどまらず、クラウドセキュリティに対する重大な脅威へと進化しています。最新の調査では、外部公開された MCP サーバの数はほぼ3倍に増え、1,467件に達しました。さらに憂慮すべきは、これらのサーバがクラウドインフラを直接狙う強力な攻撃経路になりつつあることです。攻撃者はもはや MCP サーバに紐づくデータへのアクセスにとどまらず、それらをホストするクラウドサービスそのものを侵害できるようになっています。

本記事では最新の調査結果を報告するとともに、MCP の悪用における新たな領域であるクラウドに焦点を当てます。クラウド向け MCP 実装に最近確認された脆弱性を取り上げ、実際の攻撃シナリオを分析したうえで、深刻化するこの脅威から身を守るための推奨事項を組織向けに示します。

主要な調査結果：数字が示す現実

最新スキャンの結果は、MCP セキュリティの厳しい現状を浮き彫りにしています。公開サーバ数は3倍に膨れ上がり、機密データや重要インフラがリスクにさらされています。

外部公開された MCP サーバ：1,467件：当初調査からほぼ3倍に増加しており、MCP の安全性を欠いた急速な導入が進んでいることを示しています。
レガシー Server-Sent Events（SSE）サーバ：1,227件：公開サーバの大半が、すでに長く非推奨とされている SSE トランスポートを使用しており、より安全な最新の MCP 実装への移行が広く進んでいない状況がうかがえます。
データベースの危機：「execute_sql」ツールが70台のホストで確認されました。データベースクエリを実行するこの代表的なツールにより、MCP サーバは機密データへの開かれた裏口と化します。
「Graphiti Agent Memory」：39台のホストで確認されたこのエージェント型 MCP サーバ実装は、メモリ上のデータを窃取しようとする攻撃者にとって格好の標的です。
患者データの危機：少なくとも3台の MCP サーバが「progress_note」機能を使って患者の医療記録にアクセスしています。これらが侵害されれば、明確なプライバシー規制違反となるとともに、安全性を欠いた MCP 展開がもたらす現実の帰結を強く突きつけることになります。

MCP を介したクラウドインフラの侵害

MCP サーバが非常に広く普及している現状を踏まえると、クラウドサービスとの連携を目的に設計された MCP サーバが数多く存在するのは当然と言えます。本調査では、Azure および AWS 向けの非公式な MCP サーバ2種類で、複数の重大な脆弱性が明らかになりました。これらの脆弱性は、Zero Day Initiative（ZDI）を通じて該当ベンダーに開示済みです。概要は脅威の深刻度を端的に示しています。

これらの脆弱性は いずれも CVSS スコア 9.8 であり、攻撃者がセキュリティ制御を回避し、クラウド環境内で不正なコマンドを実行することを可能にします。つまり、侵害された MCP サーバは、本格的なクラウド侵害の出発点になり得るということです。

クラウド MCP 攻撃の構造

こうした攻撃は実際にはどのように行われるのでしょうか。その攻撃チェーンは、しばしば驚くほど単純でありながら、破壊的なまでに有効です。

発見：攻撃者はネットワークをスキャンして外部公開された MCP サーバを探します。 1.1 発見後、攻撃者は当該 MCP サーバが認証や認可を実装しているかを評価します。 1.2 次に、アクセスのレベルを評価します。リモート MCP サーバはきめ細かな権限制御を備えていることがあり、特定のデータやサービスにのみアクセスを許可する場合があります。
悪用：続いて、本調査で開示したような脆弱性を悪用し、サーバへの初期アクセスを獲得します。
認証情報の窃取：内部に侵入すると、平文の設定ファイルにハードコードされたクラウド認証情報や Application Programming Interface（API）キー、その他のシークレットが見つかることが少なくありません。
ラテラルムーブメント：取得した認証情報を武器に、攻撃者はクラウド環境内を横方向に移動し、他のサービスやデータベース、機密データにアクセスします。
クラウド全体の侵害：最悪のシナリオでは、攻撃者はそのアクセス権を悪用してクラウドアカウントを完全に掌握し、データ侵害、金銭的損失、レピュテーションへの打撃を招きます。

クラウド向け MCP サーバで特定した脆弱性はもはや理論上の存在ではなく、攻撃者がクラウド環境を狙い、侵害する手口の根本的な変化を示しています。続いて、いくつかの具体的な攻撃経路を詳しく見ていきます。

ハードコードされたクラウド認証情報の悪用

本調査で確認した中でもとりわけ多く、危険なセキュリティ上の欠陥の一つは、クラウド認証情報を MCP サーバの設定ファイルに直接ハードコードする手法です。19,000件超の MCP サーバのソースコードを分析した結果、その半数近く（48%）が、安全性に欠ける .env ファイルや平文の JSON 構成にシークレットを保管することを推奨していました。これはデジタル世界における「玄関マットの下に城の鍵を置いておく」行為に等しいと言えます。

認証情報がハードコードされた MCP サーバへのアクセスを攻撃者が獲得すれば、その先に広がるクラウドプロバイダー API へ直結する経路を手にすることになります。これにより、以下のような幅広い悪意ある行為が可能になります。

データの窃取：Amazon S3 や Azure Blob Storage などのクラウドストレージから機密データへアクセスし、ダウンロードします。
リソースの乗っ取り：暗号通貨マイニングなどの不正な目的のために、高額なクラウドリソースを起動します。
インフラの破壊行為：仮想マシンやデータベース、ネットワーク構成といった重要なクラウドインフラを削除・改変します。

クラウドにおけるコマンドインジェクション

本調査で発見した「aws-mcp-server」および「azure-mcp-server」のコマンドインジェクション脆弱性は、とりわけ危険です。これらの欠陥により、攻撃者はホスト上で任意のコマンドを実行できます。クラウド環境では、このホストはクラウドプロバイダーの API に対する特権アクセスを持つ仮想マシンやコンテナであることが多く、結果としてコンテナのブレイクアウトや仮想マシン（VM）エスケープにつながり得ます。攻撃者はホストおよびそのアクセス権が及ぶ他のリソースを完全に掌握することになります。

無制限なネットワークアクセスの危険性

クラウド環境におけるツールポイズニング

ツールポイズニングは、悪意ある MCP サーバが偽のツール記述や改ざんされた応答を提供する攻撃で、クラウドにおいて新たな様相を帯びます。たとえば攻撃者は、「aws-cli」や「az-cli」といったツールに細工を加え、正規のユーザがクラウド環境を操作するたびに密かにデータを窃取したり悪意あるコマンドを実行したりする可能性があります。検出が極めて難しい、巧妙で陰湿な攻撃です。

組織が今すべきこと：クラウドを軸とした防御

MCP の悪用がクラウドへ移行している以上、防御戦略も同様に転換が求められます。最初の記事で示した推奨事項は依然として有効ですが、クラウド特有のセキュリティ制御という新たな層を加える必要があります。組織が今直ちに取り組むべき事項は以下のとおりです。

MCP サーバをクラウドインフラの重要構成要素として扱う MCP サーバはもはや単なる実験的ツールではなく、クラウドインフラの重要な構成要素であり、それにふさわしい扱いが求められます。すなわち、他の本番サービスと同等の厳格なセキュリティ基準を適用することを意味します。
1. セキュア・バイ・デザイン：開発から本番運用までの MCP 導入ライフサイクル全体にセキュリティを組み込みます
2. 変更管理：すべての MCP サーバ構成に対し、正式な変更管理プロセスを導入します
3. 定期的な監査：MCP サーバとその構成について、定期的なセキュリティ監査を実施します
クラウドネイティブなシークレット管理でハードコードされた認証情報を排除する MCP サーバの構成に認証情報をハードコードする運用は、時限爆弾を抱えているのと同じです。組織は直ちに、利用しているクラウドプロバイダーのネイティブ機能を活用した、より安全なシークレット管理戦略へ移行する必要があります。
1. AWS：AWS Secrets Manager または AWS Systems Manager Parameter Store を使用してシークレットを保管・管理します
2. Azure：Azure Key Vault を使用してシークレットを安全に保管・参照します
3. Google Cloud Platform（GCP）：Google Cloud Secret Manager を使用してシークレットを管理し、アクセスを制御します

これらのサービスを利用することで、MCP サーバが平文の認証情報に直接アクセスすることを防げます。代わりに、必要なときにシークレットを取得できる Identity and Access Management（IAM）ロールを付与し、完全な監査とアクセス制御を確保できます。

厳格なネットワークセグメンテーションと公開状況の管理を徹底する 外部公開された MCP サーバは、攻撃者への招待状そのものです。組織は厳格なネットワークセグメンテーションと公開状況の管理を実装し、MCP のアタックサーフェスを大幅に削減しなければなりません。
1. デフォルトはプライベート：MCP サーバはデフォルトでプライベートサブネットに配置し、パブリック IP アドレスを付与しません
2. 最小権限のネットワークアクセス：セキュリティグループとネットワーク Access Control List（ACL）を活用し、インバウンドおよびアウトバウンドの通信を必要最小限に制限します
3. リバースプロキシと API ゲートウェイ：インターネットに公開する MCP サーバに対し、リバースプロキシや API ゲートウェイを使って認証・認可・ログ記録の追加レイヤーを設けます
堅牢な認証・認可・監査を実装する 多くの MCP サーバが既定で開放状態にある現状は、重大なセキュリティリスクです。組織はすべての MCP インターフェースに対し、強力な認証・認可・監査を強制する必要があります。
1. OAuth 2.0：すべての MCP クライアント認証に OAuth 2.0 を実装し、すべてのアクセスを特定のユーザ ID に紐づけます
2. Role-Based Access Control（RBAC）：MCP ツールに対して細かなロールと権限を定義し、ユーザが業務に必要なツールやデータにのみアクセスできるようにします。
3. 包括的な監査：MCP ツール呼び出しはすべてログに記録します（ユーザ、ツール、パラメータ、結果を含む）。不審な活動の検出と調査に不可欠です
MCP サーバをコンテナ化し隔離する MCP サーバを隔離されたコンテナで実行することは、侵害時の影響範囲を限定する有効な手段です。コンテナ化によって、以下が実現できます。
1. ファイルシステムアクセスの制限：サーバによるホストファイルシステムへのアクセスを制限し、機密ファイルへのアクセスを防止します
2. ネットワークアクセスの制限：コンテナのネットワークポリシーを利用し、サーバがアクセスできるネットワークリソースを制御します
3. リソース制限の適用：サーバの CPU およびメモリ使用量を制限し、ホスト上の他サービスへの影響を防ぎますDocker の MCP Toolkit などの同種のソリューションは、安全でコンテナ化された MCP アーキテクチャを構築するうえで良い出発点となります。

結論：MCP セキュリティの新たな戦場はクラウド

MCP サーバが安全性を欠いたまま急速に普及した結果、組織にとって新たで危険なアタックサーフェスが生まれました。当初はデータ漏洩への懸念にすぎなかったものが、いまではクラウドインフラに対する全面的な脅威へと拡大しています。本調査によれば、外部公開されたサーバの数はほぼ3倍に増え、攻撃者はクラウド向け MCP 実装を積極的に狙い、重要なリソースの制御権を奪おうとしています。

MCP の利便性は、多くの組織を誤った安心感へと導いてきました。実際には、適切な防御策を講じなければ、これらのサーバはデータへのバックドアにとどまらず、クラウド環境全体への入口となります。本調査で発見した AWS および Azure 向け MCP サーバの脆弱性が、認証情報をハードコードする慣行の蔓延と組み合わさることで、壊滅的な侵害を引き起こす条件がそろってしまいます。

組織は MCP の運用を保護するため、今すぐ行動する必要があります。そのためには、MCP サーバをクラウドインフラの重要構成要素として捉え、他の本番サービスと同等の厳格なセキュリティ基準を適用するという、根本的な意識転換が求められます。クラウドネイティブなシークレット管理を採用し、厳格なネットワーク制御を徹底し、堅牢な認証・認可を実装し、さらに MCP サーバをコンテナ化することで、組織はこの危険なセキュリティギャップの解消に着手できます。脅威は現実のものであり、賭けは大きく、行動すべき時はまさに今です。

付録

本付録では、各種のクラウド攻撃経路をより技術的に詳しく解説します。

ハードコードされた認証情報：ケーススタディ

開発者が、Amazon RDS 上の本番データベースにアクセスするよう MCP サーバを構成したケースを考えます。よくあるものの安全性に欠ける慣行に従って、データベースの認証情報を MCP サーバの設定ファイルに直接記述したとします。

{ 
  "mcp\_server": { 
  "tools": \[ 
  { "name": "production\_db\_query", 
  "description": "Query the production database", 
  "type": "sql", 
  "connection\_string": "postgresql://user:password@prod-rds-instance.random-chars.us-east-1.rds.amazonaws.com:5432/production\_db"
    } 
    \] 
  }
}

外部公開されたこの MCP サーバを発見した攻撃者は、自然言語でデータベースにクエリを発行できるばかりか、ユーザ名とパスワードを含む接続文字列全体を抜き取ることもできます。これらの認証情報を手にすれば、世界中のどこからでも RDS インスタンスへ接続でき、アプリケーション層のあらゆるセキュリティ制御を回避できます。データベース全体をダンプし、レコードを改変・削除し、計り知れない損害を与えることが可能です。これは高度な攻撃ではなく、安全性に欠けたデフォルト設定によって成立する、ありふれた認証情報の窃取の事例にすぎません。

コマンドインジェクション：クラウドサーバからクラウドアカウントへ

本調査で発見した「aws-mcp-server」および「azure-mcp-server」のコマンドインジェクション脆弱性は、とりわけ陰湿です。EC2 インスタンス上で動作する「aws-mcp-server」に、他の AWS リソースを管理する広範な権限を付与する IAM ロールが割り当てられているケースを想定します。このサーバのコマンドインジェクション脆弱性を悪用した攻撃者は、その EC2 インスタンスとしてコマンドを実行できます。これにより、攻撃者は次のことが可能になります。

IAM 認証情報の窃取：攻撃者は、以下のURLのEC2 メタデータサービスに問い合わせ、IAM ロールに紐づく一時認証情報を窃取できます。

http://169.254.169.254/latest/meta-data/iam/security-credentials/

他の AWS サービスへのアクセス：これらの認証情報があれば、AWS CLI や API を用いて、IAM ロールがアクセス可能なあらゆる AWS サービスを操作できます。対象は S3、DynamoDB、Lambda などに及び得ます。

永続化の確立：攻撃者は新たな IAM ユーザの作成、セキュリティグループの改変、新規 EC2 インスタンスの起動によって、環境内に足場を維持できます。

このシナリオでは、MCP サーバの単一の脆弱性が、クラウドアカウントの全面侵害へとエスカレートしています。MCP サーバは攻撃者にとって踏み台となり、横方向への移動とクラウド環境全体の掌握を可能にしてしまいます。

ツールポイズニング：見えにくい裏切り

クラウドにおけるツールポイズニングは、極めて目立たず効果的な攻撃となり得ます。Kubernetes クラスタを管理するツールを提供する MCP サーバがあると仮定します。正規のユーザは AI エージェントに「最新版の Web アプリケーションを本番クラスタにデプロイして」と依頼するかもしれません。AI エージェントは、その MCP サーバが提供する「kubectl」ツールを使ってデプロイを実行します。

しかし、悪意ある MCP サーバはこのツールに細工を仕込むことができます。AI エージェントが kubectl ツールを呼び出した際、MCP サーバはデプロイに悪意あるサイドカーコンテナを密かに追加できます。このサイドカーは、データの窃取、クラスタ内の他サービスへの攻撃、さらにはサービス拒否攻撃の起点として悪用され得ます。ユーザは、自身の正当な依頼が悪意ある行為のために乗っ取られていることにまったく気づきません。これがツールポイズニングの危険性です。すなわち、自らのツールを自らに刃向ける形に変えてしまうのです。

参考記事

Update on Exposed MCP Servers: The Threat Widens to the Cloud

By Alfredo Oliveira（Senior Threat Researcher, TrendAI™ Research）、David Fiser（Senior Threat Researcher, TrendAI™ Research）

翻訳：与那城務（Platform Marketing, Trend Micro™ Research）