一个别人打包给你的项目文件夹，能在你打字之前就执行代码：GitSpawn 波及七个命令行编码 agent，四个至今没修

AI资讯编辑部今天

Manifold Security 于 9 月 1 日披露一组命名为 GitSpawn 的缺陷：7 个命令行 AI 编码 agent 共 8 个问题，复测时仍有 4 个未修复。原理是这些 agent 启动时会在后台跑 git status 或 git diff 收集项目上下文，而 git 的 core.fsmonitor 允许仓库在自己的 .git/config 里指定一个索引刷新时自动运行的辅助程序——于是恶意仓库指定的命令会以开发者的完整权限执行，在沙箱之外，没有审批提示，agent 的权限系统根本看不见。触发时机早到你还没输入任何东西，某些 agent 上甚至在工作区信任提示和登录之前。截至 9 月 1 日复测，Claude Code 的 core.fsmonitor 路径、Cursor、Goose 和 OpenAI Codex 已修，Qwen Code 0.22.3、Grok Build 1.0.13、Hermes 0.21.0 以及 Claude Code ultrareview 的另一条路径仍未修。目前未见在野利用。

出问题的不是模型，是 harness

值得说清楚的是这条路径绕过了什么。agent 的权限系统管的是「模型想做的事」——要不要允许它写文件、跑命令、访问网络。而这里执行命令的不是模型，是 agent 自己的代码为了收集上下文去派生的 git 子进程。`core.fsmonitor` 是 git 有文档的正常功能，读的又是仓库自带的 `.git/config`，整条链路上没有一处需要模型开口，因此审批提示不会弹，沙箱也拦不住。攻击者拿到的是以开发者身份的任意代码执行：SSH 密钥、环境里的云凭证、shell 配置里的令牌、磁盘上的每一个仓库，以及一个长期立足点。

投递方式决定了谁真的有风险

这里有一个容易被忽略的限制，反而是最该记住的一条：正常的 `git clone`、`fetch`、`pull` 传不了这个攻击——这些操作从不传输仓库的 `.git/config`。中毒的仓库必须以文件形式、带着完整的 `.git` 目录到达你手上。也就是说风险面不是「我克隆了一个陌生仓库」，而是压缩包、共享盘、同步目录和 U 盘——正好是外包交付、同事移交项目、甲方发来一份代码审查时最常用的几种方式。习惯上大家对「别人发来的 zip」的警惕，远低于对陌生 GitHub 链接的警惕。

现在该做什么

三条现成的检查：查一下当前仓库有没有被塞设置，`git config --get core.fsmonitor`；不想逐个查就全局关掉，`git config --global core.fsmonitor false`；打开任何外部交付的目录之前，先看 `.git/config` 里的 `core.fsmonitor`、`core.hooksPath` 和 filter 相关配置——或者干脆删掉 `.git` 目录再打开。厂商侧的修法很简单，在后台收集上下文时把配置显式净化掉，例如 `git -c core.fsmonitor=false status`。Manifold 给的时间线里，Claude Code 的 `core.fsmonitor` 路径 6 月 26 日报告、2.1.196 修复；Cursor（7 月 8 日）、Goose（7 月 13 日，1.44.0 修复，CVE-2026-72718）和 Codex（7 月 20 日，OpenAI 另发了三个 CVE）也已处理。仍开着的是 Qwen Code、Grok Build、Hermes（CVE-2026-71963），以及 Claude Code `ultrareview` 里滥用另一个配置键的问题——7 月 15 日报告，被当作内部工单的重复项关掉，9 月 1 日在 2.1.252 上复测仍然可触发，研究者刻意没有公开那个键名。好消息只有一条：截至 9 月 2 日，没有任何一方报告在野利用，CISA 的已知被利用漏洞目录里也查不到这些编号。这类问题的窗口通常在披露之后才真正打开，现在动手成本最低。

via: Manifold Security 技术披露、The Hacker News 报道、Cybersecurity News 报道