OpenAI Codex被曝3處致命漏洞

AI編程助手正在接管開發者的鍵盤，但沒人告訴過你，它也可能成為黑客的特洛伊木馬。

Phantom Labs安全團隊上周披露的一組漏洞，把OpenAI Codex變成了攻擊者潛入企業代碼倉庫的跳板。他們演示了如何通過一個精心構造的分支名，讓AI助手親手把自己的GitHub訪問令牌交出來。

漏洞核心：當分支名變成攻擊載荷

Codex的工作流程聽起來很干凈——用戶提交需求，系統在云端啟動容器，AI在里面寫代碼、分析倉庫、提交修改。但BeyondTrust的研究員發現，這個流程在容器啟動階段有個致命疏忽。

問題出在GitHub分支名的處理上。當Codex準備環境時，會把用戶指定的分支名直接寫進啟動腳本，沒有任何過濾。攻擊者只需要把一個shell命令藏進分支名，就能在容器初始化時執行任意代碼。

演示用的攻擊載荷長這樣：一個看似正常的分支名里嵌入了重定向指令，把系統環境變量中的GitHub OAuth令牌輸出到臨時文件。然后攻擊者再"禮貌地"請Codex讀取這個文件，令牌就以明文形式出現在聊天界面里。

Phantom Labs的研究員把這叫作"AI供應鏈攻擊的新變種"。傳統的命令注入需要找到輸入口，而Codex的設計讓攻擊者有了無數個入口——每個被AI處理的分支都可能是一個。

本地攻擊：你電腦里的認證文件也不安全

云端漏洞只是開始。研究團隊接著發現了桌面版Codex的軟肋：認證憑據被明文存儲在本地文件里。

Windows、macOS、Linux三平臺無一例外。攻擊者一旦拿到開發者機器的訪問權限，就能直接復制這些會話令牌。用它們向Codex后端API認證，可以拉取該用戶的完整任務歷史。

任務日志里藏著什么？每次Codex操作GitHub倉庫時留下的訪問令牌。這些令牌通常帶有廣泛的倉庫權限，因為用戶授權時圖方便，很少細粒度限制AI助手的動作范圍。

橫向移動的路徑就此打通。從一臺失陷的開發機，到整個組織的代碼資產，中間只隔了幾個API調用。

自動化攻擊：惡意分支能自己傳播

最棘手的攻擊場景不需要受害者主動交互。攻擊者直接在共享倉庫里創建一個惡意分支，命名上做點手腳——用Unicode表意空格替代普通空格，視覺上和main分支幾乎無法區分。

GitHub的分支名限制被用內部字段分隔符繞過。當其他開發者或CI流程觸發Codex處理這個分支時，注入的代碼靜默執行，把令牌外傳到攻擊者服務器。

Pull Request場景同樣中招。開發者@Codex做代碼審查時，系統啟動審查容器，惡意分支名里的載荷隨之運行。整個過程對發起審查的人完全透明。

Phantom Labs測算，這種"毒分支"可以在大型開源項目或企業內部倉庫中被動傳播，感染所有使用該倉庫的Codex用戶。AI助手的便利性在這里變成了攻擊面的放大器——它讓代碼倉庫的每個參與者都成了潛在的泄露節點。

OpenAI的修復與未解的問題

漏洞披露后，OpenAI在72小時內推送了補丁。分支名輸入現在經過嚴格過濾，本地認證文件的存儲方式也被重構。但安全社區的討論沒有停止。

核心爭議在于AI代理的權限模型。Codex需要GitHub令牌才能工作，這意味著它必須持有高權限憑證。傳統工具鏈里，這些憑證由開發者手動管理、按需使用；AI助手把它們變成了長期駐留的系統組件。

BeyondTrust在報告中提到一個細節：部分企業客戶在漏洞披露前已經注意到異常令牌活動，但歸因困難——Codex的自動化操作和正常用戶行為在日志里難以區分。當AI成為開發流程的默認配置，安全監控的基礎設施還沒有跟上。

GitHub去年發布的AI安全指南曾警告"過度授權"風險，建議為AI工具創建專用機器賬戶并限制倉庫范圍。但調研顯示，實際配置中很少人愿意犧牲便利性來做權限隔離。

Phantom Labs的研究員在技術博客末尾留了句話：「我們測試了主流AI編程工具，Codex不是唯一有這類問題的。」其他產品的容器隔離、輸入驗證、憑證管理是否經得起同樣 scrutiny，目前沒有公開答案。

企業安全團隊現在面臨一個選擇題：是收緊AI工具的使用范圍，還是押注廠商能快速修補這類架構性弱點？