Nodeflare
記事一覧
MCPセキュリティ

MCPの脆弱性（CVE）一覧：SDK・サーバー・クライアントの44件と安全な最小バージョン【MCP Security・2026年10月版】

MCPのSDK・Inspector・mcp-remote・filesystem/gitサーバー・Claude Code・Cursor・stdio起動プラットフォームで公開された脆弱性44件を一覧化。影響範囲と修正版、安全な最小バージョン、アップグレード後に必要な設定、npm auditと自作スクリプトでの検証結果まで。

最終更新：2026年10月29日 ／ 対象：2026年10月28日までに公開されたアドバイザリ ／ MCP TypeScript SDK 1.x・2.x、MCP Python SDK 1.x・2.x、公式MCPサーバーと開発ツール、MCPクライアント

結論（30秒で読める要約）

MCPの脆弱性は、もう「たまに出る珍しいもの」ではありません。本記事では、MCP SDK、公式サーバーと開発ツール、MCPクライアント、設定からMCPサーバーを起動するプラットフォームで公開された44件のアドバイザリ（CVEとGitHub Security Advisory）を一覧にしました。MCP Securityで今週ひとつだけやるなら、手元で動いているものが次のバージョンより古くないかを確認してください。

コンポーネント 安全な最小バージョン（2026年10月29日時点） 理由
TypeScript SDK @modelcontextprotocol/sdk（1.x） 1.32.0 8件。うち5件は1.30.1〜1.32.0で修正
TypeScript SDK @modelcontextprotocol/server / client（2.x） 2.3.0 2パッケージで計6件
Python SDK mcp（1.x） 1.30.0 10件。セッション乗っ取りやトークンのaudience未検証を含む
Python SDK mcp（2.x） 2.2.0 2.x系にも及んだ6件
MCP Inspector 0.16.6 CVE-2025-49596（CVSS 4.0で9.4）、CVE-2025-58444
mcp-remote 0.1.16 CVE-2025-6514（CVSS 3.1で9.6）
mcp-server-git 2026.1.14 パス・引数インジェクション系のCVE 4件
@modelcontextprotocol/server-filesystem 2025.7.1（旧0.x系なら0.6.3） CVE-2025-53109、CVE-2025-53110
Claude Code 2.0.65 CVE-2025-59536、CVE-2026-21852
Cursor 1.3.9 CVE-2025-54135、CVE-2025-54136
LiteLLM 1.83.7-stable CVE-2026-30623

一覧にしてみると、3つの傾向がはっきり見えます。

  • 44件中18件（41%）は「信頼できない文字列がそのままコマンドとして実行される」タイプです。URL、設定の項目、ツール引数などが実行に回ってしまうもので、多くはstdioサーバーを起動するコードにあります。
  • 公式SDKは2言語とも、同じ4種類のバグ（トークンのaudience、OAuthのissuer紐付け、別オリジンへのリダイレクト、リクエストサイズ無制限）を1か月以内に修正しています。2026年半ばにSDKのバージョンを固定したままなら、ほぼ確実に該当します。
  • ほとんどはAI特有ではなく、昔からあるWebのバグです。プロンプトインジェクションが起点になるのは2件（CursorのCVE-2025-54135、WindsurfのCVE-2026-30615）だけで、残りは認証漏れ、所有者チェック漏れ、パストラバーサル、コマンドインジェクションです。

9章では、わざと古いバージョンで組んだ環境を実際に検査しました。npm audit は脆弱なパッケージを4件（critical 1件、high 3件）検出し、その中には古いサーバーの内部に入れ子で入っていたSDKも含まれていました。Python側は小さなスクリプトで補いました。

目次

  1. 「MCPの脆弱性」とは何を指すか
  2. MCP SDKの脆弱性（19件）
  3. 公式サーバーと開発ツール（9件）
  4. MCPクライアントとAIコーディングツール（5件）
  5. STDIO設定インジェクション系（11件）
  6. CVEのない事故：悪意あるパッケージとロジックの欠陥
  7. 44件に共通すること
  8. 自分の環境が影響を受けるかの確認手順
  9. 検証：古いMCP環境を実際に監査する
  10. パッチ運用チェックリスト（12項目）
  11. よくあるハマりどころ（症状→原因→対処）
  12. NodeFlareならこう解決できる
  13. FAQ

1. 「MCPの脆弱性」とは何を指すか

MCPの脆弱性とは、Model Context Protocolを実装・起動するソフトウェアのセキュリティ上の欠陥のことです。対象はSDK、MCPサーバー、MCPクライアントやホスト、InspectorやプロキシのようなMCP周辺のツールです。プロトコル仕様そのものにCVEが付くことはなく、CVEが付くのは実装の側です。

MCPの脆弱性は5つの層に分けられ、層ごとに直し方と気づき方が違います。

層 例 対応が必要な人 気づく方法
SDK @modelcontextprotocol/sdk、mcp（PyPI） そのSDKでサーバーやクライアントを作っている全員 npm audit、pip-audit、Dependabot
公式サーバー・開発ツール Inspector、filesystem、git、mcp-remote ローカルで動かしている開発者 同上＋modelcontextprotocol/servers のアドバイザリ
サードパーティのサーバー Figma、Kubernetes、AWS系など多数 インストールした人 GitHubのアドバイザリやブログ記事のみ、ということが多い
クライアント・ホスト Claude Code、Cursor、Windsurf そのクライアントの全利用者 ベンダーのリリースノート、自動更新
MCPサーバーを起動するプラットフォーム LiteLLM、Flowise、LangFlow プラットフォームの運用者 ベンダーのアドバイザリ

