實證研究發布於 AIA: 2026年9月15日

AI 程式開發 agent 只要對本機發出一個請求，就能自己把沙箱關掉

DeepSeek Harness 是 DeepSeek 推出的開源本機工具，用來執行 AI 程式開發 agent，提供瀏覽器操作介面，背後則是一個只跑在 loopback 位址（也就是連回自己這台電腦的本機位址）上的 HTTP 控制 API。資安公司 OX Security 發現，這個 API 根本沒有做身分驗證：程式裡只有一個函式會去讀 HTTP request header (標頭) 中的 Host 欄位，只要值看起來像本機位址就放行，完全沒有比對這條連線真正的來源位址。再加上沙箱只擋檔案寫入、沒有擋網路，agent 自己的 shell 就能呼叫這個 API，把當前工作階段改成 danger-full-access 並關掉核准提示，這個漏洞的識別編號是 CVE-2026-82533（CVE 是公開資安漏洞的識別編號）。

Permission BypassLocal Agent TakeoverIdentity & AccessAI Coding Agent

6 項對應的 AIDEFEND 防禦手法

來源: CVE-2026-82533: DeepSeek Harness AI agent sandbox escape

作者: Nir Zadok and Moshe Siman Tov Bustan, OX Security

原文發布: 2026年9月8日

威脅分析

三個預設值剛好湊在一起。 第一，控制 API 沒有任何身分驗證，只有一道檢查 Host 標頭的機制，而程式碼註解本身就寫明「這道圍籬不是驗證層」。第二，沙箱雖然禁止寫入檔案，卻和主機共用同一個網路命名空間，所以 loopback 一直都連得到。第三，agent 的 shell 環境變數裡，本來就帶著這個介面的網址與當前工作階段的識別碼。
一個命令，就改掉了這個工作階段自己的規則。 只要 README、程式碼註解或 issue 裡夾帶攻擊者寫好的文字，就可能誘使 agent 對本機 API 送出一個 curl 請求，執行 /permission danger-full-access 這個命令。這個動作會寫入權限預設集、改變沙箱模式，並把核准政策設成 never。OX 用對照測試證實了效果：兩個工作階段採用相同預設集、下相同命令，只有先做過那次 API 呼叫的那一個，才能寫到工作區以外的地方。
沒有人被問過，畫面上也看不到。 一般命令本來就不需要核准，核准機制只管「要求提升權限」這件事；而這次呼叫並沒有提出提升權限的要求，它是直接改掉設定。OX 指出，工作階段記錄中完全沒有出現核准事件，而且這次變更被記成來源是使用者，因為這套工具分不出來，是 agent 自己的 shell 還是坐在鍵盤前的人送出的請求。
修補關上了門，但沒有封住走廊。 0.1.2-alpha.1 版新增了啟動 token，換成一份帶簽章的 cookie，之後每次呼叫 API 都必須帶著它。不過這次修補並沒有重新限制 loopback 的網路連線，而且目前沒有來源能說明，在新的機制下，沙箱裡的 agent 是否仍然有辦法取得一個有效的工作階段。

適用的 6 項 AIDEFEND 防禦手法

AID-H-021.004

Control-Plane & Oversight-Surface Isolation

極高

agent 的執行環境，不應該讀得到也改得動那些用來監督它自己的設定，包含它自己的沙箱模式與核准政策。把執行環境的身分和控制面分開之後，就算 agent 被完全挾持、而且手上有 shell，這條提權路徑一樣走不通，因為「改變自己的拘束條件」屬於管理動作，它根本沒有立場執行。

AID-I-001.004

Sandbox Network Egress Restrictions

極高

這裡的拘束只作用在檔案層面：bubblewrap 啟動時沒有隔離網路命名空間，macOS 的設定檔也是「除了寫入檔案以外全部允許」，所以控制連接埠永遠只差一個請求的距離。把預設拒絕的目的位址政策放在沙箱外部強制執行，那個請求就根本發不出去。這一項仍然要由部署方自己負責，因為官方修補只補上了身分驗證，並沒有重新限制 loopback 的連線。

