一條指令逃出沙箱：CVE-2026-82533 讓 DeepSeek 215k 星標的編碼代理人親手關掉自己的牢籠

一條指令，零次提示

2026 年 9 月 8 日，OX Research 的研究員 Nir Zadok 與 Moshe Siman Tov Bustan 發表了一份應該成為 2026 年所有 AI 編碼代理人開發團隊必讀的漏洞揭露：一個在 DeepSeek Harness——這套開源、本機優位的代理人執行環境，也是今年成長最快的開發者工具之一——沙箱內執行的代理人，可以用一條 shell 指令解除自己的禁錮。不需要對外曝露網路。不需要任何憑證。不需要偏離出廠預設值一絲一毫。

這個漏洞已被編號為 CVE-2026-82533，CVSS 4.0 評分 9.4（CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H），並於 8 月 27 日在 DeepSeek Harness 0.1.2-alpha.1 中修復——距離 OX 於 8 月 24 日向 VulnCheck（CNA）提報僅三天。如果你還在跑 0.1.1-rc.2 或更早的版本，修法很簡單：升級。

但版本號是這個故事裡最不有趣的部分。CVE-2026-82533 值得細讀的原因，在於它揭露了整個業界打造代理人沙箱的方式——以及兩個各自看來都合理的設計決策，如何組合成一個能讓「被你關起來的東西」自己開門走出去的漏洞。

DeepSeek Harness 是什麼，為什麼重要

DeepSeek Harness——用戶暱稱 dsh——是 DeepSeek 的開源本機 AI 編碼代理人執行環境。它提供一個瀏覽器 UI，背後由 127.0.0.1:3080 上的本機 HTTP API 支撐，並採用「Everything is a Plugin（一切皆插件）」架構：模型、工具、技能、session、沙箱與儲存全部可插拔。2026 年 8 月發布後，它在數週內突破 215,000 個 GitHub 星標，成為今年最多人收藏的開發者工具之一。

這份人氣正是這次揭露威力十足的原因。編碼代理人執行環境是高價值攻擊目標的理由，與它好用的理由完全相同：它握有一個 shell。代理人讀寫你的原始碼樹、執行你的建置與測試指令，並以啟動它的開發者的完整權限運作——潛在涵蓋 SSH 金鑰、雲端憑證、套件庫 token，以及那台工作站上所有觸及得到的內部系統。沙箱，就是站在「不可信輸入」（一份惡意的 README、一張被下毒的 issue、一頁被提示注入的網頁）與上述所有權限之間的那道防線。CVE-2026-82533 拆掉了這道防線——而且不是靠漏洞串接，而是靠設計上的疏忽。

逃逸的解剖學

根本原因是一堂關於「HTTP 層的信任是什麼意思」的課。一個名為 isTrustedApiRequest 的函式讀取請求的 Host 標頭，只要值是 loopback 位址或出現在設定的 trustedHosts 清單中就放行。關鍵在於：它從未將這個值與連線的實際 peer 位址比對。

程式碼註解顯示這個檢查是為了防禦 DNS rebinding 而寫，而且對那個威脅確實有效：瀏覽器無法對 Host 說謊，所以一個挾帶攻擊者網域的 rebinding 請求會被正確拒絕。但 request.headers 是這個函式唯一使用的輸入。一個不受瀏覽器限制的客戶端——比如說，沙箱內的代理人執行的一句 curl——大可自己填一個受信任的 Host 值。

OX 用兩個只差在 Host 標頭、其餘完全相同的請求示範了差別：外來主機被擋下；自我宣稱的 loopback 暢行無阻。

沙箱接著完成了剩下的工作。DeepSeek Harness 將代理人執行的指令放進 OS 沙箱——依平台不同採用 bubblewrap、Landlock 或 Seatbelt。OX 檢視的兩份沙箱設定檔都限制了檔案系統、卻放行了網路：bubblewrap 參數帶了 --unshare-pid 但沒帶 --unshare-net，因此網路命名空間與主機共用；Seatbelt 設定檔用 (allow default) 疊上 (deny file-write*)——檔案寫入被拒，其餘一切（包括 loopback）全部允許。另外，普通的 bash 工具呼叫不需要核准——核准管的是沙箱「升級」請求，不是日常指令執行。

