DeepSeek Harness CVE-2026-82533：受沙箱隔離的代理只需一個指令即可停用自己的沙箱

VulnCheck 於 2026 年 9 月 8 日發布 CVE-2026-82533：這是一個重大（critical）的身分驗證繞過漏洞，可讓 AI 程式碼編寫代理用單一 shell 指令關閉自己的沙箱。受影響軟體為 DeepSeek Harness，這是 DeepSeek 專為程式碼編寫代理打造的開源本機執行環境；Cloud Security Alliance 表示，它在數週內於 GitHub 累積約 215,000 顆星；0.1.2-alpha.1 之前的所有版本皆受影響。它依據呼叫端自行提供的 Host 標頭來判斷呼叫端是否為本機，因此請求可佯稱來自迴路位址。由於其沙箱僅限制檔案寫入、未限制迴路網路，受沙箱限制的代理可呼叫該 harness 在 3080 埠上未經身分驗證的控制 API，並將其工作階段切換為 danger-full-access，且關閉核准機制。VulnCheck 將其評為 9.4 分，屬重大等級；目前並未聲稱已有實際濫用案例。該紀錄只是 AI 事件公開資料集中的一筆，而 the Orca AI Incident Archive 收錄了完整紀錄集，包含每筆事件的日期、嚴重程度分級與來源。

那個詢問請求本身是什麼的檢查

有漏洞的元件是 harness 的本機代理程式控制 API，也就是網頁介面與命令列用來驅動執行中工作階段的小型 HTTP 服務。根據 Cloud Security Alliance 於 2026 年 9 月 10 日發布的研究筆記（該筆記引用發現此漏洞的公司 OX Security 的報告），該服務預設在 127.0.0.1 的 3080 埠上監聽，並在筆記稱為 isTrustedApiRequest 的函式中做出信任判斷。該函式讀取 HTTP Host 標頭，並在該值符合 localhost 或 127.0.0.1 等回送名稱時授予存取權。Host 標頭是客戶端寫入的中繼資料；它完全無法說明 TCP 連線來自何處。The Hacker News 於 2026 年 9 月 9 日引用受影響的原始碼報導，該檢查從未查看連線的來源，且同一檔案中的註解寫道，該檢查「並非身分驗證層」。

這就是 CWE-807 的全部內容：在安全決策中依賴不受信任的輸入；而這正是 VulnCheck 已發布紀錄所描述的：接受由客戶端提供的回送（loopback）Host 標頭，而非驗證實際的 TCP 連線來源。

把一個有缺陷的檢查變成逃逸路線的，正是 harness 把代理自己的鑰匙交到它手上。The Hacker News 報導，harness 會把控制介面的位址和當前工作階段的識別碼傳給代理的 shell，因此指令不必自行找出其中任何一項。另一方面，沙箱只涵蓋了其中一個通道，另一個則沒有：受影響版本的命令列參考文件指出，在預設設定下，寫入會留在工作區和暫存資料夾內，而讀取與網路存取則不受限制。

為什麼核准提示沒有阻止它

這個執行框架確實有核准提示，但與其說它們遭到繞過，不如說它們根本不適用。The Hacker News 報導指出，在受影響的版本中，只有當某個指令試圖取得比工作階段既有權限更廣泛的存取權時，才會要求核准。那次提權呼叫並沒有要求這類權限；它變更了工作階段的設定。執行該呼叫的代理程式進入了 OX Security 稱為 danger-full-access 的模式，核准提示被設為「永不」，並繼續以啟動該執行框架的使用者身分執行，完全置身沙箱之外。

OX Security 對這道邊界提出的證據是一組受控對照。The Hacker News 報導，該公司以完全相同的預設設定執行兩個工作階段，並對兩者下達相同指令：發出呼叫的工作階段寫入其工作區外的資料夾，另一個工作階段則遭到封鎖。

第二條路徑，以及它所需的前提。