本記事では、SDKと公式コンポーネントは公開分をすべて、クライアントとプラットフォームは一次情報で確認できたCVEを載せています。サードパーティのサーバーまで網羅することはしていません。そちらはMCPサーバーのサンドボックス化の記事にある確認手順を使ってください。まだ見つかっていない次のCVEの被害を、隔離でどこまで抑えられるかもそこで解説しています。

2. MCP SDKの脆弱性（19件）

1つのバグがその上に作られた全サーバーに広がるため、公式SDKは最も重要な層です。両SDKとも、2025年12月（DNSリバインディング対策の初期値）と、2026年9〜10月にまとまってアドバイザリを出しています。

TypeScript SDK

アドバイザリ 種類 影響範囲 修正版 影響を受ける構成
CVE-2025-66414（GHSA-w48q-cv73-mx4w） DNSリバインディング対策が初期状態で無効 < 1.24.0 1.24.0 認証なしでlocalhostにHTTPで立てたサーバー
CVE-2026-0621（GHSA-cqwc-fm46-7fff） UriTemplate のReDoS < 1.25.2 1.25.2 {/id*} のような展開型のリソーステンプレートを持つサーバー
CVE-2026-25536（GHSA-345p-7cg4-v4c7）、CVSS 7.1 別クライアントへのレスポンス漏えい 1.10.0〜1.25.3 1.26.0 1つのtransportやserverインスタンスを複数クライアントで使い回す構成
GHSA-f897-62hf-6gxq、CVSS 7.5 リクエスト本文・バッチ数の上限なし 1.10.0〜< 1.30.1 1.30.1 信頼できないクライアントから届くHTTPサーバー
GHSA-6qxp-vccf-f47h、CVSS 7.5 OAuthクライアントが、サーバーの指定した認可サーバーへ資格情報を送る 1.12.0〜< 1.31.0 1.31.0 完全には信頼できないサーバーへ接続するOAuthクライアント
GHSA-6prh-2h8m-c8cw、CVSS 6.5 別オリジンへのリダイレクトでカスタムヘッダーを再送 < 1.32.0 1.32.0 独自の認証ヘッダーを使うHTTPクライアント
CVE-2026-111768（GHSA-46jr-4wx8-v453）、CVSS 7.5 4 MiB以内のリクエストでも検証中にメモリを使い切る 1.3.0〜1.31.0 1.32.0 配列やレコードを受け取るツール
GHSA-rvq5-wwqv-78pq、CVSS 6.8 Bearer認証が別サービス向けのトークンを受け入れる 1.6.0〜< 1.32.0 1.32.0 認可サーバーを他サービスと共用し、SDKのBearer認証を使うサーバー

2.x系のパッケージ（@modelcontextprotocol/server と @modelcontextprotocol/client）にも、2026年後半の同じバグが入っています。npm audit の結果では、serverパッケージにGHSA-46jr、GHSA-rvq5、GHSA-f897と、2.x固有のクライアント間配信バグ（GHSA-jm63-cq47-j5jp、CVSS 7.7）、clientパッケージにGHSA-6qxpとGHSA-6prhが出ます。どちらも 2.3.0（2026年10月2日リリース）で解消されます。

アップグレード後に設定が必要な修正が2つあります。GHSA-46jrでは、初期状態で無効の新オプション maxToolInputElements を有効にし、メッセージが小さいなら maxRequestBodySize も下げるよう案内されています。CVE-2025-66414の対策が自動で有効になるのは、localhostにバインドした createMcpExpressApp() で作ったサーバーだけです。Expressを独自に組んでいる場合は、エクスポートされている hostHeaderValidation() ミドルウェアを自分で入れます。

Python SDK

アドバイザリ 種類 影響範囲 修正版 影響を受ける構成
CVE-2025-66416（GHSA-9h52-p55h-vw2f） DNSリバインディング対策が初期状態で無効 < 1.23.0 1.23.0 認証なしでlocalhostに立てたFastMCPのHTTPサーバー
CVE-2026-52869（GHSA-jpw9-pfvf-9f58）、CVSS 7.1 セッションへのリクエストが認証済みの主体に紐付いていない ≤ 1.27.1 1.27.2 SDKのBearer認証を使うHTTPサーバー
CVE-2026-52870（GHSA-hvrp-rf83-w775）、CVSS 7.6 他クライアントのタスクを誰でも参照・キャンセルできる 1.23.0〜1.27.1 1.27.2 enable_tasks() を呼んでいるサーバー
CVE-2026-59950（GHSA-vj7q-gjh5-988w） WebSocket transportにHost/Origin検証がない < 1.28.1 1.28.1＋設定 非推奨のWebSocket transportを組み込んでいるアプリ
GHSA-fmmv-w9g8-j3gc、CVSS 7.5 リクエスト本文をサイズ上限なしで読み込む < 1.29.1、2.0.x 1.29.1、2.1.0 HTTPサーバーとOAuthエンドポイント
CVE-2026-59951（GHSA-84m7-p3x7-pcfv）、CVSS 7.5 ステートフルなセッションが回収されない 1.8.0〜< 1.30.0、2.0.0〜< 2.2.0 1.30.0、2.2.0 ステートフルなStreamable HTTPサーバー
CVE-2026-116684（GHSA-w4fh-qvv9-3v23）、CVSS 6.8 Bearer認証が別リソースサーバー向けのトークンを受け入れる 1.10.0〜1.29.1、2.0.0〜2.1.1 1.30.0、2.2.0＋設定 TokenVerifier が aud を確認していないサーバー
GHSA-qx49-fqc8-xw99、CVSS 7.5 OAuthクライアントの資格情報がissuerに紐付いていない 1.9.1〜< 1.30.0、2.0.0a1〜< 2.2.0 1.30.0、2.2.0＋設定 信頼できないサーバーへ接続するOAuthクライアント
CVE-2026-116685（GHSA-5h93-6whr-6q8j）、CVSS 5.9 別オリジンへのリダイレクトでカスタムヘッダーを送る 1.8.0〜< 1.30.0、2.0.0〜< 2.2.0 1.30.0、2.2.0 独自の認証ヘッダーを使うHTTPクライアント
CVE-2026-116686（GHSA-rwrf-2pqf-9j8j）、CVSS 6.5 サーバーが指定した $ref のURLをクライアントが取得する（SSRF） 1.10.0〜< 1.30.0、2.0.0〜< 2.2.0 1.30.0、2.2.0 信頼できないサーバーの、outputSchema 付きツールを呼ぶクライアント

