2026年2月、Docker社のAIアシスタント「Ask Gordon」に存在した重大な脆弱性「DockerDash」の詳細が公開された。CVSS 9.8の深刻度を持つこの脆弱性は、Dockerイメージのメタデータに埋め込まれた悪意ある命令が、Model Context Protocol（MCP）Gatewayを経由してリモートコード実行（RCE）やデータ窃取を引き起こすというものである。開発ツールへのAI統合が進む中、「メタコンテキストインジェクション」と呼ばれるこの新しい攻撃ベクターは、サプライチェーンセキュリティの根本的な再考を迫っている。

DockerDashとは何か ── メタデータが命令に変わるとき

DockerDashは、セキュリティ企業Noma Labsが2025年9月17日にDocker社のセキュリティチームに報告した脆弱性である。Docker Desktop 4.50.0（2025年11月6日リリース）で修正され、2026年2月3日に詳細が一般公開された。

問題の核心は、Docker社が提供するAIアシスタント「Ask Gordon」のアーキテクチャにある。Ask Gordonは、ユーザーがDockerイメージについて質問すると、そのイメージのメタデータ（LABELフィールド等）を読み取り、MCP Gatewayを通じてツールを実行する。攻撃者はこのフローを悪用し、Docker LABELフィールドに悪意あるMCPツール呼び出し命令を埋め込むことで、ユーザーの権限でコマンドを実行させることが可能であった。

この攻撃が成立した理由は、AI（Ask Gordon）→ MCP Gateway → MCPツールという実行チェーンの各段階で、命令の出所が検証されなかったことにある。メタデータは従来「情報」として扱われてきたが、AIエージェントがそれを解釈する時点で「実行可能な命令」に変質する。Noma Labsはこれを「メタコンテキストインジェクション（Meta-Context Injection）」と名付けた。

2つの攻撃経路 ── RCEとデータ窃取

DockerDashには、利用環境に応じた2つの攻撃経路が存在する。

経路1：Docker CLI/Cloud経由のRCE。攻撃者がDockerイメージのLABELフィールドに悪意ある命令を埋め込み、ユーザーがAsk Gordonにそのイメージについて質問すると、AIがメタデータ内の命令を正当なタスクとして解釈する。MCP Gatewayは検証なしにこれを実行し、docker stop等のコマンドが被害者の権限で実行される。コンテナエスケープやリバースシェルの作成も理論上可能であった。

経路2：Docker Desktopでのデータ窃取。Desktop環境ではAsk Gordonの権限が読み取り専用に制限されているが、それでもインジェクションされた命令により、インストール済みMCPツール一覧、コンテナ設定、ネットワークトポロジ、ビルドログに含まれるAPIキーやデータベースパスワードなどの機密情報を収集し、画像URLの埋め込みなどの手法で外部に送信できた。

いずれの経路でも、ユーザーはAsk Gordonに通常の質問をしただけであり、攻撃が実行されていることを認識する手段がなかった。これがDockerDashの深刻さを際立たせている。

MCPエコシステムに広がる構造的脆弱性

DockerDashは単独の事例ではない。MCP（Model Context Protocol）エコシステム全体に、同種の構造的脆弱性が広がっている。

Invariant Labsが2025年4月に発見した「ツールポイズニング」攻撃では、MCPツールのメタデータ（説明文やパラメータ定義）に<IMPORTANT>タグで囲んだ悪意ある指示を埋め込むことで、LLMの挙動を操作できることが実証された。ユーザーにはツールの簡略化されたUI表示しか見えないため、裏に隠された命令に気づくことは困難である。

2025年7月に公開されたCVE-2025-6514は、MCPクライアント向けOAuthプロキシ「mcp-remote」における命令インジェクション脆弱性（CVSS 9.6）であり、約43万件以上のダウンロードに影響した。さらにCVE-2025-49596では、MCP InspectorのCSRF脆弱性により、開発者に対するドライブバイ攻撃が可能であることが判明している。

Elastic Security Labsの調査では、テスト対象のMCP実装の43%にコマンドインジェクションの欠陥が、30%に無制限のURLフェッチが確認された。Palo Alto Networks Unit 42の研究チームは、MCPサーバーがプロンプト内容とレスポンス処理の両方を制御できるという設計上の非対称性が、リソース窃取、会話ハイジャック、秘密裏のツール呼び出しという3つの攻撃パターンを生むことを明らかにしている。

「確認ダイアログ」という緩和策の設計思想と限界