同一個遺漏的檢查讓該執行框架暴露於從未身處沙箱內的呼叫者，但僅限於預設設定並未建立的某種條件下。命令列拒絕將 API 綁定到所有網路介面，因此只有在使用者已自行轉送該連接埠時，才能從其他地方觸及該連接埠——依據 The Hacker News 的說法，轉送方式包括通道、反向代理、SSH 轉送，或編輯器本身的連接埠轉送功能；Cloud Security Alliance 的說明也列出同一組方式。VulnCheck 的公告指出，在該前提成立時，沒有憑證的呼叫者可以建立工作階段、執行任意命令，並外洩儲存的對話逐字稿。The Hacker News 補充，同一個介面可回應一個會下載工作階段完整日誌的請求。

沙箱化路徑需要不同的先決條件：代理程式將讀取並據以行動的文字。Cloud Security Alliance 的說明指出，受限制的代理程式會處理內嵌於程式碼註解、README 檔案或 issue 文字中、由攻擊者提供的提示詞。這兩條路徑都不需要竊取來的金鑰，而該說明也指出，一旦連接埠暴露，遠端路徑完全不需要與模型互動。

因此，受影響的族群是任何在預設設定下執行 0.1.1-rc.2 或更早版本 harness 的人，而星標數只能粗略暗示這個集合。The Hacker News 於 2026 年 9 月 9 日統計到超過 216,000 顆星標，並提醒星標只是書籤，而非安裝。

什麼是已經確立的，什麼不是

根據 CVE 紀錄本身可確認：VulnCheck 是編號機構，於 2026 年 8 月 29 日保留該識別碼，並於 9 月 8 日 16:59 UTC 發布紀錄；弱點為 CWE-807；受影響範圍為 0.1.2-alpha.1 之前的所有版本；致謝歸於 Nir Zadok 與 Moshe Siman Tov Bustan。紀錄所帶的兩個分數，CVSS 4.0 下的 9.4 與 CVSS 3.1 下的 9.6，來自 VulnCheck，而非第二位獨立評分者——NVD 列出這兩項指標，並以 VulnCheck 為來源——因此它們是同一項評估以兩套框架表達，而非兩項評估彼此一致。

根據儲存庫確認：修正提交 3e24087 標題為「fix(web): authenticate the browser Host API」，日期為 2026 年 8 月 24 日；依據 GitHub API，該提交新增了一個瀏覽器驗證模組，以及 210 行針對新流程的端對端測試。標籤為 dsh-v0.1.2-alpha.1 的版本接著於 8 月 27 日 17:06 UTC 發布。

尚未確立：使用。無論是 CVE 記錄、VulnCheck 的公告，還是 DeepSeek 的發布說明，都未描述在野利用情形，而 NVD 將漏洞利用成熟度記錄為未定義。FIRST 的 EPSS 模型在日期為 2026 年 10 月 27 日的資料饋送中，給予該漏洞在接下來 30 天內被利用的機率為 1.24%，位於第 68.9 百分位。該檔案庫未記錄此條目的任何現實世界危害，並將其評為信心 A、文件記載充分，且主要來源彼此一致。

日期，包括最先送來的兩份報告

兩名開發者在還沒有 CVE 可指向之前，就得出相同結論。The Hacker News 報導，該專案自家討論區於 2026 年 8 月 13 日的一篇貼文顯示，一個仍受沙箱限制的行程可觸及本機介面，並將工作階段切換為 danger-full-access，且附有測試輸出；8 月 14 日的第二篇貼文則列出該介面在未經憑證下所接受的請求。第二篇貼文也指出，該專案沒有安全性政策檔案，也沒有私下回報漏洞的管道；The Hacker News 於 9 月 9 日查核，發現安全性政策檔案仍舊缺失。

OX Security 的時間線將其向 VulnCheck 提交報告的日期定為 2026 年 8 月 24 日——與 GitHub 記錄的修復提交日期相同。該提交訊息對這份報告隻字未提，而據 The Hacker News 描述，OX Security 的公開說法並未提及較早的社群貼文。8 月 24 日發生的這兩件事是否相關，公開紀錄並未說明，本文也不作此假設。

修復與披露之間的落差並不罕見。Cloud Security Alliance 的說明記載，OX Security 於 8 月 30 日確認修復完成，比 VulnCheck 發布 CVE 早了九天。

修正落地之處，以及未落地之處