AID-H-004.002

Service & API Authentication

極高

請求標頭是呼叫者自己填的，證明不了呼叫者是誰。每一次控制面呼叫都要求出示真正的憑證，並以簽發者與路由綁定來驗證，而不是靠對方自稱的主機名稱，這正是官方後來推出的做法：用啟動 token 換取一份帶簽章的 cookie。同一道驗證，也保護了那條可以匯出已儲存對話記錄的路徑。

AID-D-015

High-Risk Approval Bypass & HITL Activity Detection

高

這次提權之所以完全隱形，正是因為它沒有留下任何核准紀錄，而且被歸屬成使用者的操作。把每一次權限或核准政策的變更，都拿去比對是否有一份綁定通過驗證之操作人員的簽署核准，這份沉默就會變成一筆可查的異常；一個找不到對應人工決策的變更，恰好就是這項控制要找出來的訊號。

AID-H-003.010

Deployed AI Software Vulnerability Remediation Lifecycle

高

升級路徑要對照「實際裝得到的版本」來確認：0.1.2-alpha.1 確實含有修補，但只發布在 GitHub 上，npm 上第一個帶修補的版本是 0.1.2-alpha.2。應盤點開發者機器上實際安裝的版本，以及任何內嵌這套工具的桌面應用程式，並以實際執行中的版本為準，而不是看釋出說明（release notes）。

AID-M-001.005

Public AI Endpoint & Agent-Service Exposure Discovery

中

這套工具本身拒絕綁定公開網路介面，所以要能從遠端連到，前提是有人自己用通道、SSH 轉送或編輯器的連接埠轉送把它導出去。由外而內的曝露掃描，就是用來找出這些被轉送出去的 agent 介面；這件事之所以重要，是因為只要這個連接埠被連到，攻擊者不需要任何驗證就能控制 agent，並下載所有已儲存的對話記錄。

身為資安防禦者，我們應該這麼做

升級到真正含有修補的版本，並且以實際安裝的版本為準而不是看標籤：請從 npm 安裝 0.1.2-alpha.2 或更新的版本，因為 0.1.2-alpha.1 只存在於 GitHub。也要檢查任何自帶一份 harness 的桌面應用程式或 IDE 外掛。
把 agent 的本機控制介面當成特權面來看待。如果你的工具也有這樣一個介面，就要求出示沙箱內程序拿不到的憑證，並且絕不把請求標頭當成呼叫者身分的證明。
沙箱要一併限制網路，不能只限制檔案寫入。一個擋得住寫入、卻放行 loopback 的拘束設定，等於讓被關住的程式碼還是連得到那個在監督它的服務。
不要把本機 agent 的連接埠轉送或打通到自己這台機器以外的地方。如果開發者為了方便已經這樣做了，要把這些轉送找出來關掉，因為同一個介面還能匯出完整的對話記錄。
記錄權限模式與核准政策的每一次變更並設定警示，而且每一筆都要能對應到一個通過驗證的人工決策。一筆記成使用者操作、背後卻找不到核准紀錄的變更，正是這類逃逸會留下的訊號。

結論

這個沙箱完全照設計運作，而問題恰恰就在這裡：它被設計來擋住檔案寫入，但真正需要保護的，是那個決定「沙箱允許什麼」的介面。一旦 agent 的 shell 連得到那個介面，而介面又只信任一個任何人都能自己填的標頭，拘束條件就變成了被拘束的程序自己可以改的設定。AIDEFEND 把這條路徑對應到幾道彼此獨立的控制：讓執行環境碰不到自己的控制面、把沙箱的限制從檔案延伸到網路、每一次控制面呼叫都要求真正的憑證，以及在權限變更找不到對應的人工核准時主動示警。