アドバイザリによると、次の3つはコードや設定を変えないと対策が完了しません。

  • トークンのaudience（CVE-2026-116684）：AuthSettings で validate_token_resource=True と resource_server_url を設定し、さらに verify_token() でトークンのaudienceを AccessToken.resource として返します。前半だけ行うと、すべてのリクエストが401になります。
  • OAuthのissuer紐付け（GHSA-qx49）：ClientCredentialsOAuthProvider または PrivateKeyJWTOAuthProvider に issuer= を渡し、保存済みのクライアント登録を一度消して再登録させます。信頼できないサーバーとやり取りした可能性があるクライアントは、シークレットもローテーションします。
  • WebSocket（CVE-2026-59950）：アップグレードしただけでは保護が有効になりません。enable_dns_rebinding_protection=True を指定した TransportSecuritySettings を渡すか、Streamable HTTPへ移行します。

両SDKのaudienceのバグは、MCPセキュリティテスト計画のテストA4（別リソース向けに発行された正規トークンを送る）でちょうど検出できる種類のものです。

3. 公式サーバーと開発ツール（9件）

これらは開発者のPC上で、たいていその開発者のファイルやネットワークへのアクセス権をすべて持ったまま動きます。一覧の中でスコアが最も高いのがこの層なのはそのためです。

CVE コンポーネント 種類 影響範囲 修正版 スコア
CVE-2025-49596 MCP Inspector Inspectorのクライアントとプロキシ間に認証がなく、RCEにつながる < 0.14.1 0.14.1 CVSS 4.0で9.4
CVE-2025-58444 MCP Inspector 信頼できないサーバーの不正なリダイレクトURIによるXSSからコマンド実行 < 0.16.6 0.16.6 CVSS 4.0で8.6
CVE-2025-6514 mcp-remote 細工された authorization_endpoint によるOSコマンドインジェクション 0.0.5〜0.1.15 0.1.16 CVSS 3.1で9.6
CVE-2025-53109 server-filesystem シンボリックリンクによるパス検証の回避 < 0.6.3、< 2025.7.1 0.6.3、2025.7.1 CVSS 4.0で8.4
CVE-2025-53110 server-filesystem 前方一致するパスによるパス検証の回避 < 0.6.3、< 2025.7.1 0.6.3、2025.7.1 CVSS 4.0で7.3
CVE-2025-68143 mcp-server-git git_init が任意のパスを受け付けた < 2025.9.25 2025.9.25（ツール自体を削除） CVSS 4.0で6.5
CVE-2025-68144 mcp-server-git git_diff / git_checkout の引数インジェクション < 2025.12.18 2025.12.18 CVSS 3.1で8.1
CVE-2025-68145 mcp-server-git --repository 指定時のパス検証漏れ < 2025.12.18 2025.12.18 CVSS 3.1で7.1
CVE-2026-27735 mcp-server-git git_add がリポジトリ外のファイルをステージできた < 2026.1.14 2026.1.14 CVSS 4.0で6.4

実務上の注意が2つあります。The Hacker Newsによると、gitサーバーのCVEはCyataが2025年6月に報告し、修正は7か月がかりでした。「去年の夏に更新した」だけでは足りません。もう1つは server-filesystem のバージョン体系の変更です。2026.8.31 までは日付形式でしたが、2026年10月11日に 1.0.0、10月28日に 2.1.0 が公開されました。自作のチェックで 2.1.0 < 2025.7.1 を数値で比べると、最新版を脆弱と判定してしまいます。npm audit は正しく扱い、脆弱な範囲を <=0.6.2 または 2025.1.14 - 2025.3.28 と表示します。

4. MCPクライアントとAIコーディングツール（5件）

どのサーバーをどのコマンドで起動するかを決めるのはクライアントなので、クライアントのCVEは重要です。次の5件はいずれも、リポジトリやサーバーが用意した内容が、コマンド実行や資格情報の漏えいにつながったものです。

CVE クライアント 種類 修正版 スコア
CVE-2025-59536 Claude Code 起動時の信頼ダイアログを承認する前に、プロジェクトのMCPサーバーやhooksが実行され得た 1.0.111 CVSS 3.1で8.8
CVE-2026-21852 Claude Code リポジトリが ANTHROPIC_BASE_URL を設定し、信頼確認の前にAPIキーが漏れ得た 2.0.65 出典に記載なし
CVE-2025-54135（CurXecute） Cursor 任意コード実行。MCP設定を書き換えるプロンプトインジェクションから到達できると報告 1.3.9 CVSS 3.1で8.5
CVE-2025-54136（MCPoison） Cursor 検証されないMCP設定の変更によるリモートコード実行 1.3 CVSS 3.1で7.2
CVE-2026-30615 Windsurf プロンプトインジェクションからMCP設定の書き換え（OX Securityの一覧より） ベンダー情報を参照 Critical（OXによる）

