MCP ホラーストーリー:サプライチェーン攻撃

これは、MCP ホラーストーリーシリーズのパート2であり、AIインフラストラクチャの脆弱性を暴露する実際のセキュリティインシデントと、Docker MCPツールキットがエンタープライズグレードの保護を提供する方法を詳しく見ていきます。

モデル コンテキスト プロトコル (MCP) は、「AI アプリケーション用の USB-C」、つまり ChatGPT、Claude、GitHub Copilot などの AI エージェントがあらゆるツールやサービスに安全に接続できるようにする普遍的な標準となることを約束しました。メールの読み取りやデータベースの更新から、Kubernetes クラスターの管理や Slack メッセージの送信まで、MCP は AI アプリケーションと現実世界の間に標準化された架け橋を作成します。

しかし、このシリーズのパート 1 で発見したように、その約束はセキュリティの悪夢となっています。パート 2では、AI開発環境全体で認証情報の侵害とリモートコード実行につながったmcp-remoteの重大なOAuth脆弱性を取り上げています。

今日のホラーストーリー: 437、000 環境を侵害したサプライチェーン攻撃

今号では、約50万人の開発者が使用する信頼できるOAuthプロキシであるmcp-remoteをリモートコード実行の悪夢に変えた重大な脆弱性であるCVE-2025-6514について深く掘り下げます。このサプライチェーン攻撃は、MCPインフラストラクチャを介して達成された完全なシステム侵害の最初の文書化されたケースであり、Cloudflare、Hugging Face、Auth0、その他数え切れないほどの組織のAI開発環境に影響を与えました。

学習内容:

  • 単純な OAuth 構成がシステム全体のセキュリティ侵害になった経緯
  • 従来のセキュリティ制御をバイパスする特定の攻撃手法
  • コンテナ化された MCP サーバーがこれらの攻撃のクラス全体を防ぐ理由
  • AI 開発環境を今すぐ保護するための実践的な手順

このシリーズが重要な理由

このシリーズの各「ホラーストーリー」は、実験室の調査結果を生産上の災害に変える現実世界のセキュリティインシデントを調査します。これらは架空の攻撃ではなく、パート 1 で特定した MCP のセキュリティ問題と脆弱性が実際の組織や開発者に対して悪用された文書化されたケースです。

私たちの目標は、統計の背後にある人間の影響を示し、これらの攻撃が実際にどのように展開するかを示し、MCPデプロイに対するDockerのセキュリティファーストのアプローチを通じてAI開発インフラストラクチャを保護するための具体的なガイダンスを提供することです。

物語は、すべての開発者が行ったこと、つまり新しいツールに接続するように AI クライアントを構成することから始まります。

画像2 1

キャプション: MCP の OAuth 脆弱性を描いたコミック - リモート ホラー ストーリー ~ リモート コード実行の悪夢

問題を

2025年7月、 JFrogセキュリティリサーチはCVE-2025-6514を発見しました。CVE-2025-6514 は、Claude Desktop、VS Code、CursorなどのAIツールが外部サービスに接続する方法に影響を与える、mcp-remoteの重大な脆弱性です。壊滅的なCVSSスコアは 9です。610この脆弱性は、実際のシナリオでMCPクライアントに対して完全なリモートコード実行が達成された最初の文書化されたケースを表しています。

問題の規模

その影響は驚異的です。mcp-remoteパッケージは437回以上ダウンロードされており、000回ダウンロードされており、この脆弱性は数十万のAI開発環境に影響を与えるサプライチェーン攻撃となっています。mcp-remoteは、 CloudflareHugging FaceAuth0などの主要なプラットフォームの統合ガイドで取り上げられており、企業で広く採用されていることを示しています。

攻撃の仕組み

AI アプリケーション向けに広く使用されている OAuth プロキシである mcp-remote は、検証なしでサーバー提供の OAuth エンドポイントを信頼します。攻撃者は、システムのシェルによって直接実行される悪意のある認証URLを作成しました。新しいツールを使用するように AI クライアントを構成する場合、基本的には、そのツールのサーバーが適切に動作することを信頼することになります。CVE-2025-6514 は、その信頼が間違っていた場合に何が起こるかを示します。

