2026 年下半年 Coding Agent 工具信任链的工程化失效正在从"个别 CVE"过渡到"系统性问题"。9 月 3 日 Manifold Security 在 Hacker News 发布《GitSpawn: Flaw Lets Untrusted Repos Run Code in Claude Code, Codex, Cursor, and Grok》,5 分首页关注——一篇工程级漏
2026 年下半年 Coding Agent 工具信任链的工程化失效正在从"个别 CVE"过渡到"系统性问题"。9 月 3 日 Manifold Security 在 Hacker News 发布《GitSpawn: Flaw Lets Untrusted Repos Run Code in Claude Code, Codex, Cursor, and Grok》,5 分首页关注——一篇工程级漏洞披露,展示了 Git Spawn 类问题——8 个 findings 跨 7 个 agent(Claude Code / Codex / Cursor / Grok Build / Hermes / Goose / Qwen Code),4 个仍然 unpatched(Claude Code ultrareview 路径 / Hermes / Qwen Code / Grok Build)。除了 fsmonitor 这条 sink 之外,Git Hook 同样是 Coding Agent 工具信任链里被严重低估的高危 sink——untrusted repo 的 .git/hooks/ 下的 pre-commit / post-checkout / post-merge 等脚本在 git 工作流触发时自动执行,任何 Coding Agent 在这类 repo 上跑 git 命令都会自动触发恶意脚本。结合 GitSpawn 的 fsmonitor sink、Git Hook sink、OneCLI 的 vault 设计、Talos 的 permission kernel,这四件事合起来,把 Coding Agent 工具信任链的完整工程失效样本摆到桌面上。
一、Git Hook 在 Coding Agent 场景下的真实威胁
Git Hook 不是新概念——Git 自身的设计就有 client-side hooks 用于自动化 commit / push / merge 流程。但 hooks 在 Coding Agent 场景下的威胁性被严重低估,因为 hooks 是 silent execution,不需 user approve,不被 sandbox 拦,执行时机恰好是 Agent 自动化流水线最频繁的节点。
具体威胁路径是 untrusted repo 包含 `.git/hooks/post-checkout` 或 `.git/hooks/pre-commit` 这种标准 hook 文件,内容是任意 shell 命令。攻击者把这个 repo 推上 GitHub、放在 zip 里分发、通过云盘 sync、塞进同事拷给 client 的目录——任何方式让 developer 把 .git 目录带进工作环境。然后 developer 用 Claude Code / Codex / Cursor 打开这个 repo,Agent 跑 `git status` 或 `git checkout` 或任何触发 hook 的 git 命令,hook 自动执行,任意 shell 命令以 developer 身份运行。这条攻击路径跟 GitSpawn 一样满足 fsmonitor 的所有条件——载体是 directory、攻击者拿到任意代码执行、hook 文件不需要额外 approve。
关键差异是 Git Hook 在 Git 自身的设计里就是如此。Git Hook 文件(`.git/hooks/*`)是 Git 设计就让用户编辑的脚本,用于自动化 commit / merge / push 流程。`.git/hooks/` 目录里的脚本是普通文件,默认 Git 不执行,但 `git init` 创建时自带 .sample 后缀,需要用户显式 chmod +x 或 mv 才能启用。问题在于很多 Git 客户端(包括 SourceTree、GitKraken、各种 IDE 集成)会自动 chmod 已存在的 hook 文件,而且 developer 之间互拷目录时通常把整个目录一起拷(包含 .git/),不会特意 strip hooks 目录。
二、Git Hook 跟 fsmonitor 的攻击面差异
Git Hook sink 跟 fsmonitor sink 在攻击面上有几个关键差异。
第一,触发频率。fsmonitor 在每次 git index refresh 时触发,Git Hook 在特定 git workflow(checkout / commit / merge / push)时触发。fsmonitor 的触发频率更高(几乎所有 git 命令都触发),Git Hook 触发频率相对低(只在特定 workflow 触发)。但 Coding Agent 场景下,checkout、commit、merge 这些 workflow 本身就是高频操作,Git Hook 触发频率实际不低。
第二,可见性。fsmonitor 的执行在 Agent 自己的 subprocess 里,不在 Agent 工作流上,Agent 看不到。Git Hook 的执行是 git 工作流的一部分,git 会显示 hook running 的输出。但 Coding Agent 在多任务并发时,hook 输出可能被淹没在长 context 里,developer 不一定注意到。
第三,绕过难度。fsmonitor 需要 git refresh index 才触发,Git Hook 需要特定 git workflow 才触发。两类攻击都需要 Coding Agent 在 untrusted repo 上跑 git 命令,但 Coding Agent 几乎一定会在新 repo 上跑 git 命令。
第四,影响范围。fsmonitor 影响所有触发 index refresh 的 git 命令,Git Hook 影响所有触发特定 hook 的 git workflow。两者 overlap 大但不重合——Coding Agent 跑 `git status` 触发 fsmonitor 但不触发任何 hook,跑 `git commit -m "..."` 同时触发 fsmonitor + pre-commit / post-commit hooks。
三、为什么 GitSpawn 这类发现具有系统性意义
Manifold 团队在 GitSpawn 文章里给出的最重要洞察不是单个 CVE,而是所有主流 Coding Agent 都共享同一类 git 调用路径假设——"git 命令本身无害"。这个假设在 Git Hook 场景下同样成立但更隐蔽,fsmonitor 至少需要在 .git/config 里写命令执行 sink,GitHook 直接在 .git/hooks/ 目录放可执行脚本,语义上更"自然"。
更关键的是,Manifold 团队在文章里点出"Coding agents do not just answer questions. They run tools, spawn processes, and act on endpoints with the privileges of whoever launched them, which is the point of running one. That is a layer the existing controls were not built for. EDR sees familiar developer tooling doing familiar things. The same shape shows up wherever an agent picks up something it did not write. Skills, MCP servers, and plugins arrive as files, carry their own configuration, and are trusted on arrival for the same reason a repository is. The artifact changes, the pattern does not."
这段话把 Coding Agent 信任链的根本问题点到了——agent 接的任何 artifact(repo / skill / MCP server / plugin)都以 file 形式到达,自带 configuration,被默认信任,因为"打开它就跑起来"。fsmonitor sink 和 Git Hook sink 只是这个 pattern 的两个具体实现,Skill 文件、MCP server config、Plugin metadata 都可以藏类似 sink。
四、把 Git Hook 跟其他 Agent 工具信任链 sink 对比
把 fsmonitor、Git Hook、Skill file、MCP config、Plugin metadata 这些潜在 sink 列成一张表,可以看到 Coding Agent 工具信任链的失效模式是统一的。
fsmonitor sink:藏在 .git/config 里,触发条件是 git index refresh,所有 git 命令都会触发。GitSpawn 文章披露 8 个 findings 中 6 个走这条。
Git Hook sink:藏在 .git/hooks/ 里,触发条件是特定 git workflow(checkout / commit / merge / push)。Coding Agent 在多任务流水线里频繁触发。修复方向:git config --add core.hooksPath /dev/null 或者 strip .git/hooks 在 open repo 时。
Skill file sink:藏在 Claude Code skill / OpenCode skill / Warp skill / 各 vendor skill 系统里。Skill 是 plain markdown 文件,理论上不应该执行,但如果 Agent 通过 Skill 安装 bash script(像 Warp 演示的 progressive disclosure),bash script 本身就是 sink。修复方向:Skill 执行必须有 explicit approve。
MCP config sink:藏在 .claude.json / .cursor/mcp.json / .vscode/mcp.json 里,触发条件是 MCP server 启动。Argus Security 6 月文章已经分析 MCP server 的安全模型——MCP 工具调用本身是被设计为 executable 的,所以 MCP sink 比 fsmonitor 更"自然"。
Plugin metadata sink:藏在 VS Code extensions / Chrome extensions / npm packages 里。Geiger 9 月 9 日发的资产可见性扫描就是为这个 sink 提供 visibility。
五类 sink 的共同点是 Coding Agent 默认信任 sink 所在 file,直接以 file 形式到达。Geiger 的扫描 + Manifold 的 GitSpawn 披露 + OneCLI 的 vault 隔离 + Talos 的 permission kernel 这四件事合起来,给出了应对 sink 的多层防护。
五、企业 Coding Agent 工具信任链的具体防护 checklist
把 fsmonitor + Git Hook + Skill + MCP config + Plugin metadata 五类 sink 合起来,企业 Coding Agent 工具信任链的防护应该满足如下 checklist。
第一条,任何 Coding Agent 在 open new repo 前必须 strip .git/hooks/。这是最直接的 Git Hook sink 防护,代价是失去 git hooks automation 但换来安全性。生产环境用 server-side hooks 替代 local hooks。
第二条,任何 Coding Agent 必须用 git -c core.fsmonitor=false 启动 git 命令,这是 Manifold 团队在 GitSpawn 文章里直接给出的 mitigation。一行命令、零运行时成本,任何 vendor 在下一个 release 都可以加。
第三条,所有 Coding Agent 必须 sandboxed 跑 git 命令。Agent 跑 git 命令时不能以 developer 身份跑,必须在受限 identity 下跑,即使 sink 被触发,blast radius 受限。
第四条,所有 Coding Agent 的 git subprocess 调用必须进独立审计流。fsmonitor / hook 执行不显示在 Agent context,但必须能在 audit log 里查到。这是事后归因的基础。
第五条,所有 Skill file 安装必须 explicit approve,不能 silent install。Skill file 是 markdown,理论上不能 execute,但如果 vendor 允许 Skill 调用 bash script,必须 explicit approve。
第六条,所有 MCP server 安装必须 sandbox + capability declaration + audit。Geiger 给出的 EXECUTES / HOLDS-SECRETS / BROAD-FILESYSTEM / NETWORK 四个标签是 MCP server 安装的最低审查项。
第七条,所有 Plugin 安装必须 sandbox + explicit approve。Geiger 给出的 read-only scanner 是 visibility 层,但 enforcement 必须有 sandbox。
第八条,所有 Coding Agent 平台必须做 Geiger-style asset inventory 扫描。Geiger 9 月发版的扫描器能扫到本机所有 AI agent 资产 + 风险标签,这种 visibility 是 sink 检测的前提。
第九条,所有 Coding Agent 平台必须做 Manifold-style 持续 vulnerability disclosure。GitSpawn 8 个 findings 跨 7 个 agent,持续披露能推动 vendor patch,任何企业 IT 都应该 follow 这种披露文化。
第十条,所有 Coding Agent 平台必须做 Talos-style permission kernel。permission kernel 在 application 层强制拦截 dangerous commands,即使 sink 被触发,user 也必须在 dangerous operation 前 explicit approve。
六、Coding Agent 工具信任链的系统性整改
把 GitSpawn + Git Hook + Geiger + OneCLI + Talos 五件事合起来,Coding Agent 工具信任链正在从"个别 CVE 修补"过渡到"系统性整改"。早期 Coding Agent 把 trust chain 当成"vendor 自己修 bug"的事;接下来一年内,任何严肃的企业 Coding Agent 部署都会要求系统性 sink 防护,因为 untrusted repo / untrusted skill / untrusted MCP / untrusted plugin 都是 real-world attack surface。
系统性整改的方向是"defense in depth"——不依赖单一防护,在 artifact arrival / skill install / MCP start / git run / command exec 每个阶段都有独立 sink 检查。Geiger 提供 visibility 层(知道有什么 risk),OneCLI 提供 secret isolation 层(不让 Agent 直接持有 credential),Talos 提供 permission kernel 层(application 层 enforce dangerous command approval),Telos 提供 LSM hooks 层(OS 层 enforce syscall),Manifold 提供 vulnerability disclosure 层(推动 vendor 修 bug),Five layers 叠加形成完整 sink 防护。
回到一开始的问题——GitSpawn 和 Git Hook sink 把"Coding Agent 工具信任链的工程失效"这件事第一次系统性摆到桌面上,5 个 sink 类别都需要独立防护,任何一层缺失都构成 enterprise blocker。剩下的是企业 IT 在落地时把十条 checklist 都做对,把 Coding Agent 工具信任链从"vendor 修 bug"升级为"系统性 sink 防护"。这是 2026 年下半年 Agent 安全工程走向成熟的标志,也是企业 AI 真正能承担关键业务的入场券。