逃離 OpenAI Codex 沙盒的兩種方法：Heapjack 與 Overpatch

2026 年 9 月 15 日，Accomplish AI 首席安全研究員 Oren Yomtov 發表了一份技術說明，描述兩種各自獨立、可逃離包圍 OpenAI Codex 程式設計代理之沙箱的方法。根據他的報告，兩者均於 2026 年 8 月 12 日向 OpenAI 通報，且都在八天內修復：Codex Desktop 組建 26.818.21641 中的 Heapjack，以及 Codex CLI 0.149.0 中的 Overpatch。Heapjack 是兩者中較嚴重的一個。被攻擊者除了在 Codex 中開啟儲存庫並就程式碼提出問題之外，無需做任何事；而且它是在唯讀模式下執行——這是產品提供的最嚴格模式——不會出現核准提示，畫面上也不會顯示任何內容。根據雲端安全聯盟（Cloud Security Alliance），這兩個漏洞都沒有獲配 CVE，OpenAI 也沒有發布獨立公告，且未有任何通報顯示有人因此受害。它與今年其他代理控制條目一同收錄於AI 事件檔案，其中每筆紀錄都附有來源文件、信心等級與爭議標記。

Heapjack：權杖存放在不受信任端可讀取的堆積中。

Codex Desktop 在安裝 Yomtov 所攻擊的元件之前並不會詢問使用者。安裝時，它會將一個 node_repl 區塊寫入位於 ~/.codex/config.toml 的全域設定檔，而 Yomtov 指出，這既沒有選擇加入的機制，也沒有任何可以將其關閉的設定。由於該項目存在於共用設定之中，而非取決於個別使用者的選擇，一般的 Codex CLI 使用者會在從未被詢問的情況下，一併繼承同一個工具。

node_repl 工具本身是一個原生程式，執行於沙箱之外。它可以開啟應用程式、連線至 Unix socket，並編輯全域設定檔。它在沙箱內啟動的是一個單一 Node.js 程序，而該程序持有兩個 JavaScript 執行環境：一個受信任、包含 OpenAI 自家程式碼的環境，以及一個不受信任、執行代理被要求執行之任何內容的環境。

受信任的上下文透過出示每次執行時全新產生的隨機權杖，來證明自己受信任。這本應是兩個上下文之間的邊界。但它並不是，因為這兩個上下文都活在單一 V8 isolate 中，共用單一記憶體堆積，所以權杖只是存放在記憶體裡的一個字串，不受信任的程式碼可以讀取它。一位在 X 上對該揭露做出回應的留言者更直白地表達了這點，BleepingComputer 引述了他的一句話：「V8 上下文隔離的是全域物件，不是記憶體，所以這個沙箱其實是記憶體堆積從未同意過的承諾。」那是一種描述，不是證據；證據是概念驗證。

Yomtov 的漏洞利用程式完全符合該描述的含意。不受信任的 JavaScript 會呼叫 v8.getHeapSnapshot()，掃描產生的快照中形似 UUID 的字串，並逐一測試每個候選值。猜錯時會回傳「not authorized」。正確的權杖搭配無效引數時，反而會回傳真正的驗證錯誤。這兩則錯誤訊息之間的差異，就是辨識出正確值的預言機。

取得權杖後，沙箱化行程會將自己的 JSON 請求寫入檔案描述符 1——也就是受信任環境用來觸及原生父行程的同一條標準輸出管線。父行程會驗證權杖，找到有效的權杖，然後執行工作。在概念驗證中，這項工作就是系統 open 指令，它會將請求交給 launchd，並完全在 Codex 的行程樹之外啟動應用程式。同一權杖允許連線至任意 Unix 通訊端，其中包括 Docker 守護行程通訊端，並可觸及用於編輯全域設定檔的工具。

這一切都在唯讀模式下執行，而這正是謹慎的使用者會選擇的模式，因為眼前這個儲存庫並不受信任。整個過程的任何階段都沒有出現核准提示。實務情境很短：在 Codex 中以唯讀模式開啟一個複製下來的儲存庫，並針對程式碼提出問題。撰寫該儲存庫的人就能在這台機器上取得不受沙箱限制的指令執行權限，而螢幕上完全沒有任何提示說明此事。

