部落格 發布於 AIA: 2026年5月3日

OpenAI Codex 漏洞：惡意 GitHub 分支名稱如何偷走 GitHub token

BeyondTrust Phantom Labs 報告指出，OpenAI Codex 建立任務時，會把 GitHub 分支名稱帶進容器初始化用的 shell 指令，讓惡意分支名稱變成命令注入（command injection，外部輸入被接進 shell 指令後，變成額外命令執行）。攻擊成功後，可以偷到 Codex 用來存取 GitHub 的 OAuth token，或 GitHub App 安裝後取得的短效存取 token；自動化版本還能透過共享 repo 裡的惡意分支，影響多個使用 Codex 的開發者。OpenAI 已修補 BeyondTrust 回報的問題，但防禦重點仍然很清楚：repo 中繼資料（metadata）不能被當成安全的 shell 輸入，agent 使用的 token 也必須縮小權限範圍、避免外洩，並且能快速撤銷。

Command InjectionCredential TheftInput ValidationAI Coding AgentGitHub Security
9 項對應的 AIDEFEND 防禦手法
來源: How Command Injection Vulnerability in OpenAI Codex Leads to GitHub Token Compromise 
作者 Tyler Jespersen, BeyondTrust Phantom Labs · 原文發布: 2026年3月30日

威脅分析

  • GitHub 中繼資料被帶進 shell 指令。 BeyondTrust 發現，Codex 建立任務的 HTTP 請求裡有一個 branch 參數；這個分支名稱後來會進到容器初始化流程，用來複製指定 repo、切到指定分支。
  • 分支名稱變成命令注入的切入點。 攻擊者可以在 GitHub 分支名稱裡放 shell 特殊字元，讓原本應該只是分支名稱的字串跳出原本的指令內容，改成在 Codex 容器裡執行攻擊者指定的命令。
  • 真正被盯上的是 Codex 任務使用的 GitHub token。 Codex 在複製 repo 或做程式碼審查時，會使用 OAuth token 或 GitHub App 安裝後取得的短效存取 token。注入的命令可以把含 token 的 Git remote 設定或任務輸出複製出來，再送到攻擊者控制的伺服器。
  • 攻擊可以靠 repo 本身放大。 只要攻擊者有建立或修改分支的權限，就能在共享 repo 裡放惡意分支；甚至可以用全形空白字元（Unicode U+3000）把惡意指令藏起來，或把惡意分支設成預設分支，讓其他使用 Codex 的人也觸發它。
  • 本機 Codex 憑證讓攻擊路徑更多。 BeyondTrust 也提到，Codex CLI、SDK 和 IDE 擴充功能會在 ~/.codex/auth.json 存放敏感憑證；如果開發者電腦被入侵，攻擊者可以拿這些憑證呼叫 Codex 後端 API，讀取任務歷史或容器 log。

適用的 9 項 AIDEFEND 防禦手法

