AI 安全／程式代理
GitSpawn 藉惡意 `.git/config` 繞過程式代理沙箱，四項漏洞披露時仍未修補
多款 CLI 程式代理會在信任確認前執行 Git 狀態查詢，讓儲存庫內的可執行設定以使用者權限在主機運行。攻擊不會經一般 `git clone` 傳播，但透過 ZIP、同步資料夾或 USB 交付完整 `.git` 目錄即可觸發。
Manifold Security 披露名為 GitSpawn 的共同弱點：Claude Code、Codex、Cursor、Goose、Hermes Agent、Qwen Code 與 Grok Build 等 CLI 代理啟動時，會在背景呼叫 `git status`、`git diff` 等指令蒐集專案上下文。Git 刷新索引時會讀取儲存庫自身的 `.git/config`；若 `core.fsmonitor` 被設成攻擊者控制的程式，Git 便會依原本設計直接執行它。由於子程序由代理主機端程式產生，命令可在沙箱外、批准提示前，以啟動代理的帳號權限運行。[Manifold 的技術披露](https://www.manifold.security/blog/ai-coding-agents-git-hijack)表示八項通報中，Codex、Cursor、Goose 與 Claude Code 的主要啟動路徑已修補；截至 9 月 1 日重新測試，Qwen Code 0.22.3、Grok Build 1.0.13、Hermes 0.21.0，以及 Claude Code 2.1.252 的 `ultrareview` 路徑仍受影響。Goose 漏洞編為 CVE-2026-72718，Hermes 則為 CVE-2026-71963；[The Hacker News](https://thehackernews.com/2026/09/malicious-git-configs-can-make-claude.html)亦確認披露時有四項尚未修補。
攻擊邊界需要說清楚：正常 clone、fetch 或 pull 不會攜帶儲存庫本機設定；攻擊者必須把含 `.git` 的整個目錄經 ZIP、共享磁碟、同步服務或實體媒體交付。這仍是實際的供應鏈入口，因為顧問交件、事件鑑識檔案及內部專案快照常以這類方式流通。工程團隊應先更新代理、在隔離環境檢查陌生 `.git/config`，並讓代理所有背景 Git 呼叫顯式覆寫 `core.fsmonitor=false`。只封鎖這一鍵仍不充分：`core.hooksPath`、外部 diff／merge 工具等設定也可能指向可執行檔，長期修正應是將儲存庫設定視為不可信輸入，並把上下文蒐集納入同一套授權與沙箱邊界。