11月3日、Help Net Securityが「AI coding agents are installing MCP servers that will never be patched」と題した記事を公開した。AIコーディングエージェントが廃止済みのMCPサーバーを自動インストールし続け、高深刻度の脆弱性4件にパッチが一切提供されないまま、2025年7月以降に1,730万回以上ダウンロードされているという深刻なセキュリティ問題の調査報告だ。発見者のGlow Labsはこの現象を「MCPhantom」と名付けている。
AIエージェントは「廃止済み」を読まない
開発者がAIコーディングエージェントに「GitHub MCPをセットアップして」と指示すると、エージェントは自分でパッケージを選ぶ。ここで言うMCP（Model Context Protocol）とは、AIモデルが外部ツールやデータソースと連携するためのプロトコルであり、MCPサーバーはその接続先となるコンポーネントだ。Glow Labsの調査によると、実際のAIコーディングセッションのトランスクリプトを分析したところ、エージェントがアーカイブ済みリポジトリ（今後パッチが一切提供されない）からMCPサーバーをインストールするケースが確認された。
問題の核心は、エージェントがパッケージ名をモデルのトレーニングデータから補完している点だ。調査対象のセッション（廃止済みサーバーがインストールまたは提案されたもの）の**98%**で、エージェントは古いパッケージ名をトレーニングデータから引っ張ってきていた。残り2%はユーザー自身が旧パッケージを名指しで要求したケースだ。
GitHubは公式のMCPサーバーを提供しているが、Glow Labsが記録した事例では、エージェントはその公式サーバーを素通りし、トレーニングデータにあるAnthropicの旧リファレンスサーバーを選択した。該当リポジトリはアーカイブ済みで「セキュリティアップデートは提供しない」と明記されているが、エージェントはアーカイブ通知を読まない。
この現象はClaude Code、Cursor、Codex CLI、Claude Chat（※編集部注：元記事に記載の製品名を原文に即して表記。「Claude Cowork」等の表記が元記事にある場合は原文を参照されたい）で確認されており、Anthropic・OpenAI・xAIのモデルにまたがって発生している。
4つの高深刻度脆弱性、パッチはゼロ
これらの旧リファレンスサーバーには高深刻度の脆弱性が4件存在する。最も深刻なのは、Puppeteerサーバーにおけるリモートコード実行（RCE）バグだ。
Puppeteerサーバーはエージェントがブラウザを操作するためのものだが、プロンプトインジェクション一発でブラウザ以外の任意のプロセスを起動し、攻撃者が選んだコマンドを実行できる。開発者が承認したのは「Webブラウジング」という一つの権限だが、その権限がそのまま拡張されて悪用される構造だ。
Glow Labsはこの脆弱性を報告したが、メンテナ側から「リポジトリは2025年5月にアーカイブ済みで無メンテナンス状態のためスコープ外」として対応を断られた。npmパッケージを「deprecated」としてマーキングすることは検討するとしたが、deprecatedパッケージはnpx経由で依然としてインストール可能だ。現時点で悪用の報告はないものの、パッチも来ない。
使用実態は廃止通知と完全にずれている。Glow Labsが調査した廃止済みパッケージは、2025年7月以降にnpmから1,730万回以上ダウンロードされており、5つがnpmのMCPカテゴリ上位100に入っている。
既存のセキュリティツールがなぜ沈黙するか
この問題がやっかいなのは、既存のセキュリティ管理が機能しない構造にある点だ。
- EDR：信頼済みのNode.jsプロセスが公開npmパッケージをインストールしているだけに見えるため、通常の操作と区別がつかない
- SCA（ソフトウェアコンポジション解析）：サーバーはnpx経由で動作するためマニフェストファイルが存在せず、脆弱性にはCVEも付番されていない
- ソフトウェアインベントリ：アプリケーションとして登録されないため、エンドポイント上にしか痕跡が残らない
「インストール前にエージェントに調べさせればいい」という対策も通じない。GlowのVulnerability ResearcherであるNadav Cohen（※編集部注：元記事の表記を原文に即して確認されたい）は次のように述べている。
「あるセッションでエージェントはnpm上でパッケージを確認し、『このパッケージはdeprecatedです』という結果を得ていた。それでもエージェントはパッケージをインストールし、ユーザーには何も伝えなかった。」
エージェントは廃止情報を「取得」できても、それをインストール判断に反映しない。検索と行動が切り離されているという、現行エージェントアーキテクチャ固有の問題だ。
誰が直せるのか、4つの担い手とその現実
Cohenは修正の担い手として4者を挙げているが、それぞれに制約がある点が重要だ。
- ハーネス（エージェント実行環境）メーカー：廃止済みサーバーを拒否または警告する仕組みを導入できる。ただし「全ハーネスが対応しなければ穴が残る」という構造的な限界がある
- モデルメーカー：古いパッケージ名をモデルの知識から更新できる。しかし「モデルの重みの更新はコストが高く、実現は難しい」とCohenは指摘する
- パッケージオーナー：脆弱性を直接修正できる唯一の主体であり、「旧サーバーを使い続けているユーザーを守れる唯一の方法」とされる。だが今回のケースのように、メンテナが対応を拒否すれば手詰まりになる
- セキュリティ企業：多くのハーネスがすでにサポートしている実行前フックを活用できる。「ハーネスメーカー、モデルメーカー、パッケージオーナーを待たずに今日から使える」という点で、現時点では最も即効性が高い選択肢だ
4者のうち3者が「難しい」「条件付き」という状況であり、セキュリティ企業による実行前フックが当面の現実解となっている。
npmからパッケージを削除するという手段は現実的ではない。npmの削除ポリシーでは、過去1週間のダウンロードが300件未満、オーナーが1人、公開の依存先なし、という条件が必要だ。対象のserver-githubは先週だけで185,239回ダウンロードされており、オーナーは6人いる。
Glow VP of R&DのOphir Arieはこう語っている。
「モデルのメモリが、deprecationフィードのないパッケージマネージャーになってしまっている。」
セキュリティチームへの当面の対策として、Glow Labsは廃止済みの@modelcontextprotocolサーバーを参照しているMCP設定を探し出して公式サーバーへの切り替えを進めること、サービスごとに承認サーバーを1つに絞ること、承認基準にnpmのdeprecation状態を追加することを推奨している。
詳細はAI coding agents are installing MCP servers that will never be patchedを参照していただきたい。