Claude Codeの2件はCheck Point Researchが報告し、TenableはCurXecuteをAIM Security、MCPoisonをCheck Pointの発見としています。5件に共通する教訓は、プロジェクト単位のMCP設定（.mcp.json、.cursor/mcp.json など）をコードとして扱うことです。プルリクエストでレビューし、プロジェクトのサーバーを自動起動するエージェントで、信頼できないリポジトリを開かないようにします。

5. STDIO設定インジェクション系（11件）

一覧で最大のグループは、1つの調査から生まれました。2026年4月、OX Securityは、多くのAIプラットフォームでユーザーや外部入力がstdio MCPサーバーの設定（command と args）に届き、SDKがそれをサブプロセスとして実行してしまうことを公表しました（OXのアドバイザリは StdioServerParameters を名指ししています）。OXの報告では、影響を受けるサプライチェーンのダウンロード数は1億5,000万以上、公開アクセス可能なサーバーは7,000以上、脆弱なインスタンスは最大20万です。

CVE 製品 状況（OXまたはベンダーによる）
CVE-2026-30623 LiteLLM 1.83.6-nightly と 1.83.7-stable で修正
CVE-2025-65720 GPT Researcher 3.3.7〜3.4.4が影響
CVE-2026-30624 Agent Zero 全バージョンが影響とされる
CVE-2026-54449 LangBot 4.10.0まで
CVE-2026-30618 Fay 4.3.1
CVE-2026-33224 Bisheng 未確定
CVE-2026-30616 Jaaz 1.0.30
CVE-2026-30617 Langchain-Chatchat 0.3.1
CVE-2026-30625 Upsonic npx/npm の引数による許可リストの回避。0.72.0で警告を追加
CVE-2026-40933 Flowise 許可リストの回避。3.1.0より後のバージョン
CVE-2026-26015 DocsGPT ネットワーク経由で隠れたstdio設定を注入。公式サイト側で修正済み

大事なのは「誰が直すのか」という点です。OXはAnthropicのMCPを「修正を拒否された開示」に分類し、The RegisterはAnthropicが「プロトコルのアーキテクチャ変更を断り、この挙動を『想定どおり』とした」と報じています。一方、MCPのSecurity Best Practicesは、すでに起動する側に責任を置いています。ワンクリックでローカルサーバーを設定できるクライアントは、実行するコマンドを省略せずに表示し、明示的な承認を得なければなりません（MUST）。stdioサーバーを起動するプロキシは、起動したプロセスをサンドボックス化し、危険なコマンドには追加の認可を求めるべき（SHOULD）とされています。

MCPサーバーを起動するプラットフォームを作っているなら、次の3点を守ってください。

  • リクエストのデータ、チャットの内容、管理者以外のユーザーに command や args を決めさせない。LiteLLMの修正は、コマンドを許可リスト（npx、uvx、python、python3、node、docker、deno）に限定し、テスト用エンドポイントを PROXY_ADMIN ロール限定にしました。
  • コマンドの許可リストだけに頼らない。UpsonicとFlowiseのCVEは、起動コマンドの引数を使った許可リストの回避です。
  • 起動したサーバーは1つずつ、専用のファイルシステムとネットワークポリシーを持つサンドボックスで動かす。インジェクションが成功しても、盗めるものが何もない場所で止まります。stdioサーバーを開発者のPCから切り離す方法は、stdio MCPサーバーをリモートで動かす手順で解説しています。

6. CVEのない事故：悪意あるパッケージとロジックの欠陥

MCP Securityで特に学びの多い事故のいくつかにはCVEが付いていません。そのため、CVEスキャナーには一切出てきません。

事故 何が起きたか（出典による） スキャナーで見つからない理由 効く対策
postmark-mcp（2025年9月） バージョン1.0.16に1行の変更が入り、サーバー経由で送るすべてのメールを外部アドレスにBCCしていた。削除までに1,643ダウンロード（Koi Security、The Hacker News経由） 脆弱性ではなく悪意あるコード バージョンの完全固定、更新前の差分確認、最小権限のAPIキー
AsanaのMCPサーバー（2025年） ロジックの欠陥で一部データが他組織のユーザーから見えた。Asanaの推計で約1,000社に影響（BleepingComputer） ホスティング型のサービスで、スキャンするパッケージがない 2テナントを使った認可テスト
レジストリ汚染の検証（2026年） OXの報告では、11のMCPレジストリのうち9つが悪意あるテスト用パッケージを受け入れた レジストリの運用方針にはCVEが付かない 確認済みの公開者からだけインストールし、導入前に審査する

postmark-mcp の件は、ネットワーク制御の限界を確かめるのにも役立ちます。コピーは本来使うはずのメールAPIそのものを通って送られていたので、そのAPIを許可するEgressの許可リストでは止められませんでした。止められたのは、バージョン固定と差分レビューです。

7. 44件に共通すること

44件を根本原因で分類すると、どこに力を入れるべきかが見えてきます。

