如何審查以下載形式收到的 Git 專案，防止 AI 編碼智能體執行倉庫設定中的命令

在讓編碼 Agent 指向從下載取得的資料夾之前，先執行一個命令：

git -C /path/to/repo config --local --list --show-origin

如果輸出包含 core.fsmonitor、core.hooksPath、attr.tree，或 filter. 或 diff. 底下任何指名某個命令的內容，就要停止。該檔案中像 fsmonitor = ... 這樣的一行，是一個程式，git 下次更新索引時會執行它；而 git status 和 git diff 會更新索引。這是工具中最不起眼的兩個命令，也正是你的 Agent 在工作階段啟動時會執行、用來瞭解分支及變更內容的命令。

GitSpawn 是甚麼

Manifold Security 在 2026 年 9 月初披露了七個命令列編碼 Agent 的八項漏洞，並將這個問題命名為 GitSpawn。這種攻擊模式分為三個部分。

執行端：core.fsmonitor 是 git 中一項正當且有文件記載的效能設定。它的值是一個命令，git 會執行該命令以瞭解哪些檔案有所變更，讓大型儲存庫免於完整掃描檔案系統。Git 會從儲存庫本身的 .git/config 讀取該值。

觸發條件：CLI 編碼 Agent 會在你開啟專案時於背景呼叫 git status 或 git diff，以建立所需上下文。它們在此過程中不會修改儲存庫的設定。儲存庫設定輸入，git 在背景呼叫，命令隨即執行。

後果：該命令會以你的用戶身分，在你的裝置上、Agent 沙盒之外執行，而且不會經過核准提示。根據 Manifold 的測試（如下方報道所述），Claude Code 和 Hermes Agent 會在工作區信任提示獲接受前執行載荷。Qwen Code 會在你完成驗證前執行載荷。Grok Build 則會在你按下第一個按鍵時執行載荷。

這不是提示詞注入，也不是 MCP 設定錯誤。載荷完全不會接觸模型，而是藏在 git 中繼資料內；觸發它的是產品本身的底層運作機制。

受影響對象

以下是 Manifold 於 9 月 1 日重測時的狀況快照，也是最近一次發布的數據：

Agent	發布時狀態
goose	已於 1.44.0 修正，CVE-2026-72718 (CVSS 7.0)
OpenAI Codex CLI	已於 0.131.0 修正，CVE-2026-19592
OpenAI Codex Desktop	已修正，CVE-2026-19593
Cursor	已修正
Claude Code，`core.fsmonitor` 路徑	已於 2.1.196 修正
Claude Code，`claude ultrareview` 背後的第二條路徑	在 2.1.252 仍未修補；使用不同的設定鍵，Manifold 尚未公開
Hermes Agent	在 0.21.0 仍未修補，CVE-2026-71963
Qwen Code	在 0.22.3 仍未修補
Grok Build	在 1.0.13 仍未修補

後續公開資料並不完整：Hermes 於 9 月 2 日合併修正，並於 9 月 7 日推出標籤 0.21.1；而 10 月 8 日的 0.21.6 版本則修補了另一類問題，當中篩選程式由不可信儲存庫的設定定義。Qwen Code 於 9 月 12 日合併修正。截至 10 月中旬，Claude Code 的第二條路徑、Cursor 和 Grok Build 的公開資料仍然有限。請查閲供應商的更新記錄，不要只依賴此表。

據報，七個 Agent 的每月 npm 下載量合計超過 7,700 萬次，其中 Claude Code 佔比最大。這個數字來自披露內容，並由相關報道轉述，因此應視為報稱數字，而非經審核的數據。

為何 clone 操作安全，而資料夾並非如此

git clone 絕不會攜帶 .git/config。Clone、fetch 和 pull 會傳輸已提交的內容和 refs，而非來源儲存庫的本機設定。要發動攻擊，儲存庫必須以檔案形式送到你手上，而且其 .git 目錄完整保留：例如承辦商提供的 zip、供應商共用雲端硬碟中的檔案、同步的專案資料夾、USB 手指，或附在支援工單上的重現案例封存檔。