Overpatch：一款修補工具，會把它所觸及之所有對象的父項授予出去

第二個缺陷位於 Codex CLI 這個開源命令列代理中，而且這是權限漏洞，不是記憶體漏洞。在 workspace-write 模式下，代理只能寫入專案資料夾內，不能寫入其他任何地方；針對家目錄的 shell 命令會被拒絕。apply_patch 工具原本應該守住這條界線。但它卻從正在套用的修補程式中指定的路徑推導權限，並授予對每個路徑上層目錄的寫入權限。

在修補程式中指定 /tmp 底下的一個路徑，授權範圍就會擴大到磁碟的根目錄，因為 /tmp 的父目錄就是 /。這就是整個把戲。

這個運作中的漏洞利用在單一修補程式中使用了兩個項目。第一個項目指定 /tmp 且不做任何有用的事——它會失敗，因為檔案無法覆寫目錄——存在的唯一目的就是擴大授權範圍。第二個項目則透過指向家目錄的符號連結，將一行內容附加到 .zshrc。移除第一個項目，寫入就會被拒絕。保留它，開發者下次開啟的終端機就會在沙箱之外執行攻擊者的那一行，而沙箱從頭到尾都不再參與其中。

這使得 Overpatch 成為持久化問題，而非一次性攻擊。被污染的啟動檔會在開發者每次開啟 shell 時再度執行，直到有人去讀 .zshrc 並注意到被附加的那一行——這正是為什麼雲端安全聯盟（Cloud Security Alliance）的指引是主動去找出這類後門，而不是等待症狀浮現。

這兩個錯誤都把強制執行機制放進了被強制執行的對象內部。

Yomtov 自己的論述框架，是能跨越 Codex 之外的部分。apply_patch 根據攻擊者提供的輸入，自行計算出自己的權限。node_repl 將區分受信任與不受信任程式碼的祕密，保存在不受信任程式碼可讀取的記憶體中。在每個案例中，沙箱都是從內部被指示要放行某些東西。

這類攻擊手法並不新穎。BleepingComputer 於 2026 年 9 月 20 日報導了這項披露，並指出 Pillar Security 研究人員曾於 2026 年 7 月在 Cursor、Codex、Gemini CLI 和 Google 的 Antigravity 上展示相同構想：一個始終待在沙箱內的代理程式寫入檔案，之後由沙箱外受信任的工具執行該檔案。Codex 這對漏洞的特別之處，在於 Heapjack 中的唯讀繞過，以及完全沒有任何設定可停用承載該繞過的元件。

這些修正，以及 OpenAI 說了什麼、沒說什麼

根據 Accomplish，OpenAI 在 Codex Desktop 組建 26.818.21641 中修復了 Heapjack，並在 Codex CLI 0.149.0 中修復了 Overpatch。兩項修復都在 8 月 12 日報告後的八天內完成——單就該時間線的字面解讀而言，最遲是在 8 月 20 日——而 Yomtov 將這次迅速轉變歸功於 OpenAI。

OpenAI 並未針對這兩個漏洞發布獨立的安全性公告，也未指派 CVE 識別碼；雲端安全聯盟（Cloud Security Alliance）在 2026 年 9 月 22 日的一份研究備註中記錄了這兩項缺失。OpenAI 發言人在被要求置評時告訴 BleepingComputer：「我們感謝研究人員與我們聯繫並分享他們的研究發現。我們已在八月處理這兩個問題，但我們持續強化沙箱，近期更新收緊了代理程式可寫入檔案位置的控制，並擴大跨平台對這些防護措施的測試。」

那份聲明確認了這些修正，卻對機制隻字未提。它沒有說明八月的變更是移除了該設計模式，還是封閉了從中脫身的兩條具體路徑。OpenAI 之外的任何人也都沒有這麼說。

哪些是已確立的，哪些僅仰賴單一研究者

檔案庫將此條目歸類為研究發現，嚴重程度高，地區為全球，可信度 B——有文獻記載，但僅來自單一或二手來源——並無爭議，且未記錄到實際損害。這個評級是閱讀本文其餘部分的合適視角，因為多方確認的內容與僅由發現者主張的內容之間的分野，貫穿整個故事。