バグの種類 件数 例 まず入れる対策
信頼できない文字列がコマンドになる（URL、設定の項目、引数） 18 CVE-2025-6514、CVE-2025-68144、CVE-2025-59536、STDIO系の11件 信頼できない入力を起動処理やシェルに渡さない。起動したサーバーはサンドボックス化
トークンとOAuthの信頼（audience、issuer、リダイレクト、キー漏えい） 7 CVE-2026-116684、GHSA-rvq5、GHSA-qx49、CVE-2026-21852 aud を検証、クライアントをissuerに紐付け、リダイレクトは同一オリジンのみ
パストラバーサルと範囲外へのアクセス 5 CVE-2025-53109、CVE-2025-68145、CVE-2026-27735 パスを正規化してから判定、ファイル系サーバーのマウントは最小限
リソース枯渇 5 CVE-2026-0621、CVE-2026-59951、GHSA-46jr 本文サイズの上限、セッション数の上限、レート制限
認証なしのローカルリスナー 4 CVE-2025-49596、CVE-2025-66414、CVE-2025-66416 ローカルはstdioを優先。HTTPならトークン必須にしてOrigin/Hostを検証
クライアント間・セッション間の分離 4 CVE-2026-25536、CVE-2026-52869、CVE-2026-52870 セッションごとにserverとtransportを作る。状態は検証済みユーザーに紐付ける
クライアント側のSSRF 1 CVE-2026-116686 信頼できないサーバーが示すリモート参照を解決しない

この表からわかることが2つあります。1つは、AI特有のものがほとんどなく、必要な対策は普通のWebサービスと同じだということです。もう1つは、SDKのアドバイザリの山（2025年12月と2026年9〜10月）が、2言語でほぼ同時期に修正されていることです。足並みをそろえた堅牢化が行われていると考えられるので、片方のSDKでアドバイザリが出たら、同じ週にもう片方のchangelogも確認しましょう。

8. 自分の環境が影響を受けるかの確認手順

次の順番で5つの層を確認します。前の手順ほど手間が小さいので、この順が効率的です。

  1. 棚卸し：MCPのコードが動く場所をすべて書き出します。Nodeのプロジェクト、Pythonの環境、グローバルインストール（npm ls -g）、クライアントの設定ファイル（.mcp.json、claude_desktop_config.json、.cursor/mcp.json）、LiteLLMやFlowiseのようなプラットフォームです。
  2. パッケージ監査ツールを回す：Nodeのプロジェクトごとに npm audit、Pythonの環境ごとに pip-audit（またはPyPIのJSON APIの vulnerabilities 項目）を確認します。自分で直接入れていない、依存関係の中のコピーも見つかります。
  3. クライアントのバージョンを確認する：Claude Codeは claude --version、CursorとWindsurfは「About」画面で確認します。多くのクライアントは自動更新が初期設定ですが、管理された端末やオフラインの端末は遅れがちです。
  4. npx と uvx での起動を確認する：npx -y some-mcp-server のようにバージョンなしの設定は起動時点の最新版を動かし、npx some-mcp-server@0.1.15 のような設定はいつまでも脆弱な版のままです。バージョンは完全に固定し、意図して更新します。
  5. アップグレード後の設定を入れる：2章のとおり、オプトインになっている修正がいくつかあります。

9. 検証：古いMCP環境を実際に監査する

2026年10月29日に、Nodeのプロジェクト3つとPythonのパッケージ一覧3つを用意し（Node 22.23、npm 10.9.9、Python 3.13）、標準的なツールで何が見つかるかを確かめました。

古いNodeプロジェクトには @modelcontextprotocol/sdk@1.23.0、mcp-remote@0.1.15、@modelcontextprotocol/server-filesystem@2025.3.28 を入れました。npm audit の結果は次のとおりです。

パッケージ 深刻度 報告された脆弱な範囲
@modelcontextprotocol/sdk High <=1.31.0（8件）
@modelcontextprotocol/server-filesystem High <=0.6.2 または 2025.1.14 - 2025.3.28
mcp-remote Critical 0.0.5 - 0.1.15
zod High <4.6.6

インストールしたコマンドからは予想しにくい発見が2つありました。古いfilesystemサーバーは内部にSDKのコピー（@modelcontextprotocol/sdk@0.5.0）を入れ子で持っていて、これはトップレベルのSDKを上げても直りません。また、SDKが依存する zod にも独自のメモリ枯渇のアドバイザリがありました。修正版で組んだプロジェクト（最新のSDKと mcp-remote、server-filesystem@2.1.0）は脆弱性0件でした。

npm audit はPython、クライアント、プラットフォームを見ないので、本記事冒頭の表と、インストール済みのバージョンを突き合わせる小さなスクリプトを用意しました。npm ls --all --json と pip list --format json の出力を読み込みます。

#!/usr/bin/env python3
"""mcp_cve_check.py - flag MCP packages older than the first fixed release
(table as of 2026-10-29). Standard library only.
usage: npm ls --all --json > npm.json ; pip list --format json > pip.json
       python3 mcp_cve_check.py npm.json pip.json"""
import json, re, sys

def ver(s):
    return tuple(int(x) for x in re.findall(r"\d+", s.split("-")[0])[:4])

ANY = lambda v: True
NPM = {
    "@modelcontextprotocol/sdk":       [(ANY, "1.32.0")],
    "@modelcontextprotocol/server":    [(ANY, "2.3.0")],
    "@modelcontextprotocol/client":    [(ANY, "2.3.0")],
    "@modelcontextprotocol/inspector": [(ANY, "0.16.6")],
    "mcp-remote":                      [(ANY, "0.1.16")],
    # date-based versions until 2026.8.31, semver again from 1.0.0 (2026-10-11)
    "@modelcontextprotocol/server-filesystem": [
        (lambda v: v[0] == 0, "0.6.3"), (lambda v: v[0] >= 2000, "2025.7.1")],
}
PIP = {
    "mcp": [(lambda v: v[0] == 1, "1.30.0"), (lambda v: v[0] == 2, "2.2.0")],
    "mcp-server-git": [(ANY, "2026.1.14")],
    "litellm": [(ANY, "1.83.7")],
}

def walk(node, out):
    for name, dep in (node.get("dependencies") or {}).items():
        if "version" in dep:
            out.append((name, dep["version"]))
        walk(dep, out)
    return out

