20万のMCPサーバーがコマンド実行の欠陥を露呈—Anthropicは「機能」と呼ぶ

Anthropicは、AIエージェントとツール間の通信のオープン標準として、Model Context Protocolを作成しました。OpenAIは2025年3月にそれを採用しました。Google DeepMindも追随しました。Anthropicは2025年12月にMCPをLinux Foundationに寄贈しました。ダウンロード数は1億5,000万を超えました。ところが、OX Securityの4人の研究者が、そのすべてに影響するアーキテクチャ上の問題を見つけました。

MCPのSTDIOトランスポート（AIエージェントをローカルのツールに接続するためのデフォルト）は、受け取った任意のOSコマンドを実行します。サニタイズはありません。設定とコマンドの間に実行境界もありません。悪意のあるコマンドは、すでにコマンドが実行された後にエラーを返します。開発者向けツールチェーンは何も警告しません。

OX Securityの研究者Moshe Siman Tov Bustan、Mustafa Naamnih、Nir Zadok、Roni Barはエコシステムを調査し、STDIOトランスポートが有効な状態で公開IP上に7,000台のサーバーがあることを発見しました。そして、その比率から推定して、合計で20万件の脆弱なインスタンスがあると見積もっています。研究では、課金顧客を抱える6つの稼働中の本番プラットフォームで、任意コマンド実行が可能であることを確認しました。研究成果として、LiteLLM、LangFlow、Flowise、Windsurf、Langchain-Chatchat、Bisheng、DocsGPT、GPT Researcher、Agent Zero、LettaAIなどにわたり、10件以上のCVE（高または重大）が作成されました。

Ulster Universityのサイバーセキュリティ教授でIEEEシニアメンバーのKevin Curranは、Infosecurity Magazineに対して、今回の研究が「基盤となるAIインフラのセキュリティにおける驚くべきギャップ」を露呈したと、独立して語っています。

Anthropicは挙動は設計によるものだと確認し、プロトコルの修正は行わないとしました。STDIOの実行モデルを「安全なデフォルト」と位置づけ、入力のサニタイズは開発者の責任だと説明しました。この見解はOXの指摘を受けたものではありますが、Anthropicが公式に明示した記録上の唯一の言葉は「expected（予期される）」です。Anthropicは単独の公開声明を出しておらず、VentureBeatからのコメント要請にも応じていません。

OXは、20万件の開発者に入力を正しくサニタイズさせることを期待するのが問題だと述べています。Anthropicの最も強い技術的な反論は、STDIOをサニタイズすればトランスポートが壊れるか、あるいはペイロードをさらに1階層下に押し下げることになる、というものです。どちらの立場も技術的には筋が通っています。問題は、その議論が進行している間にどうするかです。

主要メディアはすべて、この開示を報じました。しかし、セキュリティ責任者が自社のMCP導入をトリアージするために必要な「処方箋付きの製品別監査」を構築したところはありません。この記事はそれを行います。

次の5つの問いが、あなたのMCP導入が露出しているかどうか、パッチが効いているかどうか、そして月曜の朝に何をすべきかを決めます。

自分は影響を受けていますか？

チームがデフォルトのSTDIOトランスポートを使って、MCP接続のAIエージェントを導入しているなら、はい。脆弱性は、特定の1製品の単なるコーディング不具合ではありません。これはAnthropicのMCP仕様における設計上のデフォルトで、すべての公式言語SDKに伝播しています。Python、TypeScript、Java、Rustです。プロトコルを信頼した下流のあらゆるプロジェクトが、それを受け継ぎました。

OXは、4つの悪用（エクスプロイト）ファミリーを特定しました。AIフレームワークのWebインターフェース経由による、認証なしのコマンドインジェクションで、LangFlowとLiteLLMに対して実証されています。コマンド許可リスト（allowlist）を実装したツールにおける、ハードニング回避で、FlowiseとUpsonicに対して実証されました。OXは引数インジェクション（npx -c）により許可リストを回避しました。AIコーディングIDEにおけるゼロクリック・プロンプトインジェクションでは、悪意のあるHTMLがローカルのMCP設定ファイルを修正します。Windsurf（CVE-2026-30615）は、悪用にゼロユーザー操作が必要だった唯一のIDEでしたが、Cursor、Claude Code、Gemini-CLIはいずれも、より広いファミリーに対して脆弱です。そして、MCPレジストリ経由の悪意あるパッケージ配布では、OXが11のレジストリに良性のPoCを提出し、9つがセキュリティレビューなしでそれを受け入れました。