已確立，就多方都這麼說的意義而言：

• 該披露確實存在，並載有日期。Yomtov 的報告於 2026 年 9 月 15 日發表；兩個缺陷均已於 2026 年 8 月 12 日通報給 OpenAI，而根據他的說法，兩者都在八天內獲修復。

• OpenAI 確認已於八月採取行動。其發言人向 BleepingComputer 表示，這兩個問題都已處理，這獨立於發現者佐證了回報與修復的時間線，儘管該公司並未發布任何公告，也未自行發布技術說明。

已修復版本的說法一致。Codex Desktop 的組建 26.818.21641 與 Codex CLI 的版本 0.149.0 由 Accomplish 提供，BleepingComputer 重複報導，並刊載於烏干達國家電腦緊急應變小組與協調中心 2026 年 9 月 22 日的公告中；該公告將兩者評為「紅色」。

• 沒有 CVE、沒有廠商公告，也沒有任何已通報的漏洞利用情形。雲端安全聯盟（Cloud Security Alliance）於 2026 年 9 月 22 日的說明指出，既無 CVE，也無獨立的 OpenAI 公告，且未回報任何已確認的案例顯示有組織發現 Overpatch 的持久化機制存在。

• 檔案並未對其中任何內容提出異議。該紀錄被標記為「爭議：否」，其可信度評級反映的是來源模式，而非對事實有任何分歧。

尚未確立，或僅由發現者確立：

• 機制細節出自 Yomtov。堆積快照預言機、共用檔案描述符、父目錄授權——全都來自他的文章與概念驗證。雲端安全聯盟（Cloud Security Alliance）的註記是流通中最詳細的第三方摘要，文中描述其綜合了 Yomtov 的敘述與 BleepingComputer 的報導，且未聲稱其重現了任一漏洞利用或測試了任一修補。CERT.UG 的公告彙編了相同資料。

• 含有漏洞的版本範圍從未公布。只有修復版本被列出，因此沒有清單說明哪些較早的建置版本帶有各項缺陷。

• 已修補的安裝是否能免於這類漏洞，而不只是免於這兩個個案，並未說明。OpenAI 的「持續強化我們的沙箱」是一般性承諾，並非對特定機制的宣稱。

• 目前尚未有人被通報利用過這兩個漏洞。這只是「沒有通報」，而非「確認不存在」；而概念驗證顯示，Heapjack 這條攻擊路徑不會在畫面上留下任何痕跡，使用者根本無從察覺。

使用者可據以行動的內容

任何使用早於 26.818.21641 的 Codex Desktop 組建，或早於 0.149.0 的 Codex CLI 版本的人，都位於 Accomplish 所劃定界線的脆弱一側，而更新是該披露所提供的唯一補救方式。除此之外，Cloud Security Alliance 建議稽核過去涉及不受信任儲存庫的 Codex Desktop 工作階段，檢查是否有 launchd 或開啟中的活動，以及是否有 Docker socket 連線，並讀取 shell 啟動檔案——.zshrc、.bashrc 及其對應檔案——查看是否有並非由使用者撰寫、而是被附加進去的命令。

同一則註記也建議，當儲存庫不可信任時，不應把唯讀模式當成保護措施，而這正是 Heapjack 自身被迫得出的結論。它的結構性建議更進一步：以實體行程與記憶體隔離取代共享密鑰與慣例、將憑證保存在代理無法觸及之處，以及把引用專案外部路徑的修補程式一看到就視為可疑。那些都是第三方提出的建議。OpenAI 除了兩次版本號提升之外，是否已採用其中任何一項，並未公開。

最後有兩件事值得區分開來。其一是廣泛使用的編碼代理中的一對程式錯誤，於 2026 年 8 月 12 日提報，八天內修復，並在兩個組建編號中結案。另一件則是 Yomtov 所指名的設計問題——沙箱能否由它本應容納的程式碼來強制執行——而這個問題並非版本號所能回答。無論是 Accomplish 還是 OpenAI，都未曾表示八月的變更已解決了這個問題。