bad = 0
for path in sys.argv[1:]:
    data = json.load(open(path))
    eco, table = ("pip", PIP) if isinstance(data, list) else ("npm", NPM)
    found = [(p["name"].lower(), p["version"]) for p in data] if eco == "pip" else walk(data, [])
    for name, v in found:
        for applies, minimum in table.get(name, []):
            if applies(ver(v)) and ver(v) < ver(minimum):
                print(f"VULNERABLE {eco} {name}@{v} -> upgrade to >= {minimum}")
                bad += 1
print(f"{bad} vulnerable package(s)" if bad else "no known-vulnerable MCP packages")
sys.exit(1 if bad else 0)

4種類の入力での結果です。

入力 結果 終了コード
古いNodeプロジェクト＋Python一覧（mcp 1.27.1、mcp-server-git 2025.12.18、litellm 1.83.5） 7件検出。入れ子の sdk@0.5.0 も含む 1
@modelcontextprotocol/server@2.0.0 と client@2.0.0 を入れたNodeプロジェクト 2件検出 1
mcp 2.1.1 のみ 1件検出（2.2.0が必要） 1
修正版のNodeプロジェクト＋Python一覧（mcp 2.3.0、mcp-server-git 2026.10.28、litellm 1.83.7） 0件。server-filesystem@2.1.0 も正しく対象外 0

限界もあります。このスクリプトが知っているのは上の表だけなので、新しいアドバイザリが出たら更新が必要です。正としては npm audit と pip-audit を使い、このスクリプトはそれらが見ないPythonパッケージやプラットフォームまで含めて止めるCIのゲートとして使ってください。また、Claude CodeやCursorのようなクライアントは、これらのパッケージマネージャーで入れるものではないので確認できません。

10. パッチ運用チェックリスト（12項目）

棚卸し

  • [ ] MCPのコードを含むNodeプロジェクト、Python環境、グローバルインストールをすべて把握している
  • [ ] クライアントの設定ファイル（.mcp.json、claude_desktop_config.json、.cursor/mcp.json）を、サーバーと起動コマンドつきで一覧にしている
  • [ ] npx/uvx での起動はすべてバージョンを完全に固定している

