AI 安全
GitSpawn 利用儲存庫本機 Git 設定，繞過七款程式代理的執行核准
惡意專案可把命令寫入 `.git/config` 的 `core.fsmonitor`，等待代理背景執行 `git status` 或 `git diff` 時在主機啟動。部分產品已修補，但事件顯示代理沙箱若未涵蓋啟動與版本控制程序，工具核准仍可能被底層程式繞過。
Cloud Security Alliance 9 月 4 日整理 Manifold Security 揭露的 GitSpawn 漏洞群：Claude Code、Codex、Cursor、Goose、Qwen Code、Grok Build 與 Hermes Agent 都曾存在相關路徑。問題不在模型受到提示注入，而是代理為建立工作區上下文，會在使用者輸入指令前自動呼叫 Git。
Git 的 `core.fsmonitor` 原本是大型儲存庫的效能功能；其值除了布林值，也能是外部 helper 的路徑。若專案連同既有 `.git/config` 被複製到電腦，`git status` 等會刷新 index 的操作便可能以目前使用者權限執行攻擊者指定程式。由於子程序由 Git 啟動，而非模型提出的工具呼叫，它可能避開代理的命令核准、稽核紀錄與沙箱政策，甚至早於「信任此工作區」提示。
這不是一般 `git clone` 即可傳播的攻擊：Git 不會從遠端複製來源儲存庫的本機設定。風險主要出現在 ZIP、共享磁碟、同步資料夾、備份或 USB 等會保留整個 `.git` 目錄的交付方式。揭露時八項發現中仍有四項未修補，狀態也可能隨新版快速改變。
Codex 的公開程式碼展示一種較完整的處理方式：內部 Git 命令覆寫 `core.fsmonitor`，只在確認值為布林 `true` 且 Git 支援內建 daemon 時保留功能，其他情況一律降為 `false`。工程團隊不應只更新代理版本；還應在開啟外來專案前檢查 `.git/config`，把代理啟動、索引、外掛與 VCS helper 納入同一威脅模型，並搜尋其他可由儲存庫設定觸發外部程式的 Git 選項。