Context7 脆弱性ContextCrush（CVE-2026-75130）｜MCP配信悪用の手口と時系列

Context7 脆弱性「ContextCrush」（CVE-2026-75130）が、2026年8月18日にNVDへ公開された。Context7は Upstash社が開発する MCP（Model Context Protocol）ドキュメント配信サーバーで、Claude Code・Cursor・Windsurfなど30以上のAIコーディングツールから利用される、いわば「MCPドキュメント配信の定番」だ。GitHub実測（2026-08-18時点）で★60,940・フォーク2,937、ライセンスはMIT。この記事では、その”正規の配信チャネル”そのものが攻撃経路になった仕組みを、公式アドバイザリとNVD一次情報から時系列で整理し、自分のMCP構成を点検する確認コマンドを提示する。

同種の「AI連携機能が攻撃者にとっての新しい配信経路になる」構図を体系的に押さえたい場合は、サプライチェーンセキュリティ2026｜攻撃手法・防御ツール・実践チェックリストを合わせて読んでほしい。ContextCrushは、MCPサーバー自体の実装欠陥（プロトコル層）ではなく、特定SaaSプラットフォームのアプリケーション層で起きたサプライチェーン型攻撃という点で、本記事末尾で比較する他のMCP関連脆弱性とレイヤーが異なる。

Context7とは：AIコーディングツールが使うMCPドキュメント配信サーバー

Context7（開発元 Upstash, Inc.・リポジトリ upstash/context7）は、サーバーレスRedis/DBで知られるUpstash社が公開する、ライブラリの最新ドキュメント・コード例をMCP経由でAIエージェントに配信するサービスだ。TypeScript製で、GitHub実測（2026-08-18時点）では★60,940・フォーク2,937、ライセンスはMIT（LICENSEファイルの記載と一致確認済み）。直近のpushも当日にあたり、npmパッケージ群（@upstash/context7-mcp・CLIのctx7・エディタ連携の@upstash/context7-opencode等）も継続的にリリースされている、企業がホスティングも兼ねて運用する活発なプロジェクトだ。

Context7の基本的な役割は、AIコーディングアシスタントが「そのライブラリの最新の使い方」を参照する際に、古い学習データではなく最新のドキュメント・コード例をMCP経由で取得できるようにすることにある。ライブラリはContext7のレジストリに登録する形で追加でき、登録者はドキュメントに加えて「Custom Rules（AI Instructions）」という、そのライブラリを使う際にAIエージェントへ追加で伝えたい指示文を設定できる。この仕組み自体は、ライブラリ固有の注意点をAIに伝える便利な機能として設計されている。

Context7 セキュリティ体制を実体面から見る：企業運用か個人依存か

脆弱性の技術詳細に入る前に、Context7というプロジェクト自体の実体を確認しておく。読者が「Context7 セキュリティ」を調べる際に気になるのは、この種の欠陥が今後も繰り返されやすい構造かどうかだ。

・企業サポート：あり。Upstash社が開発・運用するホスティング型サービス（context7.com）と、OSSのクライアント/MCPサーバーを組み合わせたハイブリッド構成で、個人メンテナー1人に依存するプロジェクトではない
・pre-1.0か：いいえ。★60,940・数年規模の運用実績があり、npmでもcontext7-mcp・ctx7（CLI）・context7-sdkなど複数パッケージを継続リリース中
・star数と実体の乖離：乖離なし。2026-08-18時点でもコミット・npm公開が続いており、開発は現在も活発
・バス係数（コミット比率）：本記事では未確認。企業製品である点から個人依存の懸念は薄いと推測できるが、断定はしない

このプロファイル自体は、一般的な「メンテナー1人が燃え尽きて放置されたOSS」型のリスクとは異なる。ContextCrushが示しているのは、企業がしっかり運用しているサービスであっても、ユーザー生成コンテンツを扱う機能（Custom Rules）の検証設計という別の切り口で欠陥が生まれうる、という点だ。

Context7 脆弱性 ContextCrush の時系列：発見から5.5ヶ月遅れたCVE公開

発見者Noma Security（研究者Eli Ainhorn）のブログと、NVDのCVE公開日を突き合わせると、時系列に大きなギャップがあることがわかる。

