調査により、Model Context Protocol（MCP）サーバーが、ユーザーが設定を変更していないにもかかわらず、異なるバージョンの依存関係を暗黙のうちに実行しうることが明らかになりました。AIアシスタントが特権的な認証情報を使ってこうしたサーバーを利用する場合、この挙動はサプライチェーンリスクを生みます。
ある管理者のワークステーションでは、1つのサーバーが同一のリリースとコミットに固定されていたにもかかわらず、5週間のうちに15種類の依存関係セットで動作していました。
これらの環境全体では、69個のパッケージのうち23個でバージョンが変化していました。侵害は確認されておらず、今回の調査で明らかになったのは、実際の攻撃ではなくインストール方法の弱点です。
この発見は、サーバー自体のバージョンを固定しても、そのサーバーが読み込むすべてが固定されるとは限らないという点を浮き彫りにしています。
このワークステーションのAIコーディングアシスタントは、Pythonパッケージをダウンロードして実行するツールuvxを介してMCPサーバーを起動していました。設定にはリリースタグ、パッケージの正確なバージョン、特定のGitコミットのいずれかが指定されており、インストール内容は固定されているように見えました。
しかし、このランチャーは環境を再構築する際、Python Package Indexから依存関係を解決していました。あるプロジェクトは7つの直接依存関係を固定し、ハッシュ固定のロックファイルも提供していましたが、この起動方法ではロックファイルが使われませんでした。
約60個の間接依存関係は、許容されたバージョン範囲に従って変動する状態のままでした。ランチャーは起動のたびにすべてをダウンロードするのではなく環境をキャッシュしていましたが、その後の再構築で新しいパッケージが取り込まれていました。
研究者らは、1つのリリースについて19回のビルドを確認し、そこから15種類の異なる環境が生まれていたことを突き止めました。変更は、暗号ライブラリ、JSON Web Tokenの処理、MCPソフトウェア開発キット（SDK）など、セキュリティ上重要なコンポーネントに及んでいました。
調査対象の35のMCPサーバーのうち、23は、起動時、インストール時、またはイメージビルド時に依存関係を新たに解決しうるインストール方法を推奨していました。
同様のリスクは、ローカルのMCPプロキシにlatestタグ付きのnpxを使うJavaScript環境でも見られました。こうした設定では、個別の承認手順を経ずに新しいリリースが取り込まれる可能性があります。
これはMCP自体の欠陥ではありません。インストールや起動方法の選択に起因する問題です。
危険性の源は、サーバーが持つアクセス権にあります。悪意ある依存関係のコードは、サーバーのトークン、ファイル、ネットワーク権限を引き継ぐ可能性があるためです。AIセッション中にサーバーが自動起動されるたびに、侵害されたパッケージに遭遇する機会が繰り返し生まれます。
調査チームは、DNSおよびTLSの記録とエンドポイントのテレメトリを組み合わせ、レジストリへの接続を特定したうえで、AIアシスタント、ランチャー、MCPサーバーまで遡って追跡しました。EDR（エンドポイントでの検知と対応）ツールを使えば、この突き合わせに必要なプロセス、ネットワーク、ファイルの各アクティビティを把握できます。
ただし、レジストリへの通信だけでは、コードが変更されたことの証明にはなりません。キャッシュを使うランチャーは、メタデータを確認しているだけの場合もあります。依存関係のドリフトを確認するには、インストール済みパッケージの一覧、キャッシュの内容、ファイルイベントが必要です。
Corelightは、ハッシュ検証済みの依存関係を専用環境にインストールし、ソースコミットを固定したうえで、インストール済みのプログラムを直接起動することで、5つのサーバーを固定しました。起動時の更新チェックも無効にしたと、Corelightは説明しています。
2週間にわたり、これらのサーバーは457回起動しましたが、記録されたパッケージ一覧に変化はありませんでした。いずれもMCPハンドシェイクを完了し、同じツールを公開していました。
ANY.RUNを導入し、脅威調査の効率化と手作業の削減を実現している1万6,000以上のSOCチームに加わりませんか。チーム向けに試してみる
翻訳元: https://cyberpress.org/mcp-changes-enable-attacks/