這聽起來似乎很冷門，直到你數一數有多少次「可否幫我看看這個？」是以 zip 檔形式送來。如果你的工作流程中有任何情況是「儲存庫以下載檔形式送到你手上」，你便屬於威脅模型涵蓋範圍。

Agent 接觸資料夾前的審核

將此檔案儲存為 audit-repo-config.sh，並在任何從組織外部取得的目錄執行：

#!/usr/bin/env bash
# audit-repo-config.sh - flag command-valued git settings in a received folder
# usage: bash audit-repo-config.sh /path/to/repo
set -u
repo="${1:-.}"

echo "== all local settings, with origin =="
git -C "$repo" config --local --list --show-origin

echo
echo "== settings whose value can name a program =="
git -C "$repo" config --local --list \
  | grep -Ei '^(core\.fsmonitor|core\.hookspath|core\.pager|core\.editor|core\.sshcommand|attr\.tree|filter\.[^ ]*\.(clean|smudge|process|required)|diff\.[^ ]*\.command|alias\.[^ ]*)=' \
  || echo "(none)"

echo
echo "== hooks that are not samples =="
find "$repo/.git/hooks" -type f ! -name '*.sample' 2>/dev/null || echo "(no hooks directory)"

echo
echo "== attributes file =="
cat "$repo/.gitattributes" 2>/dev/null || echo "(no .gitattributes)"

core.pager=less 和 core.editor=vim 屬正常項目。清單上的其他項目，在 Agent 開啟資料夾前都應由人手檢視。

以下按優先次序排列：

從標準遠端儲存庫重新複製一份，並在全新的複本中工作。複製時不會帶入本機設定。這是最乾淨的修復方法，只需執行一條命令。
取消設定已知的設定鍵：git -C /path/to/repo config --local --unset core.fsmonitor。請視之為必要但非充分條件：claude ultrareview 路徑使用的另一個被隱藏設定鍵，代表單獨取消設定 fsmonitor 並不足以堵住所有入口。
在一次性容器或虛擬機中開啟真正不受信任的儲存庫，或使用一個無法存取 SSH 金鑰和雲端憑證的獨立用戶帳戶。這段負載會在 Agent 的權限模型之外執行，因此 Agent 自身的各種模式也無法保護你。應在作業系統層面設置隔離邊界。

問題不只在 fsmonitor

Git 有一系列可指定程式的設定，其中一些會在一般唯讀指令期間執行。clean 和 smudge 篩選器在 .git/config 中設定，並由 .gitattributes 按檔案啟用；Git 執行普通的 status 時也可能執行它們。core.hooksPath 會重新導向 hooks 目錄。attr.tree 指向屬性樹。別名設定的值以 ! 開頭時，便會執行 shell 指令。

Manifold 在多篇報道中被引述的總結直截了當：任何指定程式的設定，都可能執行該程式。在 Windows 上以 Git 2.55 實際重現，確認了 core.fsmonitor 和 filter.*.clean 兩個執行途徑，並展示負載讀取環境變數；這正是憑證竊取可能採用的手法。

這類問題早於 Agent

這個確切的漏洞以前已修正過。Claude Code 2.0.34 在 November 2025 停止於信任核准前執行 git status；但這種行為在 June 2026 的 2.1.193 中再次出現。同一類執行途徑幾年前已透過不同名稱影響 IDE。CVE-2021-43891 涉及開啟資料夾時執行惡意的 .git/config；Microsoft 在 1.63.1 將 Git 整合功能置於工作區信任機制之後，修正了這個問題。CVE-2022-24346 是 JetBrains 的相應漏洞，從 IntelliJ 2021.3.1 起已採取緩解措施。

只修補啟動次序問題並不足以持久解決。信任檢查必須永久涵蓋每一次 Git 呼叫，並加入回歸測試，否則問題會不斷重現。

如果你正在開發這類工具