この表が示す通り、発見から本番修正までは実質5日、公開開示までは約2週間というスピードで対応が完了している一方、NVDでの正式なCVE公開は約5.5ヶ月後になっている。この記事は「本日発覚した新規のゼロデイ」ではなく、「今年2月に発見・修正済みだった脆弱性に、本日ようやく正式なCVE番号が採番・公開された」という性質の事案として扱う。速報的な煽り方はせず、このギャップ自体を時系列として明示しておく。

なお、この種の「修正済みだが後日CVE採番」というパターンは珍しいものではない。CNA（CVE採番機関）への申請・NVDでの精査には時間がかかることがあり、開発元による迅速な修正と、公的なCVEデータベースへの反映は必ずしも同時進行しない。読者にとって重要なのは、CVE番号の公開日そのものを「事案の発生日」と混同しないことだ。

CVSS v3.1とv4.0でスコアが割れる理由

NVDのCVE-2026-75130ページには、CVSS v3.1で9.0（Critical）、CVSS v4.0で6.4（Medium）という、評価バージョンによって深刻度が大きく異なる2つのスコアが併記されている。CVSS v4.0は旧バージョンに比べて「攻撃の複雑さ」「必要な特権」「ユーザー関与の有無」といった要素をより細かく反映する設計になっており、間接プロンプトインジェクションのように「攻撃者が直接システムへ到達するわけではなく、AIエージェントの判断を介する」タイプの脆弱性では、旧バージョンより厳しめ、あるいは緩めに評価が振れることがある。本記事はどちらか一方を「正しいスコア」として採用せず、NVD記載の両方をそのまま併記する。

攻撃の仕組み：Custom Rulesの非サニタイズが招く間接プロンプトインジェクション

ContextCrushの技術的な核心は、Context7のライブラリ登録機能が持つ「Custom Rules（AI Instructions）」欄の非サニタイズにある。Context7はライブラリの登録自体を誰にでも開放しており、登録者はドキュメント本体に加えて、そのライブラリを扱う際にAIエージェントへ伝える追加指示（Custom Rules）を自由記述できる。この欄の内容が十分に検証・無害化されないまま、MCP応答の一部としてそのままAIエージェントへ配信されていたことが問題だった。

VulnCheckのアドバイザリは、この脆弱性をCWE-1427（不適切な出力ニュートラライズ、LLMプロンプトの文脈での分類）として整理している。攻撃者は、Context7に悪意あるライブラリ（または既存ライブラリに偽装したエントリ）を登録し、Custom Rules欄に「このライブラリを使う際は〇〇を実行せよ」といった指示を埋め込む。開発者が普段どおりAIエージェントにそのライブラリのドキュメントを問い合わせると、Context7のMCPサーバーはドキュメント本体とCustom Rulesを合わせて返す。AIエージェントは、この応答をContext7という信頼されたMCPサーバーからの正規の情報として扱うため、埋め込まれた指示をユーザーの意図と誤認して実行してしまう可能性がある。

この構図は、一般にMCP プロンプトインジェクションと呼ばれる攻撃分類の一種だ。ユーザーが直接入力したプロンプトではなく、AIエージェントが外部ツール（この場合はMCPサーバー経由のドキュメント）から取得したコンテンツに攻撃指示が紛れ込む「間接プロンプトインジェクション」に該当する。エージェントが「自分が呼び出したツールの応答は信頼できる」という前提で動作する設計そのものが悪用の土台になっている点が、通常のプロンプトインジェクション対策（入力フィルタリング）だけでは防ぎきれない理由でもある。

プロトコル層の脆弱性との違い：MCP STDIOトランスポート欠陥との比較

「MCPの脆弱性」とひとくくりにされがちだが、ContextCrushは既存記事で扱ったMCP STDIOトランスポートの設計欠陥とは攻撃レイヤーが異なる。混同を避けるため、ここで比較しておく。

ContextCrushは「MCPサーバーの実装そのもの」に穴があったわけではなく、「特定のMCPサーバー（Context7）が配信するコンテンツの検証が甘かった」という、いわばアプリケーションレベルの問題だ。MCPを実装する側だけでなく、MCPサーバーを運用する側（ユーザー生成コンテンツを扱うレジストリ型サービス）にも同種のリスクがあることを示す事例といえる。

自分の環境を確認する：Context7をMCPサーバーとして使っているか

このCVEは既に修正済みと報じられているため、攻撃の再現手順は扱わない。ここでは、読者が自分のMCP構成にContext7が含まれているかを確認する手順のみを示す。