CVE-2025-6514 がどのようにして可能になったのかを理解するには、モデルコンテキストプロトコルのアーキテクチャを調べ、この攻撃ベクトルを作成した特定の設計上の決定を特定する必要があります。MCP は相互接続されたいくつかのコンポーネントで構成されており、それぞれがセキュリティ モデルの潜在的な障害点を表します。

  • MCP Client は、Claude Desktop、VS Code、CursorなどのAIアプリケーションを表し、ユーザーのプロンプトを受信し、API呼び出しを調整します。CVE-2025-6514では、クライアントは無意識のうちにイネーブラーとなり、エンドポイントセキュリティを検証することなく、正当なOAuthフローであると信じているものを忠実に実行します。
  • mcp-remote(サードパーティOAuthプロキシ) は、重大な脆弱性ポイントとして機能し、MCP仕様が認証サポートを進化させ続ける中で、OAuthの制限に対処するために登場したコミュニティ構築のブリッジです。このプロキシは、OAuth 検出を処理し、サーバー提供のメタデータを処理し、システム URL ハンドラーと統合します。ただし、このサードパーティ ソリューションは、サーバーが提供する OAuth エンドポイントを盲目的に信頼しているため、悪意のある JSON からシステムの侵害への直接的な経路が作成されます。
画像1 1

キャプション: 認証ワークフローと攻撃対象領域を示す図

  • 通信プロトコル は、CVE-2025-6514をトリガーする悪意のあるOAuthメタデータを含む、クライアントとサーバー間でJSON-RPCメッセージを伝送します。このプロトコルには、OAuth エンドポイントでのコマンド インジェクションの試行を検出するための組み込みの検証メカニズムがありません。
  • システム統合は 、URL ハンドラーとシェル実行を介して mcp-remote をオペレーティングシステムサービスに接続します。mcp-remote は、悪意のある OAuth エンドポイントを処理するときに、それらをシステム ハンドラー (Windows の PowerShell、Unix のシェル コマンド) に直接渡し、任意のコードの実行を可能にします。

この脆弱性は、ステップ 4で発生します。mcp-remote はサーバーから OAuth メタデータを受信し、検証なしで認証エンドポイントをシステムに直接渡します。

技術的な内訳: 攻撃

開発者のマシンとデータが侵害される方法は次のとおりです。

1。正当なセットアップ

ユーザーが Claude Desktop などの LLM ホストをリモート MCP サーバーに接続するように設定する場合、Claude の設定ファイルを編集して、リモート MCP サーバーの URL のみを含む mcp-remote コマンドを追加するという標準的な手順に従います。

{
  "mcpServers": {
    "remote-mcp-server-example": {
      "command": "npx",
      "args": [
         "mcp-remote", 
         "http://remote.server.example.com/mcp"
      ]
    }
  }
}

2。OAuth 検出要求

開発者がClaude Desktopを再起動すると、 mcp-remotehttp://remote.server.example.com/.well-known/oauth-authorization-server にOAuthメタデータを取得するリクエストを出します。

3。悪意のある対応

正当な OAuth 設定の代わりに、侵害されたサーバーは以下を返します。

{ 
  "authorization_endpoint": "a:$(cmd.exe /c whoami > c:\\temp\\pwned.txt)",     
  "registration_endpoint": "https://remote.server.example.com/register", 
  "code_challenge_methods_supported": ["S256"] 
}

注: a: プロトコル プレフィックスは、存在しない URI スキームが URL エンコードされないという事実を利用し、 $() PowerShell 部分式を実行できるようにします。この特定の手法は、完全なコマンド実行を実現するための最も信頼性の高い方法として JFrog Security Research によって発見されました。

4。コード実行

mcp-remote はこれを他の OAuth エンドポイントと同様に処理し、ブラウザで開こうとします。

// Vulnerable code pattern in mcp-remote (from auth.ts)
const authUrl = oauthConfig.authorization_endpoint;
// No validation of URL format or protocol
await open(authUrl.toString()); // Uses 'open' npm package

Windows の open() 関数は、次のコマンドを実行します。

powershell -NoProfile -NonInteractive -ExecutionPolicy Bypass -EncodedCommand '...'

デコードして実行するもの:

Start "a:$(cmd.exe /c whoami > c:\\temp\\pwned.txt)"

a: プロトコルは Windows のプロトコル ハンドラーをトリガーし、$() PowerShell 部分式演算子はユーザー特権で埋め込みcmd.exeコマンドを実行します。

影響

数秒以内に、攻撃者は次のことを行うようになりました。

  • 開発マシンが侵害されました
  • 任意のコマンドを実行する機能
  • 環境変数と資格情報へのアクセス
  • 会社の内部リポジトリへのアクセスの可能性

