QVD-2026-57410を解説：DeepSeek HarnessのHostヘッダー欠陥が招く未認証RCE

QVD-2026-57410は、DeepSeekのAIエージェント基盤「DeepSeek Harness（DSH）」0.1.1-rc.2で報告された重大な脆弱性です。奇安信（QiAnXin）関連の報告では、CVSS 3.0のスコアは9.8。APIキーなどの認証情報なしで、リモートから任意のコマンドを実行できる可能性があるとされています。 1924

問題の中心にあるのは、DSHの/apiがリクエストを信頼できるローカル発として扱うかどうかを、クライアント側で操作できるHTTPのHostヘッダーに依存していた点です。Hostヘッダーは送信者が自由に細工できるため、これを認証の代わりに使うと、ローカル専用のつもりで設けた境界が破られるおそれがあります。 1924

ただし、危険度はデプロイ方法に大きく左右されます。DeepSeekが案内するWebコマンドは、標準では127.0.0.1:3080でインターフェースを起動します。この設定だけなら、外部からサービスへ直接到達することはできません。リスクが大きくなるのは、非ループバックアドレスで公開した場合や、Docker、リバースプロキシ、トンネル、VPN、LAN、Ingressなどを通じて外部から到達可能にした場合です。 1118

Hostヘッダーの偽装で何が起きるのか

影響を受ける設計では、リクエストのHost情報を手がかりに、リクエストが本機から来たものかどうかを区別しようとしていました。しかし、Hostヘッダーは攻撃者が設定できる入力値です。

サービスに到達できる攻撃者がローカル向けに見えるHost値を送ると、DSHの/api層がそのリクエストを信頼済みとして処理し、本来は内部向けの機能に到達できる可能性があります。報告では、これをループバック限定の信頼境界を回避する問題と説明しています。 1924

報告された攻撃の流れを高いレベルで整理すると、次のようになります。

1. 外部に公開されたDSHのWebまたは管理エンドポイントへ到達する。
2. ローカル向けに見える偽装Hostヘッダーを付けてリクエストを送る。
3. /apiに設けられた内部向けのアクセス制限を回避する。
4. 制限されたRPC機能を呼び出す。
5. 攻撃者が管理するモデルプロバイダーの経路を登録、または利用する。
6. DSHのAgent機能を通じて、ホスト上でコマンドを実行させる。 1920

単なるルーティング不備や情報漏えいにとどまらないのは、回避後に到達できる機能が、AIエージェントを動かすためのシステム操作能力と結び付いているためです。

なぜRCEにつながるのか

DeepSeek自身はHarnessを実験的な開発者向けプレビューソフトウェアと位置付けており、セキュリティ監査を受けていないため、安全な本番環境向け製品として扱うべきではないと説明しています。安全上の注意書きによると、同プロジェクトはモデルが生成したコードやコマンドを実行し、環境から利用可能なネットワーク、プロセス、認証情報、ファイルへアクセスできます。 4

LLMサブシステムには、プロバイダーの登録やモデル探索機能があり、discoverModelsというリモート操作も提供されています。 23 報告された攻撃チェーンでは、攻撃者が用意したプロバイダーを利用して、Agentのコマンド実行機能に到達するための入力を与えるとされています。 19

悪用に成功した場合、必ずしもroot権限が得られるわけではありません。実行されるコマンドは、DSHサービスプロセスの権限で動作します。それでも、そのアカウントがアクセスできるファイルの読み書き、利用可能な認証情報やAPIキーの窃取、プロセスの起動、アプリケーションデータの変更、外部ネットワークへの接続などにつながる可能性があります。

最終的な影響は環境設定次第です。たとえば、ファイルシステムへの過剰なアクセス権、特権コンテナ、ホストのDockerソケットのマウント、クラウド認証情報へのアクセスがある場合は、被害が拡大します。一方、提供された報告だけから、すべての環境で自動的にホスト全体を乗っ取れると断定することはできません。

特に確認すべきデプロイ構成

次のような環境は、優先度を上げて点検してください。

• DSHを0.0.0.0など、ループバック以外のアドレスにバインドしている
• Dockerなどでポート3080をホスト外部やネットワーク上に公開している
• リバースプロキシが管理APIをインターネットや信頼できないLANへ転送している
• トンネル、VPN、Ingressによって、強固な認証を受けていない利用者から到達できる
• 任意のクライアントHost値を受け入れる、またはそのまま上流へ転送するプロキシ設定になっている

