Anthropicが開発したオープンプロトコル「MCP」のSTDIO実装に、設計レベルのリモートコード実行（RCE）欠陥が確認された。セキュリティ企業OX Securityの調査によると、影響を受けるサーバは20万台以上、ダウンロード数は1億5,000万件を超える。
この記事でわかること:
- MCPのSTDIOに潜む設計レベルのRCE脆弱性の仕組み
- 4つの攻撃ベクターと実際に影響を受けたツール・サービス
- AnthropicがCVEを認めながら修正を拒否している理由
- 開発者が今すぐ確認すべき対策ポイント
MCPのSTDIOで「設計通り」に任意コマンドが実行される
MCP（Model Context Protocol）は、LLMやAIエージェントが外部データソースやツールと連携するための標準プロトコルで、Anthropicが開発してオープンソース化した。現在はTypeScript、Python、Java、Rust、Goなど10以上の言語向けにSDKが提供されており、LangChain、FastMCP、Amazon、NVIDIAなど多数のフレームワークがAnthropicの参照実装に依存している。
MCPにはクライアント・サーバ間の通信方式として「Streamable HTTP（SSE）」と「STDIO（標準入出力）」の2種類がある。STDIOはローカル環境でMCPサーバをサブプロセスとして起動するための方式で、クライアントアプリがコマンドを渡してサーバを立ち上げる仕組みだ。
問題はここにある。コマンドの中身を検証する仕組みがないため、MCPサーバを起動するはずのパラメータに「任意のOSコマンド」を埋め込んでも、SDKはそれをそのまま実行する。コマンドがMCPサーバの起動に失敗しても、実行そのものはコマンドが走った後にエラーが返るだけだ。
OX Securityはこの問題を2025年11月から追跡し、2026年4月15日に調査結果を公開した。「ブラストラジウスは巨大だ。実際の企業の6つの公式サービスで直接コマンド実行に成功し、1億5,000万ダウンロードを超える200以上のオープンソースプロジェクトのサーバを掌握できた」と研究チームは報告書に記している。
4つの攻撃ベクター
OX Securityが確認した攻撃パターンは4種類に分類される。
①認証なしのコマンドインジェクション
公開されているUIを持つAIフレームワークを対象に、STDIO設定のコマンドフィールドへ直接攻撃者が任意コマンドを送り込む。LangFlow（IBMのAIアプリ構築フレームワーク）、GPT Researcherなど複数のツールが影響を受けた。CVE-2025-65720が発行されているが、LangFlowにはCVEが未発行のままだ。
②ハードニングバイパスによるコマンドインジェクション
npxやpythonといった許可コマンドだけを実行できるようホワイトリスト保護を実装したツールでも、npx -c <コマンド> のように引数を悪用することで保護を回避できる。Upsonic（CVE-2026-30625）とFlowise（GHSA-c9gw-hvqq-f33r）がこのパターンで突破された。
③ゼロクリックのプロンプトインジェクション
Webサイトに埋め込まれた隠し命令がLLMエージェントを操作し、MCP設定ファイルを書き換えて悪意あるコマンドを仕込む。VS Code、Cursor、Claude Code、Gemini CLIなどのIDEはすべてSTDIOによるMCPサーバをサポートしているため、技術的にはすべて影響を受ける。ただし多くのIDEはファイル変更前にユーザーの確認を求めるため、実質的にゼロクリックが成立したのはWIndsurf（CVE-2026-30615）のみだった。
④MCPマーケットプレイスを経由した汚染
OX SecurityはテストとしてPoC用のMCPエントリ（空ファイルを生成するだけの無害なもの）を11のMCPマーケットプレイスに投稿し、9つで受け入れられた。「月間数十万人の訪問者を持つプラットフォームも含まれている。悪意あるMCPが1件登録されれば、検出される前に何千人もの開発者がインストールし、それぞれのマシンで任意コマンド実行が可能になる」と研究チームは指摘している。
Anthropicの対応：「設計通りの動作」
OX SecurityはAnthropicに対して繰り返し修正を要請したが、Anthropicはプロトコルのアーキテクチャ変更を拒否し、「期待される動作」と回答した。初回報告から1週間後、AnthropicはMCPアダプター（特にSTDIO）は注意して使用すべきとするセキュリティポリシーを静かに更新したが、根本的な修正は行われていない。
LangChain（mcp-adapters）、FastMCP、Amazon（run-model-context-protocol-servers-with-aws-lambda）、NVIDIA（NeMo-Agent-Toolkit）なども同様に「意図した動作」または「他の制御機構で緩和済み」として修正しないと表明している。
OX Securityは反論する。「プロトコルレベルで1つのアーキテクチャ変更を行えば、すべての下流プロジェクト、すべての開発者、すべてのエンドユーザーを保護できた。それがスタックを所有するということだ」。STDIOコマンドに対するデフォルトのコマンド許可リスト（sh、bash、powershell、curl、rmなどの高リスクバイナリをブロック）を実装すべきと提案している。
2026年4月時点で、この問題に関連して発行されたCVEは10件を超えており、影響を受けるツールは脆弱性の修正や緩和策の適用を個別に進めている状況だ。
開発者が今すぐ確認すべきこと
Anthropicが参照実装の修正を行わない以上、MCPを利用するアプリケーション開発者側での対応が必要になる。確認すべきポイントは以下の通りだ。
まず、自分のアプリケーションがSTDIOモードでMCPサーバを起動する場合、コマンドフィールドにユーザー入力が直接流れ込む経路がないか確認する。ユーザー入力はSTDIOコマンドとして渡す前に厳格なバリデーションとサニタイズを行うべきだ。
次に、コマンドのホワイトリストを実装している場合、npx -cやpython -cのような引数経由のバイパスが可能かを確認する。許可コマンドに加えて、その引数も制限する実装が必要だ。
SaaS環境でMCPサポートを提供している場合は、ユーザーが指定したMCPサーバ設定が本番サーバ上で直接実行されないよう、実行環境の分離（Dockerコンテナなど）も有効な緩和策になる。
まとめ
今回の問題の本質は、MCPのSTDIOが「誰でも任意のOSコマンドを実行できる状態」をデフォルトで許容している点にある。Anthropicが「設計通り」と主張する一方で、現実には30件以上の責任ある開示プロセスと10件超のCVEが発行される事態になっている。
MCPは今やAIエージェントの基盤インフラとなっており、その安全性は一社の判断だけに委ねられない段階に来ている。MCPを利用する開発者は、プロトコルレベルの修正を待つのではなく、アプリケーション側でSTDIOコマンドのバリデーションを今すぐ実装する必要がある。