2026年に入り、AIエージェント統合の攻撃面は「モデル本体」ではなく「接続基盤」へ急速に移動している。象徴的なのが、MCP（Model Context Protocol）サーバー群を標的にしたサプライチェーン攻撃である。OX SecurityはMCPエコシステム内で約200,000の脆弱性インスタンスを観測したと公表し、Claude Code関連ではCVE-2025-59536（報告CVSS 8.7）を含むRCE連鎖が議論された。本稿は、2025年後半から2026年前半に表面化したMCPサーバー攻撃の構造を技術的に分解し、Cursor・Windsurf・Gemini CLIを含む横断的リスクと多層防御の実装手順を提示する。

なぜMCP Serverが「新しい依存性地雷」になったのか

MCPは2024年11月25日にAnthropicが公開したオープン仕様であり、LLMが外部ツールを呼び出す共通インターフェースを提供する。設計上の利点は高い一方、実運用では「任意サーバーを容易に接続できる」特性が、パッケージ配布層（npm/PyPI）と構成層（hooks・設定ファイル）を同時に攻撃面へ変換する。すなわち、従来の依存性管理がコード中心だったのに対し、MCP時代は“実行時接続先そのもの”が依存性として振る舞う。

OX Securityは、公開MCPサーバー実装群における脆弱状態の総量を「約200,000インスタンス」と警告し、さらに悪性パッケージ連鎖の総ダウンロード規模が1.5億超に達し得るとした。これらの数値はベンダー調査値であり、母集団定義や期間に依存するため絶対値よりも傾向として解釈すべきである。しかし、少なくとも「MCPサーバーを起点にしたサプライチェーン化」が実在フェーズに入ったことは、複数の研究機関報告と整合する。

Claude Code RCE連鎖: CVE-2025-59536とHooks構成インジェクション

Check Point Researchが公開した分析では、Claude Codeのフック機構と外部ツール連携を悪用し、プロンプト注入からローカルコマンド実行へ遷移する攻撃シナリオが提示された。CVE-2025-59536はこの文脈で参照され、CVSS 8.7（報告値）として扱われることが多い。重要なのはCVE番号自体より、以下の4段階遷移である。

第1段階は悪性MCPサーバーまたは改ざんパッケージの導入、第2段階は`preToolUse`/`postToolUse`相当のフック設定へ不正ペイロード混入、第3段階は開発者の通常操作に擬態したコマンド実行、第4段階はOAuthトークンやCLI認証情報の窃取である。これにより、単一端末の侵害がコードホスティング、CI、社内SaaSへ水平展開しやすくなる。

加えて、MCPサーバー経由のツール呼び出しは「AIが提案した正当処理」に見えやすく、監査ログで人間操作と識別しづらい。ここが従来の悪性npm依存攻撃より検知を難しくする構造的欠陥である。

npm/PyPI軽量レビューでは防げない理由と横断影響

多くの組織はnpm/PyPIパッケージに対し、README確認とスター数評価の軽量レビューで導入可否を決める。しかしMCPサーバー系では、公開後の小規模更新で実行経路が変わる、外部URLから設定を動的読込する、post-installやフック記述で挙動が分岐する、という特徴があり、静的レビューだけでは不十分である。

影響は特定ベンダーに閉じない。CursorやWindsurfのようなAI IDE、Gemini CLIのようなエージェントCLI、さらに社内独自エージェント基盤が、いずれも「外部ツール接続」「ローカル実行」「トークン保持」の3条件を共有するためである。実装詳細は異なっても、攻撃者視点では同型の侵害チェーンを再利用できる。

したがって防御設計は製品単位ではなく、エージェント統合基盤単位で統一する必要がある。具体的には、MCP接続ポリシー、実行隔離、認証情報保護、監査連携を共通コントロールとして定義するべきである。

実装できる多層防御: 30日・90日で分ける手順

30日以内に実施すべき最小セットは5点である。1) MCPサーバー許可リスト化（署名済み・固定バージョンのみ）、2) フック設定ファイルのコードオーナー承認必須化、3) エージェント実行環境を開発者端末から分離したサンドボックスへ移行、4) OAuthトークンの短寿命化とスコープ最小化、5) AIツール実行ログをSIEMへ集約して相関検知を有効化、である。

90日計画では、SBOMに加えて「AI-BOM（どのエージェントがどのMCPサーバーをいつ実行したか）」を運用台帳化し、CIでドリフト検知を行う。さらに高リスク操作（シェル実行、秘密情報アクセス、本番変更）は人間承認ゲートを必須化し、エージェントの自律度を段階制御する。最終的には、RCEを“防ぐ”だけでなく、侵害発生時に横展開を止める設計へ重心を置くべきである。

MCP Serverセキュリティは、単一脆弱性のパッチ管理ではなく、エージェント統合全体の信頼境界を再設計する問題である。2026年の競争力は、接続スピードではなく、接続を壊されても被害を局所化できるアーキテクチャにより決まる。

FAQ

MCP Serverの導入を停止すべきか

全面停止より、許可リスト・実行隔離・監査強化を先行し、段階導入へ切り替える方が現実的である。業務価値とリスクを両立できる。

CVE-2025-59536の扱いで実務上注意すべき点は何か

CVSS値の大小だけで判断せず、フック構成・トークンスコープ・実行権限の3点を同時に評価すべきである。連鎖経路を遮断しない限り、単発パッチでは再侵害を防げない。

npm/PyPIの審査を強化すれば十分か

不十分である。MCPサーバーは配布後の設定変更や外部接続によりリスクが増幅するため、実行時ガードレールと監査が不可欠である。

Cursor/Windsurf/Gemini CLIで共通に実施できる対策は何か

共通実施が有効なのは、接続先ホワイトリスト、危険ツールの明示承認、短命トークン、SIEM連携、実行サンドボックス化である。製品差より統合方針の統一が効果を左右する。

参考文献