ReputationのAI/マシンラーニング担当VPであり、ユタ州AI委員会のメンバーでもあるCarter Reesは、VentureBeatに対し、枠組み自体を完全に変える必要があると述べました。「MCPのstdioはコネクタではなく特権的な実行サーフェスです。エンタープライズチームは、それを本番環境のシェルアクセスのように扱うべきです。デフォルト拒否、許可リスト、サンドボックス、そして、下流の入力バリデーションがスケール時にも成り立つと決めつけないこと――これが必要です」とReesは語りました。

IDEファミリーには特に注意が必要です。IDEはサーバーではなく、開発者の作業端末を直撃するからです。攻撃者が制御するWebサイトを閲覧した開発者は、ローカルのMCP設定ファイルへの変更を引き起こせます。そしてWindsurfのケースでは、その変更は承認プロンプトなしで即座に実行されます。Cursor、Claude Code、Gemini-CLIは何らかのユーザー操作を必要としますが、UIが実行の結果を表示せずに設定変更だけを提示しているなら、「approve（承認）」をクリックしても、十分に説明された同意にはなりません。

ベンダーはパッチを当てましたか？

当てたところもあります。部分的に当てたところもあります。未確認のままのところもあります。以下のマトリクスは、影響を受ける各製品を、悪用ファミリー、パッチの状態、そして残っているギャップと照合します。重要な列は「Protocol fix?（プロトコル修正は？）」です。すべての行で答えは「NO（いいえ）」です。

この欠陥はパッチ後も残るのか？

はい。マトリクス内の製品レベルのパッチはすべて、その製品における当該の侵入口を対象にしています。どれもMCPプロトコルのSTDIO動作を変更していません。今日LiteLLMをパッチして明日新しいMCP STDIOサーバーを構成するセキュリティ責任者は、新しいサーバーに対しても同じ不安全なデフォルトを継承します。パッチは必要です。しかしそれだけでは不十分です。

これは予測可能でした。VentureBeatが最初に MCPのセキュリティ上の欠陥について報告した（1月）の際、Enkrypt AIの最高セキュリティ責任者（Chief Security Officer）であり、AWSでの元CISO（副CISO）でもあるMerritt Baerは警告しました。「MCPは、私たちがあらゆる主要プロトコルの展開で見てきたのと同じミスを抱えて出荷されています。つまり、認証と最小特権が欠けた不安全なデフォルトです。もし初日から認証と最小特権を組み込まなければ、今後10年にわたって侵害の後始末をすることになります。」そして、Cloud Security Allianceが独立して確認したところ、OXの調査結果は別のリサーチノートでも裏付けられ、組織はMCP接続インフラを「アクティブで、未パッチの脅威」として扱うべきだと推奨されています。デフォルトは変わりませんでした。攻撃対象領域は拡大しました。

Reesは、Anthropicの立場は社内的には筋が通っていても、企業における現実との接触には耐えられないと主張しました。「それは開発者のミスで済まなくなります。同種の失敗が、これほど多くの独立した実装で再現すると、分散された障害モードになります」と彼はVentureBeatに語りました。「ガイダンスは建築（アーキテクチャ）上の統制ではありません。信頼境界の解釈を一貫させるために、何千という下流の実装者に依存することは、企業セキュリティにおける既知のアンチパターンです。」

Anthropicは、OXが1月に初めて接触してから9日後に自身のSECURITY.mdファイルを更新し、STDIOアダプタは注意して使用すべきだと記していましたが、アーキテクチャ上の変更は行いませんでした。研究者によるその更新の評価はこうです。「この変更は何も直していません。」

Reesはより慎重な見方をしました。「Anthropicにしかるべき評価を与える価値はあります」と彼はVentureBeatに語りました。「開示後、彼らはSTDIOアダプタについて注意を促すようにセキュリティガイダンスを更新しました。研究者がそれはプロトコルレベルの修正に足りないと主張していても、これは意味のある一歩です。」

プロトコルレベルで何が変わったのか？

何も変わっていません。Anthropicは、マニフェストのみの実行（manifest-only execution）、公式SDKにおけるコマンド許可リスト（allowlist）、またはその他のプロトコルレベルの緩和策を実装していません。OXは3つすべてを推奨していました。SECURITY.mdのガイダンス更新が唯一の変更です。OXの研究は2025年11月に始まり、4月15日の公開前に、生態系全体で30件以上の責任ある開示プロセスを含んでいました。