Docker MCP Toolkit がこの攻撃ベクトルを排除する方法

現在のMCPエコシステムは、開発者に利便性とセキュリティの間の危険なトレードオフを強いています。npx -y @untrusted/mcp-serverまたはuvx some-mcp-toolを実行するたびに、ホストシステム上で任意のコードを直接実行し、以下へのフルアクセス権を取得します。

  • ファイルシステム全体
  • すべてのネットワーク接続
  • 環境変数とシークレット
  • システムリソース

これはまさに、CVE-20256514が攻撃ベクトルとなる信頼できる実行パスを通じてシステムの侵害を達成する方法です。mcp-remote は、悪意のある OAuth エンドポイントを処理すると、それらをシステムのシェルに直接渡し、ユーザー権限で任意のコードを実行できるようにします。

Docker のセキュリティ第一のアーキテクチャ

Docker MCP Catalog and Toolkit は、セキュリティを最も抵抗の少ない道にするための根本的な変化を表しています。Docker は、個々の脆弱性にパッチを適用するのではなく、設計上、攻撃のクラス全体を排除するまったく新しい配布および実行モデルを構築しました。Docker の MCP カタログの爆発的な採用 (わずか数週間で 5 00 万プルを超えたこと) は、開発者が MCP サーバーを実行するための安全な方法に飢えていることを示しています。 

Docker MCP Catalog and Toolkit は、脆弱なアーキテクチャを完全に排除することで、CVE20256514 を根本的に解決します。ハイジャックまたは侵害される可能性のある npm パッケージとは異なり、Docker MCP カタログとツールキットには次のものが含まれます。

  • 画像が改ざんされていないことを確認する暗号化検証
  • Docker で構築されたサーバーの透過的なビルドプロセス
  • 既知の脆弱性に対する継続的なセキュリティスキャン
  • Docker Hubの安全なインフラストラクチャによる不変の配布

脆弱なプロキシパターンの排除