GitHub 標籤與套件註冊表並未同步更新，而如果你依照其指示安裝該測試框架，這正是值得知道的部分。命令列套件 @deepseek-ai/dsh 於 2026 年 8 月 21 日發布 0.1.1-rc.2，之後一直到 8 月 30 日的 0.1.2-alpha.2 才再有更新。CVE 指為修正版本的 0.1.2-alpha.1 完全不在註冊表中，因此第一個可安裝的修正版本比修正晚了三天。本文於 2026 年 10 月 28 日讀取 npm 註冊表中繼資料；The Hacker News 於 9 月 9 日報導了同樣的落差。

發行說明並未將其定位為安全性發佈。它們在例行變更中列出，網頁介面現在要求網路存取須使用一次性權杖驗證，既沒有 CVE 參照，也沒有安全公告，而 The Hacker News 於 9 月 9 日在該儲存庫的公告清單上找不到任何安全諮詢。如 Cloud Security Alliance 所述，該機制是：測試載具會在啟動時印出一次性權杖，瀏覽器以該權杖換取簽署過的 Cookie，之後每次呼叫都必須出示該 Cookie——信任是綁定到程序啟動時發出的祕密，而非綁定到所宣稱的網路來源。

第三方建置是懸而未決的隱患。桌面封裝程式各自隨附一份測試框架，因此使用者執行的是哪個版本，取決於封裝程式的維護者；The Hacker News 發現，一個 Windows 建置在八月底固定使用 0.1.1-rc.2，於 9 月 6 日改為 0.1.3-alpha.1，而後者包含該修正。

沙箱本身並未改變。The Hacker News 在閱讀 0.1.2-rc.1 命令列參考文件時，發現了同樣的陳述：讀取與網路存取並未受到限制，並且發現代理程式的 shell 仍會收到介面位址。該報導中沒有任何消息來源說明，在其工作區內運作的代理程式是否仍能在新方案下取得有效的工作階段；這個問題在修補程式自身的文件中仍未解答。

紀錄的來源建議什麼

• 將任何版本為 0.1.1-rc.2 或更早的安裝視為受影響，無論其封裝方式為何，包括內嵌於桌面包裝器中的副本。

• 從 npm 安裝 0.1.2-alpha.2 或更新版本；2026 年 10 月 27 日 registry 上的最新版本為 0.2.2-alpha.2。

• 如果您無法升級，請在不使用時停止網頁介面，並移除任何可連線至連接埠 3080 的通道、代理或連接埠轉送。

• 檢查連接埠 3080 是否可從 loopback 以外的任何位置連線，包括容器連接埠轉送、反向代理和 SSH 通道。

• 在框架層級記錄權限提升與核准模式的變更，因為這起攻擊之所以得逞，正是讓未經授權的權限提升看起來像例行活動。

這五項都來自 Cloud Security Alliance 的公告與 The Hacker News 的報導；CVE 記錄本身除了已修復版本外，並未提供任何補救指引。

為什麼雲端安全聯盟會將其解讀為一種模式

雲端安全聯盟的說明將此 CVE 與其在 2026 年記錄的其他兩起程式碼代理隔離失效並列：7 月 1 日的 GuardFall，事件中 11 個熱門開源程式碼代理有 10 個可被誘導執行其防護欄原本要阻擋的 shell 指令；以及 7 月 22 日的信任交接發現，事件中受隔離的代理寫入了一個檔案，後來由沙箱外受信任的元件執行。該說明明確指出，這三起事件都來自其自身研究，而非對市場的全面調查，且該模式是否會推廣到其所檢視代理之外的範圍，尚未確立。它確實主張的是，這些失效位於不同層次——指令防護欄、下游信任，以及如今的控制平面驗證——因此建議將沙箱架構視為採購問題，而非已滿足的要求。

DeepSeek 自身的安全文件並未與這種解讀相牴觸。該儲存庫的 SAFETY.md 指出，該軟體「尚未接受安全稽核，且不得被視為安全或可供生產使用」，而沙箱化、核准提示與權限控制「並不保證隔離，也無法防止損害」。在目前的建置版本中，那個讓代理程式得以透過控制 API 脫離的驗證缺口已被補上。讓這次脫離之所以如此輕易的不對稱——寫入有邊界，網路卻毫無邊界——仍是沙箱明列的限制，而非該修補集旨在修正的缺陷。