想象一个很常见的场景。同事把一个项目打包成 .zip 发给你，你解压，打开 AI 编程助手，把文件夹拖进去。你还没来得及敲一个字，也还没点那个「是否信任此工作区」的确认框，程序的后台已经跑起来了。它做的第一件事，是调用 git 去了解自己身处何方。

而如果那个 .zip 里藏了一点手脚，你的电脑此刻可能已经被攻破了。

这是安全团队 Manifold 在 2026 年 9 月 1 日公开的一批发现。他们给它起了个名字叫 GitSpawn，核心结论相当惊悚：包括 Claude Code、Codex、Cursor 在内的多家主流编程 agent，都存在同一个漏洞，只要仓库的 .git/config 里写上一行恶意配置，agent 在启动时自己调用的 git 命令，就会替你执行任意代码。

一切要从「agent 一打开就偷偷跑 git」说起#

Manifold 最初的问题特别简单：一个命令行的 AI agent，启动的那一刻到底在后台做什么？

他们观察了好几个 agent，发现了一件共同的事：agent 会先收集「自己刚被打开的这个项目」的上下文，而收集上下文的手段，很大一部分就是调用 git。有的在启动时调，有的在会话开始后调。要当前分支、要改动列表、要暂存区状态，五花八门。比如这两个再普通不过的命令：

git status --porcelain=2 --branch
git diff --name-only HEAD

这两条命令没有任何异常，你自己也会这么写。问题在于，几乎所有会触碰工作区的 git 命令，都会先刷新一遍索引。而刷新的过程里，藏着一个致命的执行点。

core.fsmonitor：一个「设计如此」的命令执行口子#

core.fsmonitor 是 git 针对大型仓库的一个性能优化：与其逐个检查磁盘上的文件，git 会让一个「助手程序」来告诉它哪些文件变了，并在刷新索引时运行这个程序。这是官方文档里写明的、有意为之的行为。

关键在这里：git 是从仓库自己的 .git/config 里读取这个设置的。于是，一个仓库完全可以自带这样的内容：

[core]
    fsmonitor = <任意命令>

只要 agent 用 git 刷新了索引，无论它跑的是 git status 还是 git diff，这条命令都会被触发。而且 core.fsmonitor 并不是唯一一个这种性质的设置，Manifold 在下文里披露的其中一个案例，走的就是另一个完全不同的配置项。

这里有个细节必须讲清楚，因为它直接决定了攻击的传播方式：git 的克隆操作不会把这个东西带进来。克隆一个恶意 URL 不会中招，fetch、pull 也不会。因为攻击要生效，仓库必须「以文件的形式、连带着自己的 .git 目录」一起到达你的机器。也就是说，真正的载体是那些绕开 git 的传输方式：一个共享的 .zip、一个共享网盘、一个同步文件夹、一块 U 盘。同事之间互相传项目、顾问把代码交给客户，走的往往正是这些路。

命令一旦触发，它是以你的身份、你的权限，在你自己的机器上跑的。因为这是 agent 自己 spawn 出的子进程去调用 git，所以它跑在沙箱之外，没有任何审批弹窗，权限模型根本看不到它。

同一个错误，一家接一家#

Manifold 一共发现了 8 处问题，横跨 7 个 agent。在公开时，有 4 处仍未修复。他们给每个 agent 的披露都配了「触发点、触发方式、录像」三件套，并且刻意没有放出可以直接拿来害人的现成仓库。

Claude Code 有两个独立的问题。第一个就是 core.fsmonitor：它在启动时用内部子进程跑 git status，位于沙箱之外，且没有剥离任何仓库配置，恶意命令会在工作区信任提示被接受之前就执行。这个问题在 2.1.193 上确认，2.1.196 已修复。第二个走的是另一个 git 设置，属于同一种「没剥离配置」的模式，claude ultrareview 的审查路径上会触发，同样在信任提示出现之前就执行。Manifold 在 7 月 15 日上报，被标记为内部工单的重复项，到 9 月 1 日的 2.1.252 版本上仍未修复。

Goose 的触发点是 goose review。它构建审查用的 diff 时，只给 git 传了一个 core.quotePath=off，其余配置原样放行，于是索引一刷新，恶意命令就跑了。影响 1.41.0 版本，1.44.0 修复，官方分配了 CVE-2026-72718，自评严重度 7.0。

