QVD-2026-57410 是據報影響 DeepSeek Harness（DSH）0.1.1-rc.2 的重大安全漏洞。奇安信相關報告將其描述為不需驗證即可利用的遠端程式碼執行（RCE）漏洞，CVSS 3.0 評分達 9.8。核心問題在於，DSH 的 /api 信任判斷可能依賴由用戶端自行提供的 HTTP Host 標頭，將一段可偽造的請求資訊錯當成身分驗證依據。1924

不過，實際風險高度取決於部署方式。DeepSeek 文件顯示，執行 Web 介面的指令預設會在 127.0.0.1:3080 啟動，這通常會限制外部直接連線。當服務被綁定至非回環介面，或經由 Docker、反向代理、通道、VPN、區域網路或 ingress 轉發時，風險便會顯著上升。1118

Host 標頭繞過是怎麼發生的？

受影響的設計試圖透過請求中的主機資訊，分辨請求是否來自本機。但 HTTP Host 標頭由請求方提供，並不是可靠的身分憑證；只要攻擊者能連到服務，就可能偽造一個看似本機的 Host 值，誘使 /api 層把遠端請求當成受信任的本機請求。相關報告將此描述為繞過 DSH「僅限回環介面」信任邊界。1924

在高層次上，據報的攻擊鏈如下：

1. 連線至暴露在外的 DSH Web 或管理端點。
2. 送出帶有偽造本機格式 Host 標頭的請求。
3. 繞過原本用於保護內部操作的 /api 限制。
4. 呼叫受限制的 RPC 功能。
5. 註冊或使用攻擊者控制的大型語言模型提供者路由。
6. 利用 DSH 的 Agent 能力，在主機上執行命令。1920

因此，這不只是路由錯誤或資訊洩漏問題：一旦繞過信任檢查，攻擊者可能觸及一個原本就具備 AI Agent 系統操作能力的功能面。

為什麼 Host 標頭問題會升級成 RCE？

DeepSeek 自己將 Harness 定位為實驗性開發者預覽軟體，並明確表示專案尚未接受安全性稽核。安全說明也警告，Harness 能執行模型產生的程式碼與命令，並存取授予它的網路、程序、憑證與檔案；錯誤輸出、缺陷、錯誤設定、惡意輸入或不受信任的外掛，都可能影響主機。4

DSH 的 LLM 子系統支援提供者註冊、模型清單與模型探索，其中包括 discoverModels 遠端操作。23 在所報告的利用鏈中，攻擊者控制的模型提供者可被用來提供後續所需的輸入，進而觸發 Agent 的命令執行能力。19

成功利用並不代表攻擊者必然取得 root 權限。命令會以 DSH 服務程序的權限執行；但如果該程序能讀寫敏感檔案、存取 API 金鑰或其他憑證、啟動程序、修改應用程式資料，或連接外部網路，影響仍可能相當嚴重。

最終後果取決於部署環境，例如服務是否擁有過大的檔案系統權限、容器是否以高權限執行、是否掛載 Docker socket，或是否能讀取雲端憑證。現有報告並未證實所有部署都會自動演變成完整主機接管。

哪些部署最需要立即檢查？

以下配置應列為優先檢查對象：

• DSH 綁定 0.0.0.0 或其他非回環位址。
• Docker 或其他容器執行環境將 3080 連接埠發布至本機以外的網路。
• 反向代理將管理 API 轉發至網際網路或不受信任的區域網路。
• 通道、VPN 或 ingress 讓未經強力驗證的使用者可以連到服務。
• 代理設定接受任意用戶端 Host 值，或將該值原封不動轉發至上游服務。

「只在內部網路」本身不是授權機制。只要攻擊者能連到端點，並影響相關請求標頭，就可能嘗試進行繞過。

PoC、CVE 與實際攻擊狀況

多份報告表示，QVD-2026-57410 的概念驗證程式碼（PoC）或技術細節已公開。192027 這代表應立即收斂暴露面，但「PoC 已公開」不等於每一個部署環境都已遭入侵。

所提供的報告指出，截至披露時尚未觀察到在野大規模利用，也沒有證據將此漏洞與已知威脅團體或攻擊活動連結。1924 這只是特定時間點的觀察，不能視為安全保證。若服務曾經暴露，仍應檢查可疑請求、異常的提供者註冊、新增程序與不尋常的對外連線。

此外，QVD-2026-57410 是 QVD 編號，不是 CVE 編號。NVD 中編號相近的 CVE-2026-57410，實際上是 MailerPress 的權限提升漏洞，與 DSH 無關。17

DSH 管理者應採取哪些措施？

1. 先移除網路暴露