把這三個事實擺在一起，逃逸路徑就自己寫出來了。沙箱內的代理人對 harness 自己那個未驗證的 127.0.0.1:3080 API 下一條指令，把自己的 session 升級成 danger-full-access、核准設為 never。session 紀錄記下了這次政策變更——歸因欄位寫的是 source: {kind: 'user'}，因為 harness 分不清代理人的 shell 與鍵盤前的人類。之後的每一條指令都在無禁錮、無提示的狀態下執行。

OX 用對照實驗驗證了沙箱在逃逸前確實在正常執法：兩個 session、同樣的預設 preset、同一條指令——先下過那道解除禁錮 curl 的 session 成功寫入工作區以外的 /home/ubuntu；被禁錮的 session 則被擋下。

第二條攻擊路徑

只要 3080 埠因為任何原因變得從 loopback 以外可達——隧道、反向代理、SSH port forward、編輯器 port forward 或類似機制——這個未驗證介面就容納了第二個、更傳統的攻擊者：一個未驗證的遠端方可以完全控制代理人，並且可以另行在沒有 API key、不呼叫模型的情況下，下載所有已儲存的對話紀錄。

這第二條路把一個本機權限漏洞，變成了任何曾把 dsh 埠轉進容器、透過 SSH 轉到遠端主機、或經過編輯器整合的開發者的資料外洩漏洞。編碼代理人的對話歷史是個出乎意料敏感的產物：私有 repo 的內容、除錯時貼上的憑證、基礎設施細節，以及未發布程式碼背後的思路，全都在裡面。

為什麼這不只是 DeepSeek 的問題

把 CVE-2026-82533 歸檔為「DeepSeek 的 bug，修好了，下一條」很誘人。但那會錯過重點。這裡有三個結構性教訓，適用於每一個打造代理人執行環境的團隊：

信任標頭，就會被標頭欺騙。 用客戶端可控的標頭把關本機 API，是一種在「本機優先」開發者工具裡反覆出現的範疇錯誤。瀏覽器對 Host 受到約束；shell 沒有。任何需要判斷「這個請求是不是來自我的 UI？」的本機控制平面，都必須驗證連線的 peer 位址，而不是客戶端的自我介紹。

只擋檔案系統的沙箱，不是代理人沙箱。 這裡的沙箱設定檔是以「阻止代理人亂改檔案」的心理模型寫成的。但 2026 年的代理人，危險的能力與其說在磁碟、不如說在網路——它能呼叫本機 API、觸及雲端 metadata 端點、聯繫所有信任那台工作站的服務。--unshare-net 只花一個旗標；省略它，悄悄把一份檔案寫入政策變成了完整的逃逸路線。

核准層必須綁定身分，而不是綁定機制。 整份揭露裡最寒人的細節是歸因：授予 danger-full-access 的那次政策變更，紀錄上來自使用者——因為 harness 分不出代理人的 shell 和開發者的敲鍵。如果代理人能合成出與人類授權無法區分的輸入，核准提示就只是演戲。代理人執行環境需要一個以密碼學或結構強制的通道分離：「人類核准了這件事」與「人類啟動的某個東西核准了這件事」，必須是兩個無法混淆的命題。

一場做得對的揭露

這裡的流程值得與漏洞本身同等關注。OX Research 在預設安裝上以實際執行確認漏洞，於 2026 年 8 月 24 日向 VulnCheck（CNA）提報；DeepSeek 在 8 月 27 日於 0.1.2-alpha.1 交付修復——三天週轉——OX 於 8 月 30 日對修補版重測並確認修復，之後 CVE 才於 9 月 8 日發布。有驗證修復的協同揭露、有紀錄的時序、有附重現細節的公開技術報告——這是業界其他人應該拿來要求自己的標準。

給第一個月就給 dsh 按下星標的數十萬開發者：檢查你的版本，升級到 0.1.2-alpha.1 或更新，並稽查你的環境裡有沒有任何東西曾經轉送過 3080 埠。給其他正在打造代理人基礎設施的人：這次事件留下的檢查清單很短、也不客氣——你的本機 API 必須以 peer 位址驗證；你的沙箱必須切斷網路，除非任務真的需要；你的核准事件必須能歸因到一個人類。

會改寫自己政策的沙箱，不再是自主代理人的假想失敗模式。它以預設設定上架、拿到了 215,000 顆星，然後只花了一條指令。