Docker社がDesktop 4.50.0で実装した主要な緩和策は、MCPツール実行前の明示的なユーザー確認（Human-in-the-Loop: HITL）である。Ask Gordonは、ビルトインツールであれユーザー追加ツールであれ、すべてのMCPツールを実行する前にユーザーの承認を求めるようになった。これにより、メタデータから注入された命令が自動実行されるチェーンが断たれる。

副次的な対策として、ユーザー指定URLを含む画像の表示をブロックすることでデータ窃取経路を封じ、イメージタグインジェクションによる情報漏洩も防止している。

しかし、HITLアプローチには本質的な限界がある。MCPTox（MCPツールポイズニングのベンチマーク）の研究では、1,312件の悪意あるテストケースに対し、20種のLLMエージェントの平均攻撃成功率は36.5%に達し、o1-miniでは72.8%に上った。興味深いことに、より高性能なモデルほど命令遵守能力が高いため攻撃に脆弱であるという「逆スケーリング」現象が確認されている。ユーザーが確認ダイアログの内容を正確に評価できるかどうかは、AIが生成する説明文の信頼性に依存するため、根本的な解決とは言い難い。

MCP仕様（2025年11月更新）は「ツール呼び出しを拒否する能力を持つ人間が常にループに存在すべき」と明記しているが、承認疲れ（Approval Fatigue）の問題は避けられない。Microsoftが提唱する防御多層化（Defense-in-Depth）アプローチ、すなわちネットワーク分離、RBAC、サンドボックス実行環境、継続的監視の組み合わせが、より現実的な防御戦略である。

開発ツールAI統合時代のサプライチェーン防衛

DockerDashが示した最大の教訓は、AIエージェントの統合が開発ツールの攻撃対象面を質的に変容させるという事実である。従来のサプライチェーン攻撃は、悪意あるパッケージやライブラリの混入が主な手法であった。署名検証、ハッシュチェック、SBOMによって防御可能な世界である。しかしAIエージェントの登場により、これまで「情報」でしかなかったメタデータ、ドキュメント、コメント、リポジトリの説明文が「実行可能な命令の配信メカニズム」へと変質した。

Pillar Securityの独立した調査でも、Docker Hubのリポジトリ説明文を通じたプロンプトインジェクションが実証されており、攻撃者はイメージそのものを改ざんする必要すらない。Invariant Labsは、GitHub MCPサーバーの脆弱性を利用して公開リポジトリの悪意あるIssueからプライベートリポジトリのデータを窃取するシナリオを公開している。

組織が採るべき対策は多層的である。第一に、AIエージェントが処理するすべてのデータを「信頼できない入力」として扱うゼロトラスト原則の適用。第二に、MCPツールのサンドボックス実行とネットワークセグメンテーション。第三に、ツール定義の暗号署名と改ざん検知。第四に、すべてのツール呼び出しの不変監査ログと異常検知。そして第五に、組織管理者によるAIアシスタント機能の一括無効化オプションの確保である。

2025年だけでGitHub上に13,000以上のMCPサーバーが公開された。セキュリティ審査の速度をはるかに超えるエコシステムの拡大が続く中、DockerDashは「AIを使った開発の便利さ」と「AIが開く新たな攻撃面」のトレードオフを、具体的な被害シナリオとともに突きつけた最初の大規模事例として記憶されるだろう。

FAQ

DockerDash脆弱性はどのバージョンで修正されたか？

Docker Desktop 4.50.0（2025年11月6日リリース）で修正された。すべてのDocker Desktopユーザーはこのバージョン以降へのアップデートが推奨される。

MCP（Model Context Protocol）とは何か？

MCPは、AIモデルが外部ツールやデータソースと連携するための標準プロトコルである。DockerのAsk Gordonをはじめ、多くのAI開発ツールがMCPを採用してツール実行やデータアクセスを行っている。

メタコンテキストインジェクションと従来のプロンプトインジェクションの違いは？

従来のプロンプトインジェクションはユーザー入力を直接操作するが、メタコンテキストインジェクションはDockerイメージのLABELなどメタデータ経由で間接的にAIの挙動を操作する。攻撃がデータの「文脈」に埋め込まれるため、検出がより困難である。

自組織のDocker環境が影響を受けたか確認する方法は？

Dockerコマンド実行ログの監査、ネットワークトラフィックログでの不審な外部通信の確認、Docker関連の認証情報のローテーションが推奨される。特にAsk Gordonで外部イメージを参照した履歴がある場合は、追加の調査が必要である。

参考文献