停止將 DSH 管理介面與 API 服務發布至公開網際網路。將服務綁定至回環介面或專用管理網路；若必須遠端管理，應透過受控 VPN 或跳板主機連線。

2. 在各網路層限制來源

同步套用防火牆、雲端安全群組、容器網路與反向代理規則，只允許明確信任的來源。不要把「走內部路由」或「看起來像本機的標頭」當成身分證明。

3. 驗證並覆寫代理標頭

在邊界代理拒絕不符合預期的 Host 值。若必須轉發，應將上游 Host 標頭覆寫為已知且固定的值，而不是盲目轉發用戶端提供的內容。對轉發的用戶端 IP 標頭，也只能信任來自受控代理的值。

4. 使用獨立於 Host 的真正驗證

管理介面與內部 RPC 操作應由獨立的身分驗證和授權機制保護，例如強驗證閘道、雙向 TLS（mTLS）以及逐項操作的存取控制。Host 標頭檢查最多只能協助路由判斷，不能成為唯一的身分驗證方式。

5. 降低模型探索與對外連線風險

不需要時停用或限制 llm.discoverModels。若必須使用模型提供者探索功能，應建立提供者端點允許清單並限制對外連線；封鎖通往敏感內部位址與雲端中繼資料服務的流量，也有助於降低相關路徑遭濫用時的影響。DSH 的 LLM 文件確認，提供者註冊與模型探索屬於可用能力。23

6. 依官方資訊確認修復版本

目前所提供的資料確認 0.1.1-rc.2 為受影響版本，也顯示後續已有版本發布活動，但尚不足以證明任何特定後續版本已修復此漏洞。升級前應查看 DeepSeek 最新的發布說明與安全公告，確認官方明確列出修復內容後，才將升級視為完整緩解措施。專案安全說明目前仍警告 Harness 屬於實驗性、未經安全稽核且不適合直接視為正式生產環境軟體。410

7. 若曾暴露，立即進行入侵排查

檢查反向代理與 DSH 日誌，尋找異常 /api 請求、偽造本機格式的 Host 值、非預期的模型提供者註冊、程序啟動、檔案變更與對外連線。輪替 DSH 服務程序能存取的憑證。若發現命令執行或持久化跡象，應隔離並重建受影響的主機或容器，不要只假設重新啟動服務就能清除入侵。

QVD-2026-57410 是據報影響 DeepSeek Harness（DSH）0.1.1-rc.2 的重大安全漏洞。奇安信相關報告將其描述為不需驗證即可利用的遠端程式碼執行（RCE）漏洞，CVSS 3.0 評分達 9.8。核心問題在於，DSH 的 /api 信任判斷可能依賴由用戶端自行提供的 HTTP Host 標頭，將一段可偽造的請求資訊錯當成身分驗證依據。1924

不過，實際風險高度取決於部署方式。DeepSeek 文件顯示，執行 Web 介面的指令預設會在 127.0.0.1:3080 啟動，這通常會限制外部直接連線。當服務被綁定至非回環介面，或經由 Docker、反向代理、通道、VPN、區域網路或 ingress 轉發時，風險便會顯著上升。1118

Host 標頭繞過是怎麼發生的？

受影響的設計試圖透過請求中的主機資訊，分辨請求是否來自本機。但 HTTP Host 標頭由請求方提供，並不是可靠的身分憑證；只要攻擊者能連到服務，就可能偽造一個看似本機的 Host 值，誘使 /api 層把遠端請求當成受信任的本機請求。相關報告將此描述為繞過 DSH「僅限回環介面」信任邊界。1924

在高層次上，據報的攻擊鏈如下：

1. 連線至暴露在外的 DSH Web 或管理端點。
2. 送出帶有偽造本機格式 Host 標頭的請求。
3. 繞過原本用於保護內部操作的 /api 限制。
4. 呼叫受限制的 RPC 功能。
5. 註冊或使用攻擊者控制的大型語言模型提供者路由。
6. 利用 DSH 的 Agent 能力，在主機上執行命令。1920

因此，這不只是路由錯誤或資訊洩漏問題：一旦繞過信任檢查，攻擊者可能觸及一個原本就具備 AI Agent 系統操作能力的功能面。

為什麼 Host 標頭問題會升級成 RCE？

DeepSeek 自己將 Harness 定位為實驗性開發者預覽軟體，並明確表示專案尚未接受安全性稽核。安全說明也警告，Harness 能執行模型產生的程式碼與命令，並存取授予它的網路、程序、憑證與檔案；錯誤輸出、缺陷、錯誤設定、惡意輸入或不受信任的外掛，都可能影響主機。4

