MCPのセキュリティ事故｜AI連携サーバーが侵入口に、56プロジェクトに被害

何が起きたのか？

ウェブ制作会社向けのホスティング事業者 Mittwald で、顧客がAIアシスタントと管理画面をつなぐためのMCPサーバーに弱点があり、攻撃者に悪用されました^[2][4]。攻撃者は10月27日に弱点を突いてから11月4日に検知されるまで活動し、Mittwald は56件の顧客プロジェクトが侵害されたと公表しています^[1]。

Mittwald の管理画面「mStudio」は、Webサイトやホスティングのサービスを管理するための画面です^[4]。MCPサーバーを使うと、Claude や ChatGPT、Claude Code、GitHub Copilot、Cursor などのAIツールから、この管理画面の操作を言葉で指示できました^[3]。

1. 10月21日夜

   攻撃者が初めて弱点を試す

   PHPの脆弱性「PHP2Shell」の対応でIT業界全体が慌ただしかった時期に、攻撃者がMCPサーバーの弱点を初めて試した^[1]。

2. 10月23日〜

   普通の利用者を装って下調べ

   テスト用のアカウントを登録し、拡張機能を使い、簡単なインジェクション（不正な入力を紛れ込ませる攻撃）を試した^[1]。

3. 10月27日

   弱点を本格的に悪用

   14時58分に新しいアカウントを登録し、15時03分にMCPサーバーの弱点を狙って悪用した。Mittwald はこの日以降のデータをすべて侵害されたものとして扱っている^[1]。

4. 11月4日

   検知し、MCPサーバーを停止

   午前に異常な挙動を検知し、11時11分に攻撃者の最初のアカウントを停止。12時53分にステータスページを「調査中」にした。MCPサーバーを侵入口と特定して停止し、夜に管理画面を再開した。Webサイトは通常どおり表示されていた^[1]。

5. 11月5日

   ログインとSSHを止めて封じ込め

   痕跡のあるプロジェクトを停止し、新規アカウントの登録、管理画面へのログイン、SSH（サーバーへの遠隔接続）を一時停止した。外部の調査会社が支援し、当局にも報告した^[1]。

6. 11月6日

   56件を調査

   侵害された56件のプロジェクトとMCPサーバーを調べ、繰り返しの点検で追加の侵害は見つからなかったとしている^[1]。

7. 11月6日夜〜7日

   管理画面とSSHを再開し、経緯を公表

   6日夜から7日にかけて管理画面を、7日にSSHを再開し、パスキー（パスワードに代わる認証方式）を設定できるようにした。停止したWebサイトは当面停止したまま。MCPサーバーは停止を続けている^[1][2][3]。

Mittwald は、分析と復旧が終わりしだい、翌週に詳しい経緯を公表すると予告しています^[1]。弱点はMCPサーバーにあり、すでに塞いだと FAQ で説明しています^[2]。11月10日時点で編集部が確認したところ、詳しい報告はまだ出ていません。弱点の中身が Mittwald 自身のプログラムにあったのか、オープンソースのMCP関連ライブラリにあったのかも分かっていません^[4]。

MCPサーバーとは何か、なぜ狙われると影響が大きいのか？

MCPサーバーは、AIアシスタントと業務システムの間に立つ「通訳兼代理人」です。AIの指示を受けて、利用者の代わりに業務システムを操作します。代理で操作するために利用者のトークンを扱うので、ここが破られると、多くの利用者の通行証がまとめて危険にさらされるおそれがあります。

Mittwald のMCPサーバーへの接続には2つの方法がありました。1つはOAuth 2.1（ブラウザで本人がログインし、AIツールに与える権限を承認する方式）で、Mittwald はこちらを推奨していました。もう1つは、管理画面で発行したAPIトークンをAIツールに設定する方式で、自動処理向けとされていました^[3]。Claude と ChatGPT からは、各社の公式ディレクトリからワンクリックで導入できました^[3]。

導入の手軽さは、AIを業務につなぐ大きな利点です。一方で、Anthropic は自社のヘルプで、カスタムコネクタ（リモートのMCPサーバーで外部サービスにつなぐ機能）を追加すると、AIが利用者の権限に基づいて接続先のデータにアクセスし、場合によっては変更できるようになると説明しています。そのうえで、信頼できる組織が作り運営するサーバーにだけつなぐよう求めています^[9]。つなぐ前に、何をどこまで任せるのかを決めておく必要があります。

何が盗まれ、攻撃者は何ができたのか？

盗まれたのは、MCPサーバーを使っていた利用者のトークンです。パスワードは盗まれていません^[2]。ただし Mittwald によれば、トークンでは利用者と同じ権限で管理画面に入ることができ、攻撃者はその利用者が扱えるプロジェクトにアクセスできました^[2]。

発見までに時間がかかった理由について、Mittwald は、攻撃者が普通の利用者の行動に見える操作で下準備を偽装していたためと説明しています^[2]。攻撃者はアクセスを偽装し、陽動の操作も重ねていました^[1]。正規のアカウントと正規のトークンを使われると、外から見ると利用者本人の操作と区別がつきにくくなります。

MCPの仕様も、この点を危険として挙げています。クライアントが保存したトークンや、サーバー側にキャッシュ・記録されたトークンを盗まれると、攻撃者は正当に見えるリクエストで保護されたデータにアクセスできます^[7]。今回の弱点が具体的にどのような仕組みでトークンを読み取らせたのかは、公表されていません^[4]。

