QVD-2026-57410 是針對 DeepSeek Harness（DSH）0.1.1-rc.2 的已報告極危漏洞。奇安信相關報告將它描述為毋須身份驗證的遠端程式碼執行（RCE）漏洞，CVSS 3.0 評分為 9.8。問題核心在於，DSH 的 /api 信任判斷可能依賴由客戶端控制的 HTTP Host 標頭——但這個標頭可以由請求方自行偽造，並不能取代真正的身份驗證。1924

不過，實際風險很視乎部署方式。DeepSeek 官方文件顯示，正常使用 dsh web 啟動時，Web 介面預設會監聽 127.0.0.1:3080，即只限本機存取。當服務改為監聽非回環介面，或透過 Docker、反向代理、Tunnel、VPN、區域網絡或 Ingress 轉發，風險便會大幅增加。1118

Host 標頭繞過是怎樣發生？

受影響設計嘗試利用請求的主機資訊，分辨請求是否來自本機。但 HTTP Host 標頭是由請求方提供，攻擊者可以將它偽造成看似本機的值。只要能夠連到 DSH 服務，攻擊者便可能令 /api 層誤以為請求來自受信任的本機，繞過原本用來保護內部操作的回環地址信任邊界。1924

以高層次概括，報告所述的攻擊鏈如下：

1. 連接到暴露出去的 DSH Web 或管理端點。
2. 發送帶有偽造本機格式 Host 標頭的請求。
3. 繞過原本限制 /api 存取的檢查。
4. 呼叫受限制的內部 RPC 功能。
5. 登記或使用由攻擊者控制的模型提供者路由。
6. 利用 DSH 的 Agent 能力，在主機上執行指令。1920

所以，這不只是普通的路由錯誤或資料洩露問題。繞過信任邊界後，攻擊者可能接觸到原本設計來操作 AI Agent、並具備系統級能力的功能。

為甚麼會升級成遠端程式碼執行？

DeepSeek 自己形容 Harness 是實驗性開發者預覽軟件，尚未接受安全審計。安全聲明亦提醒，項目可以執行模型產生的程式碼及指令，並存取向它提供的網絡、程序、憑證及檔案。4

DSH 的 LLM 子系統支援登記模型提供者及探索模型，包括 discoverModels 遠端操作。23 按照已公開報告的攻擊鏈，攻擊者控制的提供者可被用來提供所需輸入，進一步觸發 Agent 的指令執行能力。19

成功利用並不代表必然取得 root 權限。指令會以 DSH 服務程序本身的權限執行；但如果該程序可以讀寫敏感檔案、使用可接觸到的憑證或 API Key、啟動其他程序，或向外連接網絡，實際破壞力仍然可以很大。

至於最終是否能夠完全接管主機，則取決於部署環境，例如：

• 服務是否擁有過大的檔案系統存取權限；
• 容器是否以特權模式運行；
• 是否掛載 Docker socket；
• DSH 是否能讀取雲端憑證；
• 服務帳戶是否擁有過高權限。

現有報告並沒有證明所有部署都會自動演變成完整的主機接管。

哪些部署方式最需要優先檢查？

以下配置應視為緊急檢查對象：

• DSH 綁定 0.0.0.0 或其他非回環地址；
• Docker 或其他容器運行環境將 3080 port 發佈到本機以外的網絡；
• 反向代理將管理 API 轉發到互聯網或不受信任的內聯網；
• Tunnel、VPN 或 Ingress 令未有強身份驗證的使用者可以連到服務；
• Proxy 接受任意客戶端 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 或跳板機，不要直接公開管理 port。

2. 每一層網絡都限制來源

在防火牆、雲端 Security Group、容器網絡及反向代理層面，只允許明確可信的來源。不要單靠「內部路由」或「看似本機」的標頭作為身份證明。

3. 驗證並覆寫 Proxy 標頭

在邊緣 Proxy 拒絕不符合預期的 Host 值。若必須轉發，應將上游 Host 標頭覆寫成已知固定值，而不是盲目轉發客戶端提供的內容。對 X-Forwarded-For 等客戶端 IP 標頭，亦只應在它們來自受控 Proxy 時才信任。

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

管理功能及內部 RPC 操作應由獨立的身份驗證和授權保護，例如強身份驗證閘道、mTLS，以及按操作細分的存取控制。Host 標頭檢查可以協助路由判斷，但絕不能成為唯一的身份控制。

5. 收窄模型提供者探索及對外連線風險

如非必要，停用或限制 llm.discoverModels。如必須使用模型提供者探索功能，應建立提供者端點白名單，並配合對外流量控制。封鎖通往敏感內部地址、雲端 metadata 服務及其他不必要目的地的連線，可以減低提供者探索路徑被濫用成伺服器端請求工具時的影響。DSH 的 LLM 文件確認，提供者登記及模型探索是其公開能力的一部分。23

6. 只按官方資料確認修復版本

現有來源指出 0.1.1-rc.2 是受影響版本，亦顯示項目之後仍有版本活動；但資料並未證明任何特定後續版本已修復這個漏洞。因此，升級前應查閱 DeepSeek 最新的 Release Notes 及安全公告，確認官方明確列出修復內容後，才可視為完成修補。項目本身的安全聲明亦繼續提醒 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 官方文件顯示，正常使用 dsh web 啟動時，Web 介面預設會監聽 127.0.0.1:3080，即只限本機存取。當服務改為監聽非回環介面，或透過 Docker、反向代理、Tunnel、VPN、區域網絡或 Ingress 轉發，風險便會大幅增加。1118