DSH 的 LLM 子系統支援提供者註冊、模型清單與模型探索，其中包括 discoverModels 遠端操作。23 在所報告的利用鏈中，攻擊者控制的模型提供者可被用來提供後續所需的輸入，進而觸發 Agent 的命令執行能力。19

成功利用並不代表攻擊者必然取得 root 權限。命令會以 DSH 服務程序的權限執行；但如果該程序能讀寫敏感檔案、存取 API 金鑰或其他憑證、啟動程序、修改應用程式資料，或連接外部網路，影響仍可能相當嚴重。

最終後果取決於部署環境，例如服務是否擁有過大的檔案系統權限、容器是否以高權限執行、是否掛載 Docker socket，或是否能讀取雲端憑證。現有報告並未證實所有部署都會自動演變成完整主機接管。

哪些部署最需要立即檢查？

以下配置應列為優先檢查對象：

• DSH 綁定 0.0.0.0 或其他非回環位址。
• Docker 或其他容器執行環境將 3080 連接埠發布至本機以外的網路。
• 反向代理將管理 API 轉發至網際網路或不受信任的區域網路。
• 通道、VPN 或 ingress 讓未經強力驗證的使用者可以連到服務。
• 代理設定接受任意用戶端 Host 值，或將該值原封不動轉發至上游服務。

「只在內部網路」本身不是授權機制。只要攻擊者能連到端點，並影響相關請求標頭，就可能嘗試進行繞過。

PoC、CVE 與實際攻擊狀況

多份報告表示，QVD-2026-57410 的概念驗證程式碼（PoC）或技術細節已公開。192027 這代表應立即收斂暴露面，但「PoC 已公開」不等於每一個部署環境都已遭入侵。

所提供的報告指出，截至披露時尚未觀察到在野大規模利用，也沒有證據將此漏洞與已知威脅團體或攻擊活動連結。1924 這只是特定時間點的觀察，不能視為安全保證。若服務曾經暴露，仍應檢查可疑請求、異常的提供者註冊、新增程序與不尋常的對外連線。

此外，QVD-2026-57410 是 QVD 編號，不是 CVE 編號。NVD 中編號相近的 CVE-2026-57410，實際上是 MailerPress 的權限提升漏洞，與 DSH 無關。17

DSH 管理者應採取哪些措施？

1. 先移除網路暴露

停止將 DSH 管理介面與 API 服務發布至公開網際網路。將服務綁定至回環介面或專用管理網路；若必須遠端管理，應透過受控 VPN 或跳板主機連線。

2. 在各網路層限制來源

同步套用防火牆、雲端安全群組、容器網路與反向代理規則，只允許明確信任的來源。不要把「走內部路由」或「看起來像本機的標頭」當成身分證明。

3. 驗證並覆寫代理標頭

在邊界代理拒絕不符合預期的 Host 值。若必須轉發，應將上游 Host 標頭覆寫為已知且固定的值，而不是盲目轉發用戶端提供的內容。對轉發的用戶端 IP 標頭，也只能信任來自受控代理的值。

4. 使用獨立於 Host 的真正驗證

管理介面與內部 RPC 操作應由獨立的身分驗證和授權機制保護，例如強驗證閘道、雙向 TLS（mTLS）以及逐項操作的存取控制。Host 標頭檢查最多只能協助路由判斷，不能成為唯一的身分驗證方式。

5. 降低模型探索與對外連線風險

不需要時停用或限制 llm.discoverModels。若必須使用模型提供者探索功能，應建立提供者端點允許清單並限制對外連線；封鎖通往敏感內部位址與雲端中繼資料服務的流量，也有助於降低相關路徑遭濫用時的影響。DSH 的 LLM 文件確認，提供者註冊與模型探索屬於可用能力。23

6. 依官方資訊確認修復版本

目前所提供的資料確認 0.1.1-rc.2 為受影響版本，也顯示後續已有版本發布活動，但尚不足以證明任何特定後續版本已修復此漏洞。升級前應查看 DeepSeek 最新的發布說明與安全公告，確認官方明確列出修復內容後，才將升級視為完整緩解措施。專案安全說明目前仍警告 Harness 屬於實驗性、未經安全稽核且不適合直接視為正式生產環境軟體。410

7. 若曾暴露，立即進行入侵排查

檢查反向代理與 DSH 日誌，尋找異常 /api 請求、偽造本機格式的 Host 值、非預期的模型提供者註冊、程序啟動、檔案變更與對外連線。輪替 DSH 服務程序能存取的憑證。若發現命令執行或持久化跡象，應隔離並重建受影響的主機或容器，不要只假設重新啟動服務就能清除入侵。