本当にAIを使った攻撃だったのか？

AIが使われた可能性はありますが、確かめられてはいません。Mittwald は、記録上の操作が非常に速く、人間なら時間がかかるはずの手順の間隔が数秒しかなかったことから「AIツールの使用をうかがわせる」としています^[1]。

一方で、この件を報じた The Record は、Mittwald がAIの関与について他の根拠を示していないと指摘しています。自動化された普通のスクリプトでも人間より速く動けるため、両者をどう見分けたのかを Mittwald に質問しましたが、すぐには回答がなかったと書いています^[4]。

AIが使われたかどうかで、利用者が取るべき対策は変わりません。攻撃が速くなると、侵入から被害までの時間が短くなります。そのため、被害の範囲をあらかじめ小さくしておくこと（権限を絞る、使っていない接続を切る）の重要性が増します。

日本企業にも関係があるのか？

Mittwald はドイツの事業者で、国内の利用者は多くないと考えられます。ただし、AIアシスタントを社内のSaaS、クラウド、開発環境にMCPでつなぐ使い方は、国内でも広がりつつあると編集部はみています。接続先の事業者が運営するMCPサーバーが破られたとき、何が起きうるかは使い方によって違います。

AIの接続は、社員が個人の判断で追加できることが多い点にも注意が必要です。OWASP（ソフトウェアのセキュリティに取り組む国際的な非営利団体）がまとめた「MCP Top 10」でも、組織のセキュリティ管理の外で、開発者などが試験や手軽さのために立ち上げたMCPサーバー（シャドーMCPサーバー）を、主要なリスクの1つに挙げています^[8]。編集部の見方では、社員が個人で追加した外部への接続も同じで、情報システム部門が知らない接続は、侵害が公表されたときに対処が漏れます。

AIをSaaSにつないでいる会社は、今週何をすればよいか？

まず「どのAIに、どのサービスを、誰の権限でつないでいるか」を一覧にしてください。一覧がなければ、接続先が侵害を公表しても、自社が対象かどうかすら判断できません。そのうえで、使っていない接続を切り、広すぎる権限を見直します。

AIツールに預けた認証情報の扱いは、MCPに限りません。Claude Code の許可設定ファイルにパスワードやキーが残る問題はClaude Code「今後確認しない」の落とし穴で、盗まれたAIのAPIキーが高額請求につながる問題はLLMjacking の解説で取り上げています。

接続先が侵害を公表したら、何をすればよいか？

Mittwald が対象の利用者に求めた手順が、そのまま参考になります。パスワードは盗まれていなくても、トークンで入られた先に残された「裏口」を探して消し、そこに保存していた他のサービスの認証情報も作り直すよう求めています^[2]。

1. 管理画面のパスワードを変更する^[2]
2. 二要素認証を有効にする^[2]
3. プロジェクト内のAPIキー、プロジェクト用トークン、SSH鍵を確認し、覚えのないものを削除する。自分で作っていないSSHユーザーに特に注意する^[2]
4. プロジェクトに保存していた他のサービス（データベース、メール、外部API）の認証情報を作り直す^[2]
5. プロジェクトを一緒に使っている利用者に知らせる^[2]

Mittwald は、10月27日以降にMCPサーバーを使った場合は、すべて侵害された可能性があるものとして扱うよう求めています^[2]。不審な兆候として、知らないSSHユーザー、プロジェクトのフォルダにある見覚えのないファイル、作った覚えのないAPIキーを挙げています^[2]。

国内のサービスで同じことが起きた場合も、考え方は同じです。トークンが失効されても、攻撃者が侵入中に作った別の鍵やアカウントが残っていれば、そこから再び入られます。「トークンは失効済み」という連絡を受けたら終わりではなく、侵入されていた期間に追加されたものがないかを自分で確認してください。

MCPサーバーを提供する側が見直す設計は？

自社のサービスにMCPサーバーを用意する会社は、MCPの仕様と OWASP の指摘に沿って設計を点検してください。中心になるのは、受け取るトークンの検証、権限の最小化、トークンの保管、記録の4点です^[5][6][7][8]。以下は一般的な設計の指針で、Mittwald の弱点の原因を示すものではありません。

Mittwald は、PHP2Shell の対応に追われていた時期に攻撃者が最初の試行をしていたと書いています^[1]。編集部の見方では、大きな脆弱性への対応に追われる時期は、監視も手薄になりやすいと考えられます。PHP2Shell そのものについてはPHP2Shell の解説を参照してください。

まとめ

Mittwald の事例は、AIアシスタントを業務システムにつなぐMCPサーバーが、実際に侵害の入口になりうることを示しました。盗まれたのはパスワードではなくトークンでしたが、トークンは利用者と同じ権限で使えるもので、Mittwald は56件の顧客プロジェクトが侵害されたと公表しています^[1][2]。AIが攻撃に使われたかどうかは Mittwald の推定にとどまり、弱点の中身もまだ公表されていません^[4]。

AIを社内のSaaSにつないでいる会社は、接続の一覧を作り、使っていない接続を切り、権限を読み取り中心に絞ってください。接続先が侵害を公表したら、トークンの失効を待つだけでなく、侵入されていた期間に追加された鍵やアカウントを確認します。MCPサーバーを提供する会社は、受け取るトークンの検証、権限の最小化、トークンの保管、記録の4点を点検してください。生成AIの利用に伴うリスクの全体像はAIセキュリティとはで整理しています。