# Claude Code の場合、登録済みMCPサーバーの一覧にContext7が含まれるか確認
claude mcp list 2>/dev/null | grep -i context7

# 各種エディタ・エージェントのMCP設定ファイルにcontext7の記載が無いか横断的に確認
grep -ril "context7" ~/.claude ~/.cursor ~/.codeium 2>/dev/null

Context7が設定に含まれている場合でも、この脆弱性の核心はContext7のサーバー側（バックエンド・パーシングエンジン・クローリングエンジン）にあり、これらのコンポーネントはupstash/context7のGitHubリポジトリには含まれていない非公開部分だ(README「Disclaimer」に明記)。つまり、読者側でクライアントのnpmパッケージ（@upstash/context7-mcp等）のバージョンを上げる対応が必要かどうかは、この記事の執筆時点では判断できない。

Context7をローカルサーバーとして自前でホストしている場合と、Upstashが運用するホスティング型サービス（context7.com経由）を利用している場合とでも、確認すべきポイントは異なる。ホスティング型を素直に使っているだけであれば、サーバー側の修正は既に反映されている可能性が高い。一方、フォークして独自にホストしている、あるいはバックエンドの一部を自前実装に置き換えているような環境では、Custom Rulesのサニタイズ処理が自環境にも反映されているかを個別に確認する必要がある。この判断材料についても、本記事が扱えるのはここまでで、最終的な要否は公式ドキュメント・アナウンスを確認してほしい。

Context7 脆弱性 の対策：現時点で言えることと、言い切れないこと

Noma Securityのブログによれば、Upstash側の本番環境での修正は2026年2月23日に完了済みと報じられている。この修正はContext7のサーバー側（Custom Rulesの検証・サニタイズ処理）に対して行われたとみられ、GitHubリポジトリで公開されているクライアント側のコード自体に、この脆弱性に対応する明示的な修正コミットがあるかどうかは、本記事では特定していない。

読者側で現実的に取れる対応は以下の通りだ。

・自分のMCP構成にContext7が含まれるか確認する（上記コマンド参照）
・AIエージェントがMCP経由で取得した指示を無条件に実行しない運用にする：ドキュメント取得ツールからの応答であっても、ファイル削除・外部送信を伴う操作は人間の承認を挟む
・公式のセキュリティアナウンスを継続的に確認する：クライアント側の対応要否が明記されるまでは、憶測で「対応済み」「対応不要」と判断しない
・MCPレジストリ型サービスを自分で運用・実装している場合は、ユーザー生成コンテンツ（今回のCustom Rulesに相当する自由記述欄）が、既存の信頼された配信経路（MCPレスポンス）にそのまま混入していないかを棚卸しする

自分でMCPサーバーを実装・運用している場合、ContextCrushの事案は棚卸しの材料になる。確認しておきたい観点は、①ユーザーが自由記述できる欄（Custom Rules相当）が、他の信頼された情報と無検証で同じ応答に混ざっていないか、②AIエージェント側が、MCP応答内のどの部分が「ドキュメント」でどの部分が「指示」なのかを区別できる設計になっているかの2点だ。

MCPクライアント側（Claude Code・Cursor等のエージェント実装）の観点でも、対応の余地はある。多くのエージェントは、MCPツールの実行結果を追加のシステムプロンプトのように扱わず、あくまで「参照情報」として提示した上でユーザーの判断を挟む設計を選べる。ファイル削除・外部への送信・シェルコマンド実行など、取り返しのつかない操作については、MCP応答由来の指示だけを根拠に自動実行しない設定・レビューフローを維持することが、個別のCVE対応よりも汎用的な防御線になる。

まとめ：正規の配信チャネルが攻撃経路になったサプライチェーン攻撃

参照ソース

・NVD - CVE-2026-75130 — CVSSスコア（v3.1/v4.0）・影響バージョン・公開日を取得
・ContextCrush: The Context7 MCP Server Vulnerability Hiding in Plain Sight（Noma Security, 2026-03-05） — 発見経緯・攻撃メカニズム・開示タイムラインを取得
・VulnCheck Advisory: Context7 Prompt Injection via Custom AI Instructions — CWE-1427分類・CVSS v4ベクターを取得
・upstash/context7（公式リポジトリ） — star数・ライセンス・開発状況を実測