検出

  • [ ] npm audit と pip-audit をCIで回し、MCP関連のhigh・criticalでビルドを失敗させている
  • [ ] DependabotかRenovateで @modelcontextprotocol/* と mcp を監視している
  • [ ] SDKと servers リポジトリのセキュリティアドバイザリを誰かが購読している

修正

  • [ ] TypeScript SDKは1.32.0以上（1.x）または2.3.0以上（2.x）、Python SDKは1.30.0以上（1.x）または2.2.0以上（2.x）
  • [ ] アップグレード後の設定を入れた：Pythonの validate_token_resource と issuer=、TypeScriptの maxToolInputElements、WebSocketの TransportSecuritySettings
  • [ ] Inspectorは0.16.6以上、mcp-remote は0.1.16以上、mcp-server-git は2026.1.14以上、server-filesystem は2025.7.1以上
  • [ ] 信頼できないサーバーへ資格情報を送った可能性があるとアドバイザリが示すケースでは、資格情報をローテーションした

封じ込め

  • [ ] ローカルのサーバーはstdioか、トークン必須でOrigin/Hostを検証するHTTPにしている。認証なしでlocalhostに待ち受けているものはない
  • [ ] MCPサーバーを起動するプラットフォームは、管理者以外の入力から command や args を受け付けず、サーバーごとにサンドボックスで動かしている

11. よくあるハマりどころ（症状→原因→対処）

症状 原因 対処
SDKを上げたのに監査で引っかかり続ける サーバーのパッケージが自前のSDKのコピーを入れ子で持っている 親のパッケージを上げる。npm ls @modelcontextprotocol/sdk で確認
スキャナーが server-filesystem@2.1.0 を脆弱と判定する 自作のチェックがsemverと日付形式を数値で比べている npm audit の範囲を使うか、1.x/2.xは2026年以降のリリースとして扱う
Python SDKを上げたら全リクエストが401になる validate_token_resource=True だけ設定し、AccessToken.resource を返していない アドバイザリの2つの変更をセットで入れる
修正後も古いサーバーが動き続ける 設定が npx some-server@<古い版> のまま、またはグローバルのキャッシュが残っている 修正版に固定してクライアントを再起動
上げたのにWebSocketサーバーが別オリジンのページを受け入れる 1.28.1では security_settings の初期値が None TransportSecuritySettings を渡すか、Streamable HTTPへ移行
LiteLLMを上げたらstdioサーバーが起動しない コマンドが新しい許可リストにない 許可された起動コマンドを使うか、LITELLM_MCP_STDIO_EXTRA_COMMANDS に追加
「最新版」だったパッケージに悪意あるコードが入っていた 脆弱性ではなく悪意あるリリース バージョンを完全固定し、更新前に差分を確認
ローカルの開発ツール経由で開発者のPCが侵害された InspectorやローカルのHTTPサーバーが認証なしで待ち受けていた ツールを更新し、stdioにするかトークン必須にする

12. NodeFlareならこう解決できる

NodeFlareはMCPサーバーをリモートでホストし、サーバーごとに専用のFirecracker microVMで動かします。前段のプロキシが、リクエストがコードに届く前に認証・認可・レート制限・ログ記録を行います。一方で、依存パッケージを代わりに更新することはなく、イメージやパッケージのCVEスキャンも行いません（ドキュメントにどちらの記載もありません）。プロンプトインジェクションを防ぐこともできません。NodeFlareで変わるのは、未修正のバグや未知のバグが「どこまで届くか」です。本記事で挙げたバグの種類と、ドキュメントに記載された機能の対応は次のとおりです。

本記事のリスク NodeFlareの機能 内容
認証なしのローカルリスナー（CVE-2025-49596、CVE-2025-66414、CVE-2025-66416） プロキシ認証つきのリモートホスティング そもそもサーバーが開発者のPC上にありません。呼び出し側には mcp_* APIキーかOAuthトークンが必要で、転送前に検証されます。キーはハッシュ化して保存され、同じIPから誤ったキーが繰り返されるとそのIPを10分間ロックアウトします
URLを知っていれば誰でもエンドポイントに届く 送信元IPの許可リスト restricted ポリシーにすると、登録したIPv4/IPv6のCIDRだけを受け付けます。認証より前、VMの起動より前にプロキシで判定し、リストが空ならすべて拒否します。ネットワークアクセス制限はProプラン以上で使えます
文字列がコマンドになる、パストラバーサル（18件＋5件） サーバーごとのFirecracker microVM インジェクションが成功しても、実行されるのはそのサーバー専用のmicroVMの中です。SSHキーや他のサーバーがある開発者の端末上ではありません
侵害後に攻撃者のホストへデータが送られる Egress制御 モードは off（初期値）、observe、enforce。許可リストは最大100件（完全なホスト名、先頭1つのワイルドカード（例：*.example.com）、IPアドレス）で、DNSとnftablesによりホスト側で強制します。ただし postmark-mcp のように正規のメールAPI経由でコピーされるケースは止められません
自分のサーバーコード内のクライアント分離やaudienceのバグ ツール単位のスコープと一覧の絞り込み tools:call:<ツール名>、resources:read:<uri>、prompts:get:<name> といったスコープをリクエストごとにプロキシで確認し、拒否した呼び出しはJSON-RPCエラーを返してサーバーに届けません。tool_list_filter_by_scope で tools/list を呼び出せるツールだけに絞れます
リソース枯渇（5件） レート制限、クォータ、支出上限 IPごとの毎分リクエスト数の上限、ワークスペースの月間クォータ、任意で設定できるサーバーごとの月間支出上限があります。ワークスペースの支出上限に達するとHTTP 402を返します
侵害されたサーバーのビルドやログからシークレットが漏れる 暗号化された環境変数 保存時に暗号化され、VMの起動時にだけ注入されます。ビルド引数、イメージレイヤー、ログには書き込まれず、ビルドログでは既知のトークン形式の文字列を伏せ字にします
悪用の試みに気づく リクエストログ リクエストごとに mcp_method、tool_name、arg_keys（キー名のみ）、http_status、outcome（scope_denied や rate_limited など）、caller_kind、client_ip を記録します。保存期間はFreeが7日、ProとTeamが30日です

はっきりさせておくべき限界もあります。サーバー内部のSDKは自分で更新する必要があります。CVE-2026-52869のようなセッション間のバグは自分のコードの中にあり、NodeFlareのスコープ確認で分かるのは「どのツールが呼ばれたか」で、「どのセッションに触れたか」ではありません。auth_enabled = false にすると呼び出し側の資格情報がそのままサーバーに渡り、NodeFlareのスコープ確認は効かなくなるので、SDK自体の認証バグ（CVE-2026-116684、GHSA-rvq5）がふたたび問題になります。また、NodeFlareのドキュメントにはOrigin検証、リクエスト本文のサイズ上限、依存関係のスキャンについての記載がないため、これらはサーバー側とCIで対策してください。

最小の始め方：

  1. npm audit / pip-audit を回し、冒頭の表のバージョンまで上げる。
  2. サーバーをNodeFlareにデプロイし、呼び出し元ごとに必要な tools:call:<ツール名> だけを持つ mcp_* キーを発行して、tool_list_filter_by_scope を有効にする。
  3. Egressを1週間 observe で動かし、観測したホストで enforce に切り替える。

1サーバーまで無料で試せます：NodeFlareを始める

13. FAQ

これまでで最も深刻なMCPの脆弱性は？

スコアで見ると、公式コンポーネントでは mcp-remote のCVE-2025-6514（CVSS 3.1で9.6）とMCP InspectorのCVE-2025-49596（CVSS 4.0で9.4）が最も高く、どちらも信頼できないサーバーやWebページから開発者のPCでコマンドを実行され得るものです。影響の広さで見ると、2026年4月のSTDIO設定インジェクション系が最大で、AIプラットフォームにまたがる11件のCVEがあります。

どのバージョンのMCP SDKなら安全ですか？

2026年10月29日時点では、@modelcontextprotocol/sdk は1.32.0以上、TypeScriptの2.x系パッケージは2.3.0以上、Pythonの mcp は1.30.0以上または2.2.0以上を使ってください。Pythonの validate_token_resource やTypeScriptの maxToolInputElements のように、アップグレード後に設定が必要な修正もあります。

ローカルのMCPサーバーはDNSリバインディングの影響を受けますか？

認証なしでlocalhostにHTTPで立てている場合だけです。TypeScript SDKの1.24.0より前（CVE-2025-66414）とPython SDKの1.23.0より前（CVE-2025-66416）は、DNSリバインディング対策が初期状態で無効でした。stdioのサーバーは影響を受けないため、ローカルで使うならstdioのほうが安全です。

MCPのSTDIOの「仕様どおり」問題は、SDKのCVEですか？

いいえ。OX Securityの2026年4月の調査で付いたCVEは、LiteLLM（CVE-2026-30623）のように、信頼できない入力をstdioの起動コマンドに届かせてしまった製品に割り当てられています。AnthropicはSDKの挙動を想定どおりとしており、MCPのSecurity Best Practicesも、起動コマンドを表示して承認を得る責任をクライアントや起動側に置いています。

自分のMCP環境が影響を受けているか、どう確認すればよいですか？

Nodeのプロジェクトごとに npm audit、Pythonの環境ごとに pip-audit を実行し、クライアントのバージョンを確かめ、クライアントの設定ファイルにバージョン未固定の npx や uvx がないかを見ます。結果を本記事冒頭の最小バージョン表と比べ、アドバイザリが求めるアップグレード後の設定も入れてください。

npm auditでMCPの脆弱性は見つかりますか？

npmのパッケージなら見つかります。今回の検証では、SDK、mcp-remote、古い server-filesystem、入れ子になったSDKのコピーを検出し、修正版では0件でした。ただしPythonのパッケージ、AIクライアント、LiteLLMのようなプラットフォームは対象外なので、pip-audit とクライアントのバージョン確認を組み合わせてください。

リモートのMCPサーバーはローカルより安全ですか？

1種類のリスクはなくなります。リモートのサーバーは開発者のPCのファイルを読めず、localhostへのDNSリバインディングで狙われることもありません。その代わり、トークンのaudienceやテナント間のバグといった別のリスクが加わります。隔離された環境で動き、すべてのリクエストで認証を求め、最新のSDKを使っていれば、リモートのほうが安全と言えます。

スキャナーが @modelcontextprotocol/server-filesystem の2.xを脆弱と判定するのはなぜ？

このパッケージは日付形式のバージョン（最後は 2026.8.31）から、2026年10月11日の 1.0.0 を起点とするセマンティックバージョニングに切り替わりました。2.1.0 と 2025.7.1 を数値で比べるチェックでは、古い版に見えてしまいます。1.x と 2.x は2025年7月の修正より後のリリースで、npm audit も検出しません。

MCPの脆弱性の悪用には、プロンプトインジェクションが必要ですか？

ほとんどの場合、不要です。この一覧でプロンプトインジェクションが起点になるのは、CursorのCVE-2025-54135とWindsurfのCVE-2026-30615の2件だけです。残りは、悪意あるサーバーの応答、細工したURL、リポジトリの設定ファイル、Webページ、HTTPリクエストといった普通の入力で悪用されます。

新しいMCPのCVEはどこで追えばよいですか？

modelcontextprotocol/typescript-sdk、python-sdk、servers、inspector の各リポジトリのSecurityタブを確認し、@modelcontextprotocol/* と mcp にDependabotのアラートを設定し、使っているクライアントのリリースノートを追ってください。GitHub Advisory Databaseには、リポジトリのページにまだ出ていないSDKのアドバイザリが載ることがあり、今回の検証でも npm audit がそこからTypeScriptのアドバイザリ5件を見つけました。

まとめ

MCPの脆弱性は、いまや波のように押し寄せています。SDK、公式サーバー、クライアント、起動プラットフォームにまたがる44件のアドバイザリがあり、公式SDKは同じ種類のバグを2言語で数週間のうちに修正しています。大半は昔ながらのWebのバグで、最も多いのは信頼できない文字列がコマンドになるもの（44件中18件）です。やるべきことは多くありません。冒頭の表の最小バージョンまで上げ、オプトインの設定を入れ、npx と uvx の起動をすべてバージョン固定し、CIで npm audit と pip-audit を回し、ローカルのサーバーはstdioかトークン必須にします。そのうえで、次のCVEはすでに手元のどこかに入っていると考え、見つかったときに被害が広がらないようサーバーを隔離しておきましょう。

参考資料（一次情報）

NodeFlare

MCP専用ホスティングサービス

GitHubにあるMCPを簡単デプロイ・簡単運用で最適化
無料で始める

他の記事

MCPトークン2026年10月29日

スクリーンショットとスナップショット、安いのはどっち？ブラウザ操作MCPのトークン消費を実測【Playwright MCP・2026年版】

ブラウザ系MCPのスクリーンショットとアクセシビリティスナップショットは実際に何トークン使うのか。Playwright MCP v0.0.83での3ページの実測値、Claudeの28pxパッチ式と標準・高解像度ティア、78倍になるbase64テキスト化の落とし穴、Claude Sonnet 5.5での30ステップのコスト表、節約に効く設定をまとめました。

MCPセキュリティ2026年10月28日

MCPツール承認の設計：人が確認すべき呼び出し、クライアント別の自動承認設定、サーバー側の確認ゲート【MCP Security 2026】

MCPのツール呼び出しのうち、どれに人の承認が必要かを決める方法。2026-07-28版仕様のルール、確認の93%が承認される「承認疲れ」、4段階の承認ティア、Claude Code・Cursor・VS Code・Gemini CLI・OpenAIの自動承認設定、引数に結びつけた検証済みの確認ゲート。

MCPホスティング2026年10月28日

MCP Hostingのメモリ設計：MCPサーバーに必要なRAMを10種類・npx/uvx・ブリッジ別に実測【2026年版】

MCPサーバーに必要なメモリを10種類で実測。待機中61〜105 MB、npx・uvxで約45〜50 MB増、supergateway・mcp-proxyで125〜140 MB、ステートフルは1セッション約40 MB増、fetchはピーク348 MB。Cloud Run・Lambda・Workersの上限、1.5倍ルールでの段階選び、GB時間の料金計算、測定スクリプトまで解説。

他の記事を読む
MCPの脆弱性（CVE）一覧：SDK・サーバー・クライアントの44件と安全な最小バージョン【MCP Security・2026年10月版】 | Blog | Nodeflare