意見の相違は実質的です。Anthropicのアーキテクチャ上の主張は、その重みをそのまま受けるべきです。STDIOは、構成したマシン上でプロセスを起動するために設計されたローカルのサブプロセス・トランスポートです。Anthropicのモデルにおいて信頼境界は、構成ファイルを制御している相手にあります。もしMCP設定に書き込めるなら、定義上、そのマシンでコマンドを実行する権限を持つ誰かです。その論理に従えば、コマンドインジェクションのように見えるものは、意図したとおりに機能する「仕組み」です。プロトコルレベルでSTDIOが起動できるものを制限すると、任意のローカルプロセスを起動することがその目的である以上、トランスポートの中核機能を壊すことになるか、攻撃対象領域を起動されたプロセス自体へと置き換えることになります。「意見のない標準（unopinionated-standard）」という反論も擁護可能です。つまり、実行制約をハードコードした普遍的プロトコルは普遍性を失う、ということです。OXの反論は、彼らのアドバイザリでこう述べています。「責任を実装者に移しても、リスクは移転しません。それは単に、誰がそれを作ったのかを見えにくくするだけです。」

プロトコルレベルの修正を待たないでください。製品の内側にどのように収まっているかにかかわらず、すべてのMCP STDIO設定を信頼できない入力面（入力サーフェス）として扱ってください。

月曜朝のリメディエーション手順

列挙する。 開発（dev）、ステージング（staging）、本番（production）それぞれで、すべてのMCPサーバーのデプロイを特定する。開発者のホームディレクトリやIDE設定パス（~/.cursor/、~/.codeium/windsurf/、~/.config/claude-code/）でMCP設定ファイル（mcp.json、mcp_config.json）を検索する。MCPサーバーのバイナリと一致する実行中プロセスを列挙する。公開IPへの到達性があるSTDIOトランスポートを使用しているものをフラグ付けする。OXは公開IP上で7,000件を見つけました。環境には、あなたが知らないインスタンスがあるかもしれません。

パッチを当てる。 影響を受ける各製品を、そのパッチ済みリリースに固定する。LiteLLM v1.83.7-stableには、CVE-2026-30623の修正が含まれています。DocsGPT、Flowise、Bishengでも修正が出荷されています。WindsurfとLangchain-Chatchatは、2026年5月1日時点でも「報告済み」状態のままです。Cursorは、より以前の関連する開示（CVE-2025-54136）に対してパッチ済みですが、同じプロトコルのデフォルトを継承しています。この手順を実行する朝、各ベンダーのアドバイザリを必ず確認してください。

サンドボックス化する。 MCP対応の各サービスをホストOSから隔離する。サーバーにディスク全体へのアクセスやシェル実行の権限を決して与えないこと。Flowise/Upsonicの許可リスト回避により、「コマンドだけを制限すれば十分ではない」ことが証明されています。

レジストリを監査する。 サードパーティのレジストリからインストールしたすべてのMCPサーバーをレビューする。11件中9件のレジストリが、OXのPoCをセキュリティレビューなしで受理していました。投稿のレビュー手順が文書化されているレジストリを使用する。出所を検証できないMCPサーバーは削除する。

STDIO設定を信頼できないものとして扱う。 このステップは、将来のあらゆるパッチと、将来のあらゆる製品に耐えます。プロトコルレベルのデフォルトは変更されていません。すべてのSTDIOサーバー定義は、コマンド実行のための攻撃面（コマンド実行サーフェス）です。データベースのクエリに対するユーザー入力と同じように扱ってください。検証されるまでは敵対的（hostile）であると仮定します。

プロトコル修正を待てないほど、あなたの露出は差し迫っている

AnthropicとOX Securityは、MCPのSTDIOトランスポートを防御する責任がどこにあるべきかについて意見が異なっています。この相違は、今週中に解消されることはありません。今週解決できるのは、あなたのMCPデプロイが列挙され、パッチが適用され、サンドボックス化され、そしてそれらが持つ「信頼できない実行面」として扱われているかどうかです。

Reesの言葉を借りると、「ここでの中核の問いは、アーキテクチャ上の方針であって、エクスプロイトのペイロードではありません。」Baerは1月に、不安全なデフォルトがまさにこの結果を生むと警告していました。OXは、実行面として機能し得る設定フィールドを持ったまま動作しているサーバー20万件を記録しています。プロトコルの設計者は、それが意図したとおりに動作していると言っています。あなたの月曜朝の問いは、誰が正しいのかではありません。どのサーバーが露出しているのかです。