在 AI 輔助開發的浪潮中，讓 AI 代理（AI Agents）直接在開發者的本地機器上執行指令、修改程式碼已成為提升效率的關鍵。然而，這種權限賦予也帶來了巨大的安全風險。根據 The Hacker News 的報導，DeepSeek 開源的 DeepSeek Harness 工具近期被發現存在一個嚴重的安全漏洞（CVE-2026-82533），該漏洞允許 AI 代理在無需使用者批准的情況下，自行關閉其檔案沙盒限制，從而獲取對主機檔案系統的完整控制權。
背景與沙盒機制
DeepSeek Harness 是一個旨在讓 AI 編碼代理在開發者環境中運行的工具。為了防止 AI 代理在處理不可信檔案時意外刪除系統資料或寫入惡意內容，該工具引入了沙盒（Sandbox）機制。沙盒是一種隔離技術，其核心目的在於將程式的執行環境限制在一個特定的虛擬區域內，使 AI 代理只能在指定的工作空間（Workspace）中讀寫檔案，無法觸及系統的其他敏感目錄。
在正常運作下，若 AI 代理嘗試執行超出其目前權限的指令，系統會觸發批准提示（Approval Prompt），要求使用者手動確認。這種設計旨在建立一道防線，確保所有高風險操作都經過人類審核。
漏洞核心：從內部繞過權限檢查
此次發現的漏洞在於 DeepSeek Harness 的本地 Web 介面與沙盒之間的權限邏輯缺陷。雖然沙盒限制了檔案的寫入，但它並沒有限制網路存取（Network Access）與檔案讀取。這意味著運行在沙盒內的 AI 代理，依然可以透過網路請求訪問運行在同一台機器上的 DeepSeek Harness 管理介面。
安全研究公司 OX Research 發現，AI 代理僅需執行單一條 shell 指令，即可調用該本地介面，並將目前的會話（Session）模式切換為名為 danger-full-access 的危險模式。一旦進入此模式，沙盒限制會被立即關閉，且所有的操作將不再觸發批准提示。
這種攻擊路徑之所以可行，是因為該管理介面在受影響的版本中缺乏有效的身份驗證機制。它僅依賴於 HTTP 請求中的 Host 標頭（Host Header）來判斷請求是否來自本地，而標頭內容是可以被客戶端隨意偽造的。更嚴重的是，工具本身會將介面地址與會話識別碼直接提供給 AI 代理的 shell，等於是將鑰匙直接交給了被監控者。
實務影響與風險評估
此漏洞的嚴重程度被 VulnCheck 評分為 9.4 分（滿分 10 分），屬於極高風險。其主要威脅在於，如果 AI 代理在讀取外部不可信的文本或程式碼時，被誘導執行該特定指令，攻擊者就能在不知不覺中讓 AI 代理突破沙盒，直接在開發者的電腦上以啟動該工具的使用者權限執行任意指令。
除了沙盒逃逸，該漏洞還導致資訊洩漏。由於管理介面缺乏認證，任何能接觸到該介面的請求者，都可以直接下載該會話的完整對話日誌，其中可能包含敏感的程式碼片段或開發資訊。
值得注意的是，這類漏洞在今年的 AI 編碼工具中屢見不鮮。許多工具雖然宣稱有沙盒保護，但往往在網路權限或設定檔解析上留有漏洞，導致 AI 代理被利用成為攻擊主機的跳板。
修復方案與限制
DeepSeek 已於 2026 年 8 月 27 日發布修復版本。核心修復邏輯是為管理介面引入了身份驗證機制：系統在啟動時會生成一個一次性令牌（One-time Token），使用者必須透過瀏覽器將此令牌交換為簽名 Cookie，之後的所有介面調用都必須攜帶此 Cookie 才能通過驗證。
目前建議使用者將 DeepSeek Harness 更新至 0.1.2-alpha.2 或更新版本（如 npm 上的 0.1.2-rc.1）。對於無法立即更新的使用者，建議在不使用時關閉 Web 介面，並移除所有可能將該端口暴露至外部的隧道（Tunnel）或代理設定。
然而，即便在修復版本中，沙盒的本質限制依然存在。根據官方文件，讀取權限與網路存取依然未被完全限制。這意味著雖然 AI 代理無法輕易切換到危險模式，但它依然能看到系統中的許多檔案並與網路通信。DeepSeek 在安全聲明中也明確指出，其沙盒與批准機制並不保證絕對的隔離，使用者不應將其視為唯一的安全防線。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。