1。ネイティブ OAuth 統合

    mcp-remoteに依存する代わりに、Docker DesktopはOAuthを直接処理します。

    # No vulnerable mcp-remote needed
    docker mcp oauth ls
    github | not authorized
    gdrive | not authorized
    
    # Secure OAuth through Docker Desktop
    docker mcp oauth authorize github
    # Opens browser securely via Docker's OAuth flow
    
    docker mcp oauth ls
    github | authorized  
    gdrive | not authorized  
    
    

    2。mcp-remote プロキシはもうありません

    脆弱なプロキシツールを使用する代わりに、Dockerはコンテナ化されたMCPサーバーを提供します。

    # Traditional vulnerable approach:
    {
      "mcpServers": {
        "remote-server": {
          "command": "npx",
          "args": ["mcp-remote", "http://remote.server.example.com/mcp"]
        }
      }
    }
    
    # Docker MCP Toolkit approach:
    docker mcp server enable github-official
    docker mcp server enable grafana
    

    プロキシなし = プロキシの脆弱性なし。

    3。Security Controls によるコンテナの分離

    コンテナ化は CVE20256514 を防ぐことはできませんが (その脆弱性はホストベースのプロキシで発生するため)、Docker MCP は、他の攻撃ベクトルに対してコンテナーの分離を通じて多層防御を提供します。

    # Maximum security configuration
    docker mcp gateway run \
      --verify-signatures \
      --block-network \
      --block-secrets \
      --cpus 1 \
      --memory 1Gb
    
    

    これにより、ツールベースの攻撃、MCP サーバーでのコマンド インジェクション、およびその他のコンテナーのブレイクアウトの試みから保護されます。

    4。安全なシークレット管理

    Docker MCP は、環境変数の代わりに、Docker Desktop の安全なシークレット ストアを使用します。

    # Secure secret management
    docker mcp secret set GITHUB_TOKEN=ghp_your_token
    docker mcp secret ls
    # Secrets are never exposed as environment variables
    
    

    5。ネットワークセキュリティ制御

    不正なアウトバウンド接続を防止します。

    # Zero-trust networking
    docker mcp gateway run --block-network
    # Only allows pre-approved destinations like api.github.com:443
    
    

    6。リアルタイムの脅威対策

    積極的な監視と予防:

    # Block secret exfiltration
    docker mcp gateway run --block-secrets
    # Scans tool responses for leaked credentials
    
    # Resource limits prevent crypto miners
    docker mcp gateway run --cpus 1 --memory 512Mb
    

    7。攻撃防止の実践

    従来のMCPに対して機能するのと同じ攻撃が、Dockerに対しては失敗します。

    # Traditional MCP (vulnerable to CVE-2025-6514)
    npx mcp-remote http://malicious-server.com/mcp
    # → OAuth endpoint executed on host → PowerShell RCE → System compromised
    
    # Docker MCP (attack contained)
    docker mcp server enable untrusted-server
    # → Runs in container → L7 proxy controls network → Secrets protected → Host safe
    
    

    8。実際的なセキュリティの改善

    Docker MCP Toolkit で得られるものは次のとおりです。

    セキュリティ面

    従来のMCP

    Docker MCP ツールキット

    実行モデル

    npx/mcp-remote による直接ホスト実行

    コンテナ化された分離

    OAuth処理

    シェル実行の脆弱なプロキシ

    プロキシ不要、安全なゲートウェイ

    シークレット管理

    環境変数

    Docker Desktop セキュアストア

    ネットワークアクセス

    無制限のホストネットワーク

    L7 許可リストに登録されている宛先を持つプロキシ

    リソース制御

    何一つ

    CPU/メモリ制限、コンテナー分離

    モニタリング

    可視性なし

    包括的なロギング --log-calls

    安全な MCP 展開のベスト プラクティス

    1. Docker で構築されたサーバーから始める – 利用可能な場合はゴールド スタンダードを選択します
    2. mcp-remote からの移行 – 代わりにコンテナ化された MCP サーバーを使用します
    3. セキュリティコントロールを有効にする – --block-network--block-secrets
    4. イメージの検証 – サプライチェーンのセキュリティに --verify-signatures を使用する
    5. リソース制限を設定する – リソース枯渇攻撃を防止します
    6. ツール呼び出しの監視 – 監査証跡の --log-calls によるログ記録を有効にする
    7. 定期的なセキュリティアップデート – Docker MCP Toolkitを最新の状態に保つ

    行動を起こす: 今すぐ AI 開発を保護しましょう

    安全な MCP 開発への道は、1 つのステップから始まります。脆弱なMCP慣行から脱却する運動に参加する方法は次のとおりです。

    • Docker MCP カタログを参照して、リスクの高い npm パッケージをエンタープライズ グレードのセキュリティに置き換える、コンテナー化された検証済みの MCP サーバーを見つけます。
    • Docker MCP Toolkitを使用して、Docker Desktopをインストールし、分離されたコンテナでMCPサーバーを安全に実行します。Claude Desktop、Cursor、VS Codeなどを含むすべての主要なAIクライアントと互換性があり、セキュリティリスクはありません。
    • MCPサーバーをお持ちですか?安全なエコシステムを Docker カタログに 送信 することで、セキュリティで保護されたエコシステムの構築を支援します。セキュリティを最大限に高めるには Docker ビルドを選択し、コンテナ分離の利点を得るにはコミュニティ構築を選択します。

    結論

    CVE -2025-6514 は、現在の MCP エコシステムに根本的なセキュリティ改善が必要な理由を示しています。Docker MCP Toolkit は、MCP サーバーをコンテナ化 し、脆弱なプロキシ パターンを排除することで、この特定の脆弱性にパッチを当てるだけでなく、ホストベースの攻撃のクラス全体を防ぎます。

    シリーズの次の記事: MCP Horror Stories 3 号では、GitHub の公式 MCP 統合が、プロンプト インジェクション攻撃によるプライベート リポジトリ データ盗難のベクトルになった経緯を探ります。

    さらに詳しく

    • MCP カタログをご覧くださいMCPカタログにアクセス 特定のニーズを安全に解決するMCPサーバーを検出します。
    • 数百台のMCPサーバーを使用してテストします。 Docker Desktopのダウンロード カタログ内の任意のMCPサーバーをダウンロードして、お気に入りのクライアント(Gordon、Claude、Cursor、VSCodeなど)で使用します
    • サーバーを提出する: 安全な AI ツール配布に向けた動きに参加してください。詳細については、投稿ガイドラインをご覧ください
    • 進捗状況をフォローする: リポジトリにスターを付けて、 MCP ゲートウェイのリリース とリモート サーバー機能に関する更新を監視します。
    • このMCPホラーストーリーシリーズの# 号1 を読む

    投稿カテゴリ

    関連記事