Critical MCP Server Enables Arbitrary Code Execution and Sensitive Data Exfiltration
2026/02/19 gbhackers — MCP サーバは、AI アシスタントを強力な攻撃基盤へと、静かに変質させるものでもある。それにより、任意のコード実行／大規模なデータ流出や、ローカル／クラウド環境における巧妙なユーザー操作が可能になってしまう。新たな研究の結果だけではなく、最近の実際のインシデントにおいても、この新たなエコシステムの悪用が示されている。典型的なインシデントとしては、週に数千件の機密メールを密かに収集していた、悪意の Postmark MCP サーバが挙げられる。
MCP サーバは、モデルと各種システムの間に位置し、自然言語によるリクエストをファイル読み取り／API クエリ／データ改変といった具体的な操作へ変換する。
このアーキテクチャによりシームレスな相互運用性が実現されるが、攻撃者たちによるコード実行／データ窃取や、コンテキスト汚染に至る Machine‑in‑the‑Middle 攻撃も引き起こされる。
通常、MCP サーバは 2 つの主要コンフィグ (構成)で動作し、それぞれが異なるリスクを伴う。ローカル・ホスト型 MCP サーバは、ユーザー端末上のプロセスとして実行され、AI クライアントと同等の権限を持つ。そのため侵害されたサーバは、悪意を持ってファイル／認証情報／OS などへ直接アクセスすることが可能になる。
その一方で、メール／チャット／ストレージなどのプロバイダが提供するリモートホスト型の MCP サーバは、OS レベルのコマンドを直接実行できない。しかし、企業内の高価値データや業務システムの強力な機能へのアクセスは可能である。
Model Context Protocol (MCP) は、2024年後半に Anthropic により導入されたものだ。それにより、外部ツール／ローカルリソース／SaaS プラットフォームへと、AI アシスタントが接続する方法が標準化される。
正規のリモート・サーバと悪意のローカル MCP を連鎖させる攻撃者は、企業データへのアクセスとローカル・コード実行を、単一かつ不透明なワークフロー内で結合できる。
AI エージェントは、有用性を確立するために自動的にツールを呼び出す。それにより、特にツールが “Always Allow” に設定されている場合には、ユーザーによる可視性が皆無と言って良い状況で、多くの操作が実行されていく。
MCP サーバの脆弱性
Praetorian の MCPHammer などのセキュリティ検証フレームワークが示すのは、複数のエージェント／モデル／クライアントにまたがる形で、MCP ツール・チェーンを容易に悪用できる状況にあることだ。
重要な攻撃ベクターには、サードパーティ MCP サーバの連鎖である。悪意のローカルサーバが無害な生産性ツールを装い、Slack などの信頼されたプラットフォーム内に埋め込まれたコマンドを、密かに復号して実行するシナリオである。
それにより、AI アシスタントが公式 Slack MCP を通じてワークスペース・メッセージを取得し、それを悪意の分析ツールへ転送する。その結果として、ユーザーの明示的な指示なしに実行されるものとして、アプリケーション起動／シェルコマンド実行／マルウェア展開ペイロードなどが挙げられる。
この Machine‑in‑the‑Middle のポジションから、体系的データ流出も可能になってしまう。攻撃者たちは、ツールの説明を細工し、追加のコンテキストやメッセージの取得を促す。それにより AI は、ダイレクトメッセージ／文書／チケット／ソースコードなどの大規模データを繰り返して取得し、それらを悪意の MCP ツールに転送させる。
最近の、悪意の MCP サーバに関する研究が示すのは、偵察や認証情報窃取／データ流出を実行しながらも、ユーザーに不審を抱かせないレスポンスを返すことが可能になっている点だ。単一の悪意のサーバが、パスワード・リセット情報や、請求書／社内通信などに関連するすべてのメールを密かに複製できることを、バックドア化された “postmark-mcp” パッケージが示している。
MCP エコシステムの悪用は、インタラクティブ攻撃のレベルを超え、サプライチェーン・リスクも拡大させている。
多くの MCP クライアントは、”uv／uvx／npm” などのパッケージ・マネージャを使用し、コンフィグ・ファイルから動的にサーバをインストールして実行する。そのため、タイポスクワッティングやライブラリ侵害が生じると、エージェント起動時に任意のコードが実行され得る。
さらに、MCP 対応マルウェアは、プロンプト・インジェクションやコンテンツ操作を通じて、技術的な侵害とソーシャル・エンジニアリング攻撃を結合できる。MCP サーバには、Slack ボット・トークンがハードコードされている。それを悪用する攻撃者は、書き込みとファイル・アップロードの権限をコンフィグすることでワークスペースを制御し、収集したデータを JSON ファイルに格納して、自身の Slack チャネルへ送信できる。
具体的に言うと、正規のレスポンス内に、偽の IT サポート指示／攻撃者管理の電話番号／短縮フィッシング URL などを埋め込むことで、悪意の MCP サーバによる誘導が開始され、ユーザーは認証情報窃取／ボイスフィッシング／ウォータリングホール攻撃などに遭遇する。
なぜ MCP 攻撃は発見が困難なのか
MCP ベースの攻撃は、複数層の信頼を悪用するものだ。ユーザーは、Slack やメールなど公式コネクタを信頼し、組織は人気 MCP パッケージを信頼する。そしてクライアントは “Read-Only” ツールを安全とみなし、Always Allow に設定することが多い。
最も単純な攻撃は、クエリの傍受である。たとえば、hello world スクリプトを加工して、LLM とのリクエスト／レスポンスの交換をログに残すことが可能だ。
現実的に見て、MCP サーバをインストールすることは、コード実行および機密データ操作に関するユーザーの権限を、それらに付与することに等しい。しかし多くの企業は、それらを正式な資産として管理せず、ベンダーリスク評価も実施していない。
MCP 対応 AI アシスタントを導入している組織は、新規 MCP サーバに対して厳格なレビューと承認プロセスを適用することで、リスクを低減すべきである。すべてのサーバをデフォルトで未信頼コードとみなし、Always Allow 権限を最小限に制限すべきである。
セキュリティ・チームにとって必要なことは、AI クライアントと外部サービス間の異常なデータフローを監視し、MCP パッケージ自動インストール設定を監査し、ツール連鎖呼び出しやプロンプト駆動実行経路について開発者を教育すべきである。
社内の MCP サーバを、CI／CD パイプラインがホストし始めると、ビルド・システム侵害やトークン窃取といった既存サプライチェーン脅威が、悪意の MCP ツール注入へ転用され得る。
MCP の強みは、AI モデルと豊富なデータおよび操作面を橋渡しする能力にある。しかし、その特性を厳格に制御しない限り、従来の信頼境界は容易に侵食される。
すでに、現実世界での悪用が確認され、コア MCP ツール群に重大な RCE 脆弱性が出現している以上、防御側は MCP サーバを第一級の攻撃面とみなすべきである。そして、ブラウザ、IDE、CI／CD システムと同等の強度で、検証／堅牢化／監視を開始すべきである。
この問題の背景にあるのは、AI モデルとローカル／クラウド資源の間で高権限ブリッジとして動作する、MCP サーバのデザインです。ローカル型では OS やファイルへ直接アクセスが可能であり、リモート型でも Slack やメールなど高価値データへの到達が可能です。さらにパッケージ・マネージャ経由で動的にインストールされるため、悪意のサーバやタイポスクワッティングが成立すると、任意コード実行や大規模データ流出につながります。Always Allow 設定や信頼境界の未整理が、Machine-in-the-Middle 的な悪用を容易にしています。よろしければ、MCP での検索結果も、ご参照ください。
IoT OT Security News 
You must be logged in to post a comment.