有位開發者開發了一款用來閲讀 Agent 編寫程式碼的 IDE，發現自己的產品也有同樣問題：開啟資料夾時，會在你讀取任何一行程式碼前於背景呼叫 Git 三次。他的修正方法是在產品組建所有 Git 命令的單一位置套用 git -c core.fsmonitor=false，並加入使用惡意儲存庫的測試，確保修正持續有效。他着手調查約十分鐘後，修補版本便已推出；這正是重點：這類錯誤藏在工具中沒有人會看的部分，因為那些部分「只是呼叫 Git」。

同一週也出現了這波事件的其他案例：Plugin4Shell 中，攻擊者建立一個以外掛所鎖定的提交雜湊值命名的分支，令自動更新在不知情下拉取惡意程式碼；「Fable to Haiku」中，程式碼庫的子代理程式設定將安全審查工作交給一個較小型的模型，並設定為略過 tests 資料夾，主代理程式之後執行的測試套件則會執行隱藏載荷；PixelLeak 中，無法將螢幕截圖附加到拉取要求的代理程式，改為把超過 300 個機構的 13,000 多張內部螢幕截圖提交到程式碼庫，其中一些程式碼庫是公開的。機制各異，共通之處是：所有人都把專案檔案視為不會執行任何操作的檔案。

應將代理程式開啟的程式碼庫視為不可信輸入，包括其中的設定檔。在首次 git status 之前先進行審核，否則重新複製程式碼庫，便不會遇到這個問題。

來源：

Manifold Security，《GitSpawn 披露》，2026 年 9 月上旬（主要報告；涵蓋七個代理程式的八項發現，以下內容是透過下列文章查閲，並非直接取得）
Jason Miller，《GitSpawn：.git/config 中的一行設定，便能讓你的編碼代理程式變成命令執行器》，dev.to，2026 年 10 月 11 日（原刊於 axeploit.com）：https://dev.to/secbyjasonmiller/gitspawn-one-line-in-gitconfig-turns-your-coding-agent-into-a-command-runner-ho4 及 https://axeploit.com/blog/gitspawn-the-git-performance-flag-that-turns-coding-agents-into-command
urion，《你的代理程式執行了 git，程式碼庫也一樣》，dev.to，2026 年 10 月 13 日：https://dev.to/urion/your-agent-ran-git-so-did-the-repo-1dom
Diego Rodriguez，《GitSpawn：強化 AI 編碼代理程式，防範 Git 設定檔 RCE》，diego-rodriguez.work，2026 年 10 月（公開紀錄時間線）：https://www.diego-rodriguez.work/blog/gitspawn-coding-agent-git-config-rce-2026-hardening
FreeBuf（中文安全媒體），《一個惡意 .gitconfig 如何令七款 AI 編碼助理在開啟程式碼庫時立即執行你的命令》（由原中文標題翻譯），2026 年 10 月 15 日（Windows 重現、npm 下載量數字）：https://www.freebuf.com/articles/ai-security/506604.html
Vibe Code Basics，《AI 編碼代理程式漏洞（2026 年 10 月）：GitSpawn、Plugin4Shell》，2026 年 10 月（這波事件的整理）：https://www.vibecodebasics.com/blog/ai-coding-agent-security-october-2026
Thomas Chauchefoin 和 Paul Gerste，《保障開發者工具安全：Git 整合》，SonarSource，2021 年（CVE-2021-43891 和 CVE-2022-24346 的起源）：https://blog.sonarsource.com/securing-developer-tools-git-integrations

我沒有直接開啟 Manifold Security 報告本身。七個代理程式涉及八項發現、各代理程式的狀態表、觸發時機，以及 2026 年 9 月的日期，均與上述五篇文章的説法一致。每月 77 million 次 npm 下載量的數字由 FreeBuf 提供，我沒有核實。Codex、goose 和 Hermes 的 CVE 編號與那些文章所報相同；我沒有查閲這些編號的 NVD 紀錄。至於較早的兩個 IDE 編號 CVE-2021-43891 和 CVE-2022-24346，我有根據 Microsoft 的公告，以及報道這些編號的 SonarSource 文章進行查核。本文中的審核指令碼由我自行編寫，只會讀取文字。

本文在 AI 協助下撰寫，作者對內容負責。