Qwen Code 在启动时跑 git status，同样不剥离配置。它的触发点格外早，早到用户还没有完成登录认证，恶意命令就已经执行了。7 月 7 日上报给阿里安全应急响应中心并被受理，但到 9 月 1 日的 0.22.3 版本仍未修复。

Grok Build 也在启动时调用 git，恶意命令在用户敲下第一个字符时就被触发，连消息都还没发出去。xAI 早先把一份同类报告以「仅供参考」结案，Manifold 的跟进又被当作重复项关闭，到 9 月 1 日的 1.0.13 版本仍未修复。

Hermes Agent 在会话目录里跑 git status 收集上下文，配置原样放行。Manifold 在 0.18.2 上确认、次日上报，9 月 1 日又在 0.21.0 上复现。他们跨了五个渠道、联系了六次，私密的安全通告始终没有被分派处理。最后是独立的 CVE 编号机构 VulnCheck 给这个漏洞分配了 CVE-2026-71963。至今未修复。

至于 Codex 和 Cursor，Manifold 也确认受影响，但上报后都被标记为「其他研究者已先报告」的重复项，两者目前都已修复。Codex 的变体在机制上略有不同，但属于同一类问题。

这张时间线里还有一个耐人寻味的细节：Manifold 提交的 8 份报告里，有 5 份被认定为「其他人已经独立上报过」的重复项，其中一份甚至和他们在同一天提交。换句话说，这个洞正在被不止一拨人从不同方向独立挖出来，而且修得并不快。

影响范围有多大#

这不是某个小众工具的一时疏忽。按 Manifold 引用的数据，Claude Code 一个月的 npm 下载量就超过 7700 万次。在涉及的五六个项目里，Hermes 有超过 23.7 万颗 GitHub star，Claude Code 14.3 万，Goose 5.4 万，Qwen Code 2.7 万，Grok Build 2.6 万，加在一起接近五十万。这些 agent 的每一次启动，都可能因为一个来路不明的文件夹而变成一次代码执行。

更深一层的模式#

看到这里，你可能会以为这只是 git 配置的一个坑。但 Manifold 点出了更根本的东西：这种「agent 拾起了自己没写过的文件，并默认信任它」的模式，在别处一再重演。

Skills、MCP 服务器、插件，它们和仓库一样，都是以文件的形式到达，都带着自己的配置，都在到达的那一刻被默认信任。artifact 换了一茬又一茬，模式始终没变。这也正是为什么单点修复 core.fsmonitor 远远不够，真正的问题是：agent 在后台自动拾取外部配置时，没有一道统一的、可审计的隔离。

现在能做什么#

如果你只是一个普通开发者，眼下最实用的防线只有一条：当你以文件形式收到一个仓库时，先看一眼它的 .git/config，再交给 agent 打开。任何「指向某个程序的设置」都可能在后台被执行，宁可多花十秒，也别把信任交给一个来路不明的文件夹。

如果你在开发一个 AI 编程 agent，Manifold 给出了很直接的建议：在后台收集上下文的那几步 git 调用上，把 git 配置消毒一遍，比如强制 git -c core.fsmonitor=false status，让外部配置失效。

我的看法#

这起事件里，最让我不安的不是漏洞本身有多精巧，恰恰相反，它几乎算得上「朴素」：没有模型层面的攻击，没有提示注入，只是一个再普通不过的子进程调用，连着一份没人想着要消毒的配置文件。

但正因为朴素，它才危险。因为几乎所有 agent 都走了同一条路，而这条路横跨了「沙箱」和「审批」这两道我们以为存在的防线，在用户意识到之前、在安全提示出现之前、甚至在登录完成之前，就完成了执行。它提醒我们一件事：当我们把越来越多「打开文件夹、开始干活」的动作交给 agent 时，agent 的启动过程本身，已经变成了一个新的攻击面。而且这个攻击面，现有的 EDR 看不见，网关也看不见，因为它们看到的，只是一个熟悉的开发工具在做它平时就会做的事。

GitSpawn 不是终点。随着 agent 越来越普遍地被用来「打开别人发来的东西」，这一类藏在启动路径里的执行口子，恐怕还会被一次又一次地翻出来。我们能做的，是让每一次「数据即将变成命令执行」的边界，都变得可见、可审计，并且默认不信任。

参考来源：Manifold Security《GitSpawn: A Single Flaw Lets Untrusted Repos Run Code in Claude Code, Codex, Cursor, and Grok》（2026 年 9 月 1 日，https://www.manifold.security/blog/ai-coding-agents-git-hijack ）。