「社内向け」「内部ネットワーク上」というだけでは、認可の代わりになりません。エンドポイントへ到達でき、関連するリクエストヘッダーを操作できる攻撃者は、境界回避を試みることができます。

PoC、CVE、実際の悪用状況

複数の報告では、QVD-2026-57410の概念実証（PoC）や技術情報が公開済みとされています。 192027 攻撃に必要な情報が広まっているため、封じ込めの緊急性は高まっています。ただし、PoCが公開されていることと、特定の環境が侵害された証拠があることは別です。

提供された報告の時点では、実際の攻撃（イン・ザ・ワイルド利用）は確認されておらず、既知の脅威アクターや攻撃キャンペーンとの関連を示す証拠もないとされています。 1924 これはあくまで開示時点の状況であり、安全を保証するものではありません。公開状態のインスタンスでは、不審なリクエスト、予期しないプロバイダー登録、新たなプロセス、通常と異なる外向き通信などを確認してください。

なお、QVD-2026-57410はQVDの識別子であり、CVE番号ではありません。NVDに登録されているCVE-2026-57410は、MailerPressの権限昇格脆弱性を指す別の問題です。 17

運用担当者が取るべき対応

1. まずネットワークから切り離す

DSHの管理サービスとAPIをインターネットへ公開しないでください。ループバック、または専用の管理ネットワークにバインドし、リモート管理が必要な場合は、アクセス元を管理したVPNや踏み台サーバーを利用します。

2. すべてのネットワーク層で接続元を制限する

ファイアウォール、クラウドのセキュリティグループ、コンテナネットワーク、リバースプロキシで、明示的に信頼した接続元だけを許可します。「内部ルートであること」や、ローカルに見えるヘッダーを本人確認の根拠にしてはいけません。

3. プロキシでHostヘッダーを検証・上書きする

エッジ側のプロキシで想定外のHost値を拒否します。プロキシ転送が必要な場合も、クライアントの値をそのまま上流へ渡すのではなく、既知の固定値で上流向けHostヘッダーを上書きしてください。転送されるクライアントIPのヘッダーも、管理下にあるプロキシから来た場合だけ信頼する構成にします。

4. Hostヘッダーとは独立した認証を導入する

管理機能と内部RPC操作には、実際の認証・認可を設定します。強固な認証を備えたゲートウェイ、相互TLS（mTLS）、操作単位のアクセス制御などが候補になります。Hostヘッダーの検証はルーティングの補助にはなっても、唯一の本人確認手段であってはなりません。

5. プロバイダー探索と外向き通信のリスクを抑える

不要であればllm.discoverModelsを無効化または制限します。必要な場合はプロバイダーの接続先を許可リスト化し、外向き通信（egress）を制御してください。プロバイダー探索の経路が悪用された場合に備え、機密性の高い内部宛先やクラウドのメタデータサービスへのアクセスを遮断することも、影響の抑制に役立ちます。DSHのLLMドキュメントでは、プロバイダー登録とモデル探索が機能として公開されていることが確認できます。 23

6. 公式情報で修正済みバージョンを確認する

提供された情報では、影響を受けるバージョンとして0.1.1-rc.2が挙げられ、後続リリースの活動も確認されています。しかし、特定の後続ビルドがこの脆弱性を修正したことまでは確認できません。アップデートだけで十分と判断する前に、DeepSeekの最新リリースノートやセキュリティアドバイザリーで、修正済みであることが明示されているかを確認してください。プロジェクト自身も、Harnessは実験段階で本番利用向けではないと注意喚起しています。 410

7. 公開状態だった場合は調査と資格情報のローテーションを行う

リバースプロキシとDSHのログから、異常な/apiリクエスト、ローカル向けに偽装されたHost値、予期しないモデルプロバイダー登録、プロセス起動、ファイル変更、外向き通信を探します。DSHプロセスから利用できた認証情報はローテーションしてください。コマンド実行や永続化の兆候がある場合は、サービスを再起動しただけで安全になったと考えず、影響を受けたホストやコンテナを隔離し、再構築するのが安全です。