Host 標頭繞過是怎樣發生？

受影響設計嘗試利用請求的主機資訊，分辨請求是否來自本機。但 HTTP Host 標頭是由請求方提供，攻擊者可以將它偽造成看似本機的值。只要能夠連到 DSH 服務，攻擊者便可能令 /api 層誤以為請求來自受信任的本機，繞過原本用來保護內部操作的回環地址信任邊界。1924

以高層次概括，報告所述的攻擊鏈如下：

1. 連接到暴露出去的 DSH Web 或管理端點。
2. 發送帶有偽造本機格式 Host 標頭的請求。
3. 繞過原本限制 /api 存取的檢查。
4. 呼叫受限制的內部 RPC 功能。
5. 登記或使用由攻擊者控制的模型提供者路由。
6. 利用 DSH 的 Agent 能力，在主機上執行指令。1920

所以，這不只是普通的路由錯誤或資料洩露問題。繞過信任邊界後，攻擊者可能接觸到原本設計來操作 AI Agent、並具備系統級能力的功能。

為甚麼會升級成遠端程式碼執行？

DeepSeek 自己形容 Harness 是實驗性開發者預覽軟件，尚未接受安全審計。安全聲明亦提醒，項目可以執行模型產生的程式碼及指令，並存取向它提供的網絡、程序、憑證及檔案。4

DSH 的 LLM 子系統支援登記模型提供者及探索模型，包括 discoverModels 遠端操作。23 按照已公開報告的攻擊鏈，攻擊者控制的提供者可被用來提供所需輸入，進一步觸發 Agent 的指令執行能力。19

成功利用並不代表必然取得 root 權限。指令會以 DSH 服務程序本身的權限執行；但如果該程序可以讀寫敏感檔案、使用可接觸到的憑證或 API Key、啟動其他程序，或向外連接網絡，實際破壞力仍然可以很大。

至於最終是否能夠完全接管主機，則取決於部署環境，例如：

• 服務是否擁有過大的檔案系統存取權限；
• 容器是否以特權模式運行；
• 是否掛載 Docker socket；
• DSH 是否能讀取雲端憑證；
• 服務帳戶是否擁有過高權限。

現有報告並沒有證明所有部署都會自動演變成完整的主機接管。

哪些部署方式最需要優先檢查？

以下配置應視為緊急檢查對象：

• DSH 綁定 0.0.0.0 或其他非回環地址；
• Docker 或其他容器運行環境將 3080 port 發佈到本機以外的網絡；
• 反向代理將管理 API 轉發到互聯網或不受信任的內聯網；
• Tunnel、VPN 或 Ingress 令未有強身份驗證的使用者可以連到服務；
• Proxy 接受任意客戶端 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 或跳板機，不要直接公開管理 port。

2. 每一層網絡都限制來源

在防火牆、雲端 Security Group、容器網絡及反向代理層面，只允許明確可信的來源。不要單靠「內部路由」或「看似本機」的標頭作為身份證明。

3. 驗證並覆寫 Proxy 標頭

在邊緣 Proxy 拒絕不符合預期的 Host 值。若必須轉發，應將上游 Host 標頭覆寫成已知固定值，而不是盲目轉發客戶端提供的內容。對 X-Forwarded-For 等客戶端 IP 標頭，亦只應在它們來自受控 Proxy 時才信任。

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

管理功能及內部 RPC 操作應由獨立的身份驗證和授權保護，例如強身份驗證閘道、mTLS，以及按操作細分的存取控制。Host 標頭檢查可以協助路由判斷，但絕不能成為唯一的身份控制。

5. 收窄模型提供者探索及對外連線風險

如非必要，停用或限制 llm.discoverModels。如必須使用模型提供者探索功能，應建立提供者端點白名單，並配合對外流量控制。封鎖通往敏感內部地址、雲端 metadata 服務及其他不必要目的地的連線，可以減低提供者探索路徑被濫用成伺服器端請求工具時的影響。DSH 的 LLM 文件確認，提供者登記及模型探索是其公開能力的一部分。23

6. 只按官方資料確認修復版本

現有來源指出 0.1.1-rc.2 是受影響版本，亦顯示項目之後仍有版本活動；但資料並未證明任何特定後續版本已修復這個漏洞。因此，升級前應查閱 DeepSeek 最新的 Release Notes 及安全公告，確認官方明確列出修復內容後，才可視為完成修補。項目本身的安全聲明亦繼續提醒 Harness 屬實驗性軟件，並不適合當作已準備好投入生產環境的安全產品。410

7. 如曾經暴露，進行入侵追查及換密鑰

檢查反向代理及 DSH 日誌，留意異常 /api 請求、偽造本機格式的 Host 值、未預期的模型提供者登記、新程序、檔案變更及異常對外連線。輪換所有 DSH 服務程序可以接觸到的憑證。如果發現指令已被執行或存在持久化跡象，應隔離並重建受影響主機或容器，不要以為重新啟動服務便已清除入侵。