はじめに：DeepSeek MCP Serverとは？

こんにちは、フロントエンドエンジニアの皆さん。今回は、Node.js環境で動作するAIアシスタント連携ツール `@arikusi/deepseek-mcp-server` に発見された、重大なセキュリティ脆弱性 (GHSA-fh3r-g96v-f578 / CVE-2026-55604) について解説します。このライブラリはAIとの会話履歴管理などを担うバックエンドコンポーネントですが、皆さんの開発するフロントエンドアプリケーションがもしこのバックエンドと連携している場合、そのユーザーデータが危険に晒される可能性があるため、内容を理解し適切な対策を講じることが非常に重要です。

脆弱性の概要：ユーザー制御キーによる認証バイパス

この脆弱性は「Authorization Bypass Through User-Controlled Key」（ユーザー制御キーを介した認証バイパス）と分類され、深刻度はHighと評価されています。具体的には、`@arikusi/deepseek-mcp-server` が、HTTPリクエストを通じてユーザーから提供された `session_id` を、そのセッションの所有権を確認することなく、直接セッションストアのキーとして使用してしまう点に問題があります。これにより、攻撃者は他ユーザーのセッションIDを知ることで、そのセッションにアクセスし、機密情報を窃取したり、セッションを乗っ取ったりすることが可能になります。

問題の根源は、セッション管理に用いられる `SessionStore` がプロセスグローバルなオブジェクトとして実装されており、かつ、ユーザーが指定した `session_id` を何の検証もなく信頼してしまう設計にありました。これは「Cross-Session Data Exposure via Caller-Controlled `session_id`」（呼び出し元が制御する`session_id`を介したクロスセッションデータ露出）とも呼ばれます。

具体的な脆弱性メカニズムと攻撃シナリオ

攻撃者は以下のステップで脆弱性を悪用できます。

1. **セッションIDの列挙**: まず、攻撃者は `deepseek_sessions` ツール（例えば `deepseek_sessions list` アクション）を呼び出すことで、現在アクティブな全てのセッションIDを列挙・取得できてしまいます。ここには、他の正規ユーザーが利用しているセッションIDも含まれます。

2. **被害者セッションの特定**: 例えば「victim-session」というIDを持つ被害者の会話セッションが存在するとします。

3. **セッションデータの窃取・乗っ取り**: 攻撃者は、取得した被害者のセッションID（例: 「victim-session」）を自身の `deepseek_chat` リクエストに含めて送信します。サーバーは、この提供されたセッションIDを信頼し、被害者のセッションデータ（過去の会話履歴など）を攻撃者のリクエストに結合して処理してしまいます。これにより、攻撃者は被害者の会話履歴を閲覧できるだけでなく、そのセッションを引き継いで会話を継続することも可能になります。

つまり、ユーザーがセッションIDを自由に指定できてしまうことで、まるで他人の家の鍵を勝手に複製して入り込むかのような状況が発生していたわけです。

影響とフロントエンド開発者への注意点

この脆弱性が悪用された場合、以下のような重大な影響が考えられます。

1. **機密情報の漏洩**: AIアシスタントとの会話履歴には、個人情報や業務上の機密情報が含まれる可能性があります。これらが第三者に読み取られるリスクがあります。

2. **セッションハイジャック**: 他人のセッションを乗っ取ることで、なりすましや意図しない操作を実行される可能性があります。

フロントエンドエンジニアの皆さんは、直接このライブラリをブラウザで動かすことはありませんが、皆さんが開発するアプリケーションがバックエンドAPIを介して `deepseek-mcp-server` と通信している場合、この脆弱性はアプリケーション全体のセキュリティに影響します。ユーザーが入力した情報をバックエンドに送信する際、それがどのように処理されるのか、特に認証やセッション管理に関わる部分については、常に注意を払う必要があります。

対策と推奨事項

この脆弱性は、すでに以下のバージョンで修正されています。

**最優先の対策**: `@arikusi/deepseek-mcp-server` を **バージョン `1.7.0` 以降** に速やかにアップグレードしてください。影響を受けるバージョンは `>=1.4.2, <1.7.0` です。

バージョン `1.7.0` では、HTTPトランスポートの `SessionStore` がプロセスワイドなシングルトンではなくなり、各MCP HTTPセッションが独自のストアを持つように変更されました。これにより、あるHTTPセッションの `session_id` が、他のセッションの状態を読み取ったり、列挙したり、クリアしたりすることができなくなりました。

もしアップグレードが直ちに困難な場合は、以下の回避策を検討してください。

**一時的な回避策**: `TRANSPORT=http` の環境変数を設定しない（STDIOトランスポートを使用する）か、HTTPサーバーを停止してください。STDIOトランスポートはクライアントごとに独立したプロセスで動作するため、この脆弱性の影響を受けません。

**根本的な対策の考え方**: セキュリティ設計の観点からは、以下の点を考慮することが重要です。

<ul><li>ユーザーから提供される `session_id` を安易に信用せず、必ずサーバー側で生成・管理された不透明な識別子と紐付ける。</li><li>セッション情報を、認証されたユーザーまたはトランスポートセッションに厳密にバインドする。</li><li>セッションIDの列挙や、他者のセッションへのアクセスを許すような機能は、厳しく制限するか、廃止する。</li><li>セッションの再利用を許可する際には、必ずそのセッションの所有権を証明するメカニズムを導入する。</li></ul>

まとめ

今回の `@arikusi/deepseek-mcp-server` の脆弱性は、セッション管理の基本である「ユーザー入力の不信」がいかに重要であるかを改めて示す事例です。フロントエンドエンジニアとして、バックエンドとの連携部分におけるセキュリティは特に意識したいポイントです。

開発中のアプリケーションで使用しているライブラリのセキュリティ情報を常にチェックし、速やかに最新バージョンへのアップデートを行う習慣をつけましょう。これにより、ユーザーのデータとシステムの安全を守ることができます。