MCP設定の安全でないデフォルト設定により、複数の商用サービスおよびオープンソースプロジェクトによって証明されたリモートコード実行の可能性にサーバが晒される。
AIエージェント構築ツールは、ユーザーがModel Context Protocol（MCP）サーバーを設定できるようにしていますが、Anthropicのリファレンス実装における設計上の決定により、システムをリモートコード実行に晒している可能性があります。
問題となっているのは、STDIOインターフェースを介したMCP設定の安全でないデフォルト値であり、エージェントエコシステム全体に広範な影響を及ぼします。
「被害の規模は莫大です」と、アプリケーションセキュリティ企業OX Securityの研究者たちは設計上の問題に関するレポートで述べています。「この悪用により、実際の有料顧客を持つ実在する企業の6つの公式サービス上で直接コマンドを実行でき、数百万ダウンロードされた200以上の人気のあるオープンソースGitHubプロジェクトに及ぶ数千台の公開サーバを乗っ取ることができました。」
Anthropicおよび他のMCPアダプタ開発者によると、STDIOコマンド実行の動作は仕様通りであり、MCP設定をサニタイズする責任はクライアントアプリケーションの開発者にあります。これは確かですが、実際にはOX Securityは、MCP設定でコマンドをフィルタリングしようとした開発者がほとんどいないこと、また、そうした開発者でさえ全ての潜在的なバイパス方法を検出することに失敗していることを発見しました。
問題の根源
MCPは、アプリケーションがデータソースとツールをLLMに公開するための標準化された方法を提供し、その文脈と自動ワークフロー完成における有効性を向上させます。元々AnthropicによってリリースされたMCPは、エージェント型AI空間で広く採用されている技術となっています。
Anthropicは、TypeScript、Python、Java、Kotlin、C#、Go、PHP、Ruby、RustおよびSwiftを含む様々なプログラミング言語用のSDKという形でMCPのリファレンス実装を提供しています。さらに、FastMCP、LangChainのmcp-adapters、MicrosoftのAgent Framework、mcp-agent、browser-use、AmazonのRun Model Context Protocol Servers with AWS Lambda、およびNVIDIAのNeMo-Agent-Toolkitなどのフレームワークと機能プロバイダーは、Anthropicのmodelcontextprotocolリファレンス実装に依存しています。
MCPはサーバとクライアント間で2つのトランスポートインターフェースをサポートしています。通常はリモートMCPサーバーとWebサービスに使用されるServer-Sent Events（SSE）対応のStreamable HTTP、および同じマシン上でローカルに実行されるMCPサーバーとアプリケーション用の標準入力/出力（STDIO）です。
STDIOを使用する場合、クライアントアプリケーションはMCPサーバーをサブプロセスとしてオンデマンドで起動し、パラメータを渡すことができます。これらのパラメータには、親プロセスの権限でシステム上で実行されるカスタムコマンドを含めることができます。理論上、これらのコマンドはSDKのStdioServerParametersファンクションにMCPサーバーを起動する方法を指示することを目的としていますが、フィルタリングがない場合は実質的に何でもあり得ます。
OX Securityの研究者たちはこれを緩和されるべき設計上の欠陥と見なしていますが、AnthropicおよびLangChainやFastMCPなどのMCP機能を可能にする他のフレームワークの作成者たちは同意していません。その理論的根拠は、悪意のあるユーザー入力がSDKのコマンド実行関数に到達しないようにすることの責任は、これらのMCPフレームワークを統合するクライアントアプリケーションの開発者にあるということです。
「ユーザーが提供した文字列をシェル実行環境に直接流す パターンは非推奨にされるべきアンチパターンです」とOX Securityの研究者たちは述べています。AnthropicのSDKは、デフォルトでコマンド許可リストを実装し、sh、bash、powershell、curl、rmおよびその他のハイリスク バイナリをブロックすべきであると彼らは追加しています。
核となる問題は、STDIOコマンドがMCPサーバーを初期化することを意図しているのか、それとも悪意のあるタスクを実行することを意図しているのかを検証するチェックが現在存在していないことです。さらに、研究者たちは、送信されたコマンドがサーバー起動に失敗した場合でも、SDKはコマンドが既に実行された後にエラーを返すことを観察しました。
VS Code、Cursor、Windsurfなどの全ての最新IDEおよびClaude Code、OpenAI Codex、Gemini CLIなどのエージェント型コーディングCLIには、STDIO経由のローカルMCPサーバーに対する組み込みサポートがあります。しかし、これは無数の他のエージェント型AIフレームワークおよびオープンソースツールにも当てはまり、そのほとんどはSTDIOコマンド許可リストを実装していません。
実世界のアプリケーションにおけるRCE
OX Securityの研究者たちは、ライブ本番サービスを含む多くのツールにおけるMCPサポートをテストするために過去数ヶ月間を費やしてきました。彼らは、このSTDIO設計決定に由来する30以上のRCE問題を発見し、複数のプロジェクトに報告しており、現在までに10個がCVE IDを受け取っています。
ツールがMCPサポートをどのように実装しているか、そしてユーザー入力をどのように受け入れるかに応じて、STDIO コマンドフィルタリングの欠如を悪用する複数の攻撃ベクトルがあります。
例えば、一部のサービスとツールはSTDIOを内部で無効化していません。これは、ユーザーインターフェースがStreamable HTTPでのみMCPサーバーの設定を許可していますが、Letta AIおよびDocsGPTの場合でした。これらは、企業がクラウドサービスとローカルデプロイの両方を通じてAIエージェントを作成できるプラットフォームです。
「MCP サーバー設定のためのネットワークリクエストを細工し、設定されたJSONのトランスポートタイプをSSEまたはHTTPではなくSTDIOタイプに変更し、リクエストペイロードに任意のコマンドを追加することで、攻撃者はリモートコマンド実行を達成できます」と研究者たちは述べています。
別の攻撃ベクトルは、悪意のあるMCP設定につながるプロンプトインジェクションです。すべてのIDEは技術的にはこれに対して脆弱です – ウェブサイトにはLLMエージェントがローカルファイルを修正するための隠れた指示が含まれている可能性があります – ほとんどのIDEはMCP設定ファイルに変更を加える前にユーザーに確認を促します。例外はWindsurfで、これはデフォルトでMCP設定を直接修正し、ゼロインタラクションコマンドインジェクション攻撃が発生しました。
他の多くのツールはMCP STDIOパラメータにフィルタリングを適用していません。つまり、MCPサーバーを設定するアクセス権を持つユーザーは、SaaS デプロイの場合は本番サーバーを含む、基礎となるサーバー上でコード実行を取得します。このような脆弱性があったツールには、LangFlow、GPT Researcher、LiteLLM、Agent Zero、LangBot、Fay Digital Human Framework、Bisheng、Jaaz、Langchain-Chatchatおよび研究者がまだ開示できない他のツールが含まれます。
一部の開発者は問題を認識しており、コマンドホワイトリストを使用した実装を強化しようとしました。しかし、強化は不十分であり、OX Securityの研究者たちは単純なバイパスを発見しました。
例えば、AIエージェント構築用のオープンソースフレームワークであるUpsonicは、npxを含む許可リストを実装しており、npxが実行するための-c（—call）フラグをサポートしています。このフラグは、カスタムコマンドとシェルスクリプトをnpxに渡すことを許可します。同じバイパスがFlowise（別のUI ベースのAIエージェント構築フレームワークで、MCP設定コマンドを制限していますが、npxを許可しています）でも観察されました。
Anthropic（modelcontextprotocol）、LangChain（langchain-mcp-adapters）、FastMCP、browser-useプロジェクト、AWS（Run Model Context Protocol Servers with AWS Lambda）、NVIDIA（NeMo-Agent-Toolkit）、OpenHands、PromptFoo、Firebase Studio、Gemini CLI、Claude Code、GitHub Copilot、およびCursorは、技術的には任意のコマンド実行を可能にするMCP STDIOコードを含んでいます。