AID-H-026.003
Pre-Execution Static Scan
極高
repo 中繼資料一旦被接進 Codex 的初始化指令，就會變成可執行的輸入。複製 repo、checkout 或環境初始化指令真正執行前，應先掃描最後形成的指令或可執行設定檔，擋下 shell 特殊字元、命令替換、隱藏 Unicode 空白和把資料送出去的可疑模式；同時，底層也要改用結構化的程序呼叫，而不是把字串直接拼成 shell 指令。
AID-H-019.005
Value-Level Capability Metadata & Data Flow Sink Enforcement
極高
這次被偷的不是一般字串，而是可以代表使用者或 GitHub App 執行操作的 GitHub token。agent 平台應該把 token 標成高機敏的執行期值，並阻止它流向不安全目的地，例如之後可能被模型讀到的檔案、任務 log、對外 HTTP 請求、shell 參數，或會出現在提示詞和回應裡的輸出。
AID-H-004.002
Service & API Authentication
極高
Codex 需要 GitHub 存取權，才能複製 repo、做程式碼審查或開 PR，但這些憑證應該短效、範圍很小、綁定特定用途，而且離開該任務就不能重用。repo、分支、工作流程和組織層級權限都要收斂，避免一個被偷的 token 變成攻擊者存取整個 GitHub 組織的入口。
AID-M-009.003
Agent Identity, Delegation Lineage & Runtime Authorization
高
每個 Codex 任務都是代表某個使用者或 GitHub App 執行動作。容器任務應該帶有可追責的執行期身分、被委派的 GitHub 範圍、repo、分支、任務 ID 和到期時間。這樣出事時，防禦方才知道是哪個 agent 任務、基於誰的授權、用哪個 token 做了哪些操作，也知道該撤銷哪一段權限。
AID-H-019.004
Intent-Based Dynamic Capability Scoping
高
使用者的需求可能只是審查某個分支，或詢問某個 repo 的問題。當下有效的 Codex 權限範圍應該跟著任務縮小：指定 repo、指定分支、允許的 GitHub 動作、允許的網路目的地，以及可讀取的任務歷史。分支名稱裡的惡意內容不應該有機會把這次工作階段變成 token 外洩或跨 repo 的 GitHub 存取。
AID-I-001.004
Sandbox Network Egress Restrictions
高
BeyondTrust 的自動化攻擊版本，是讓 Codex 容器對外連到攻擊者控制的伺服器，把 token 送出去。如果容器在初始化和執行時都有預設拒絕對外連線、只允許少數必要目的地，命令注入就算成功，也比較難把資料傳出去。
AID-H-029.002
Client Credential Secure Storage & Lifecycle Management
高
BeyondTrust 也指出，Codex CLI、SDK 和 IDE 應用程式會在 ~/.codex/auth.json 存放 OpenAI 帳號 token 和 refresh 相關憑證。本機 agent 憑證應該優先使用作業系統安全儲存機制，縮短有效時間，登出時清理，並支援伺服器端取消授權，避免開發者電腦被入侵後，這些憑證被再次拿來存取 Codex 後端。
AID-D-005.002
Security Monitoring & Alerting for AI
中
防禦方應該對可疑的 repo ref（例如分支或標籤名稱）觸發警示，例如分支名稱包含 shell 特殊字元、反引號、${IFS}、異常 Unicode 空白、可疑的預設分支變更、Codex 初始化錯誤、容器對未知主機的外連，以及任務 log 裡出現疑似 token 的字串。
AID-E-001.002
Automated & Real-time Invalidation
中
只要懷疑 token 已外洩，處理速度不能等人工工單。GitHub OAuth token、installation token、Codex access token、refresh token 和任務工作階段，都應該在 canary 觸發、log 暴露 secrets，或 GitHub API 使用異常時自動撤銷，並讓撤銷結果立刻在服務端生效。

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

  • 先確認 OpenAI 修補已套用到團隊使用的 Codex 產品，接著盤點所有已授權 Codex 或類似 coding agent 的 GitHub 組織和 repo。
  • 審查 Codex 類 agent 的 GitHub App 權限和使用者 OAuth 授權。若任務只需要單一 repo、單一分支或唯讀審查能力，就不要給組織層級的過大權限。
  • 把 GitHub 分支名稱、ref 名稱、repo 名稱、PR 標題、issue 文字和初始化參數，都當成不可信輸入。只要它們會進 agent 容器、shell 指令、初始化腳本或 log，就要先檢查、轉義，必要時直接拒絕。
  • 限制 Codex 容器在初始化和執行時的對外連線。只有必要時才允許套件 registry 和 GitHub 端點，並對未知外連主機觸發警示。
  • 在 GitHub 或 repo 端加入偵測：分支 ref 如果包含 ;、|、反引號、${IFS}、命令替換語法，或可疑 Unicode 空白，就要觸發審查；近期預設分支變更也要一起檢查。
  • 如果可能已經外洩，立即撤銷 Codex 相關 GitHub token、輪替受影響憑證、檢查 GitHub audit log 的 token 使用紀錄，並檢查 Codex 任務歷史和容器 log 裡是否出現 token 內容。

1 個額外的防禦考量

在 GitHub 端管好分支名稱與預設分支

除了上面對應的防禦技術，使用 AI coding agent 的開發與資安團隊，也應該在 repo 端先管好 agent 會讀取的中繼資料。對 GitHub 來說合法的分支名稱，不代表被另一個系統貼進 shell 指令時也安全。
建議做法: 用 GitHub 規則集（ruleset）、分支保護、可用時搭配接收前檢查（pre-receive hook）或 CI 檢查，擋下包含 shell 特殊字元、可疑 Unicode 空白、命令替換語法的分支或 ref，避免 AI agent 還沒開始工作，就先讀到有問題的分支名稱。

結論

這個 Codex 案例提醒我們，agent 風險不一定要等到模型開始寫程式才出現。GitHub 分支名稱原本只是 repo 中繼資料（metadata），但只要被接進 agent 容器裡的 shell 指令，就會變成可執行輸入。AIDEFEND  在這裡對應到最重要的防禦手段和觀念：避免不安全的命令執行、阻止 token 流進 log 或對外 HTTP 請求、縮小服務憑證的權限範圍、把每個 agent 任務綁到可追責身分、限制容器對外連線、監控可疑的 repo 中繼資料，並快速撤銷已外洩 token。