2026 年 9 月 3 日,Manifold Security 在 Hacker News 发布《GitSpawn: Flaw Lets Untrusted Repos Run Code in Claude Code, Codex, Cursor, Grok》,5 分上首页讨论——一篇工程级漏洞披露,标题点出了所有主流 Coding Agent 的同一类问题。文章披露了 8 个 findings
2026 年 9 月 3 日,Manifold Security 在 Hacker News 发布《GitSpawn: Flaw Lets Untrusted Repos Run Code in Claude Code, Codex, Cursor, Grok》,5 分上首页讨论——一篇工程级漏洞披露,标题点出了所有主流 Coding Agent 的同一类问题。文章披露了 8 个 findings,跨 7 个 agent,其中 4 个在发表时仍然 unpatched。同月 1 天,SenteLabs 在 HN 发布《A Proxy between LLMs and MCP servers with policy the model cannot reach》,3 分首页关注,给出了一个针对性解法——把 policy 从 model 可访问的位置搬出去,放到 deterministic proxy,甚至计划用 Lean 证明助手写 policy + Rego 执行。这两件事合起来,把 Coding Agent 安全工程当前最致命的一个系统性盲点摆到了桌面上——所有主流 Agent 的 git 工具信任链都建立在"git 命令本身无害"的假设上,而这个假设是错的;同时业界也已经在生产可用的解法,但目前采用率几乎为零。
## 一、GitSpawn 漏洞到底是怎么来的
Manifold 团队的研究起点是一个非常朴素的问题——CLI AI Agent 启动时到底在做什么?他们打开几个主流产品的实现观察,发现共同行为:Agent 启动时会主动收集项目 context,而大部分收集是通过 git 命令完成的——可能是 git status、git diff、git log,可能是其他几个变体,有些在启动时调用,有些在会话开始后调用。
当这些命令在项目目录里执行时,git 会做一件隐性操作——refresh index。index refresh 是 git 的核心机制,为了处理大仓库,git 提供 `core.fsmonitor` 这个性能配置,允许它不去逐个检查磁盘文件,而是问一个 helper program 什么变了,在 index refresh 时运行这个 helper。这个机制是文档化的、git 本意行为、Linux 内核和开源生态都在用。问题在于 git 是从仓库自己的 `.git/config` 读这个设置的。所以一个仓库可以在 `.git/config` 里写:
```
fsmonitor =
```
然后任何触发 index refresh 的 git 命令都会跑这个 ``。
Coding Agent 的 context-gathering 调用正是触发 index refresh 的命令。Agent 在启动时跑 `git status` / `git diff`,git 读 `.git/config`,发现 `fsmonitor` 设置,触发 helper 程序,程序以开发者身份在 sandbox 外执行。没有 approval 提示、没有 UI 提示、permission model 完全没看到这个调用。攻击者拿到的是任意代码执行,直接拿到 SSH keys、环境变量里的 cloud 凭证、shell config 里的 tokens、磁盘上所有 repo,以及机器本身的立足点。
更糟的是 `core.fsmonitor` 不是 git 唯一一种同类的"会跑命令"的设置,类似的还有 `core.sshCommand`、`core.gitProxy`、`core.editor`、`core.pager` 等。Manifold 在 7 个 agent 里发现的所有 findings 都属于这一类——git 配置里的命令执行 sink。漏洞的根因不是 git、不是 Agent,而是 Agent 调用 git 时完全没有 strip 仓库自己的配置。
## 二、8 个 findings 的覆盖范围
Manifold 团队披露了 8 个 findings 跨 7 个 agent。具体如下:
**Goose**(Block/Square 维护的开源 Coding Agent)在构建 diff 时跑 `git diff`,把 `-c` flag 直接交给 git,完全不 strip 配置。index refresh 触发,`fsmonitor` 命令在 goose 联系模型之前就执行了。Goose 1.41.0 被报告,1.44.0 修复,被官方打了 severity 7.0。
**Claude Code**(Anthropic 出品,每月 7700 万 npm 下载)在 startup 时通过内部 subprocess 跑 `git status` 等 context-gathering 命令,这个 subprocess 跑在 Claude Code 自己的 sandbox 外面。仓库配置完全不 strip。index refresh 触发,`fsmonitor` 命令在 workspace-trust prompt 接受之前就在 host 上跑了。版本 2.1.193 被报告,2.1.196 修复,被关闭为当天另一份报告的 duplicate。
**Claude Code 还有第二个 finding**——用的是 `core.fsmonitor` 之外的同类 git 设置(ultrareview 路径),review 路径同样不 strip 配置。恶意命令在 startup 时运行,甚至在 workspace-trust prompt 显示或接受之前。15 July 2026 在 2.1.210 被报告,被关闭为内部 ticket 的 duplicate,1 September 确认 2.1.252 仍然 unpatched。
**Hermes**(Nous Research 维护的开源 Coding Agent)在会话目录跑 git 收集 context,把仓库配置原样传过去。index refresh,`fsmonitor` 命令在 host 跑。0.18.2 被报告,1 September 在 0.21.0 仍然确认。六个渠道五次接触,私有 GHSA advisory 从未被 triage。CVE-2026-71963 由 VulnCheck(独立 CVE Numbering Authority,不是 vendor)分配,仍然 unpatched。
**Qwen Code**(阿里出品)在启动时跑 git 收集 context,同样不 strip 仓库配置。index refresh,`fsmonitor` 命令在 host 跑,甚至在用户认证之前就已经执行。0.19.6 被报告给阿里安全响应中心并被接受,1 September 在 0.22.3 仍然确认,仍然 unpatched。
**Grok Build**(xAI 出品)启动时跑 git 收集 context,同样不 strip 仓库配置。index refresh,`fsmonitor` 命令在 host 跑。用户在 Grok Build 打开 repo 并开始打字,恶意命令在第一个按键时就执行,在任何消息发送之前。0.2.93,一份 1 July 的同类报告被关闭为 informative,Manifold 的报告 14 July 关闭为它的 duplicate,1 September 在 1.0.13 仍确认,unpatched。
**OpenAI Codex** 和 **Cursor CLI** 也受影响,Manifold 测试并报告了两个,各自返回"已有另一名研究员提交的报告 duplicate",两个都已 patch。Codex 变体在机制上略有不同但属于同一类。Cursor CLI 在 sandbox 关闭时跑仓库代码——这是另一篇 Manifold 同期文章的细节,但同样归入同一 root cause class。
到发表时(2026-09-01),8 个 findings 里 4 个仍然 unpatched(Claude Code ultrareview、Hermes、Qwen Code、Grok Build),其他 4 个已修复。Manifold 强调每一个 unpatched 的 finding 都是在发表前对当前 release 重新确认过的,并且所有报告都是私下进行的。
## 三、为什么这个漏洞这么致命
GitSpawn 不只是单个 CVE 这么简单,它揭示了 Coding Agent 安全模型的一个根本性设计缺陷——所有主流 agent 的工具信任链都建立在"git 命令本身无害"的假设上,而这个假设是错的。git 在设计时是给人类用的,人类不会随便 clone 一个 hostile repo,也不会随便用别人拷贝过来的目录。但 Coding Agent 的使用模式完全不同——开发者从 GitHub clone、从同事那里拷过来、用 USB 传过来、从云盘同步下来,这些场景下 `.git/config` 可能已经被植入 payload,git 命令的默认行为就是不安全的。
更关键的是,这个漏洞的触发链完全绕过了 Agent 的安全机制。Agent 的 permission model 看到的是 "agent 跑了 git status",这是允许的命令,不是 shell out 的任意命令。Agent 的 approval prompt 看不到这次调用,因为 git 在 agent 自己的 subprocess 里 spawn,不在 agent 的执行栈上。Agent 的 sandbox 隔离也救不了,因为 git 调用故意跑在 sandbox 外面收集 context。换句话说,Agent 安全模型的每一层防御都被精确绕过了——不是某个 layer 有 bug,而是整个模型对 git 调用路径的假设都是错的。
传播路径也让这件事更危险。Manifold 明确写到 delivery 必须是 directory 形式(.git 文件夹已经在里面),不是 clone——clone 不会带 .git/config 内容,因为 git clone 会重写。但现实里 Coding Agent 用户拿到项目的方式大量都是 directory 形式:共享 zip、共享 U 盘、共享 drive、sync 文件夹、consultant 拷给 client。同事之间传项目本来就是 directory 拷贝,GitHub 之外的所有协作形式几乎都是 directory。这意味着 GitSpawn 的攻击面不是抽象的 CVE 风险,而是真实每天发生的协作流程。
## 四、解法已经在生产可用
幸运的是 GitSpawn 不是无解的。SenteLabs 在 9 月 1 日发布的 extensible-mcp 给出了针对性的工程解法,把 policy 从 model 能访问的位置搬出去,放到一个 deterministic proxy 层。
extensible-mcp 的核心设计哲学是 model 不应该加载所有可用工具,policy enforcement 不应该住在任何 model 能访问的东西里。model 可以被它读到的任何输入影响,prompt 不能完全信任,所以这一层把 Agent 的能力限制在 deterministic policy 允许的范围内。同时,每一个加载的工具既增加 context 也增加 attack surface,extensible-mcp 让 model 按需发现 capability,降低 context 开销,限制 model 在任意时刻能访问的内容。
工程实现上,extensible-mcp 是一个 stdio MCP server,任何 MCP client 都可以像连接普通 server 一样连接它。已发布 Apache-2.0 开源,104 个测试通过,example configuration 跑通官方 GitHub MCP server。
更激进的是 SenteLabs 公开的未来路线:human approvals 将密码学可验证,证明真人确实批准了这次具体动作;policy 将用 Lean proof assistant 写成数学证明,翻译到 Rego 执行,这样可以从数学上证明 rule 行为符合规范。这条路线如果走通,Coding Agent 的 policy enforcement 会从"devops 写得对的 YAML"升级到"形式化验证过的数学定理",这是安全工程的下一步形态。
Manifold 自己在文章里也给出了一个直接的 mitigation——任何 Coding Agent 厂商在 background 跑 context-gathering git 命令时,都应该 sanitize git config,例如用 `git -c core.fsmonitor=false status`。这条 mitigation 是直接的、单行命令、零运行时成本,任何 vendor 在下一个 release 都可以加进去。
## 五、企业 Coding Agent 工具信任链的工程化基线
把 GitSpawn 和 extensible-mcp 合起来,会给企业 Coding Agent 工具信任链的工程化划出一条明确基线。
第一条,任何 Coding Agent 必须对外部输入做显式 sanitize。任何从文件系统读取的配置文件(`.git/config`、`.gitignore`、`.npmrc`、`.env`、MCP server config)必须在使用时 strip 已知 dangerous 的字段,而不是原样传给底层工具。GitSpawn 是 `.git/config` 没 strip,类似的漏洞可能在任何其他配置文件上重现,只要开发者没做显式防御。
第二条,任何 Coding Agent 的 subprocess 必须经过 sandbox。任何 context-gathering 行为——git 命令、indexer、linter——都必须在 sandbox 内跑,而不是为性能或便利跑在 sandbox 外。Claude Code 之所以犯这个错,就是因为 context-gathering subprocess 在 sandbox 外面,理由可能是性能或初始化顺序,但这种理由在 RCE 风险面前不值一提。
第三条,任何 Coding Agent 必须有 workspace-trust 之前的零信任边界。GitSpawn 在 workspace-trust prompt 显示或接受之前就执行了 payload,说明 Agent 把"用户打开文件夹"等同于"用户授权 Agent 在这个文件夹里做任何事"。正确的设计应该是:Agent 在 workspace-trust 之前只读 manifest / metadata,任何可能触发 subprocess 执行的 context-gathering 都要等 trust 确认。
第四条,policy 必须从 model 可访问的位置搬出去。extensible-mcp 的设计哲学直接对接 GitSpawn 暴露的问题——如果 policy 在 model 能访问的 prompt / config 里,任何 prompt injection 都可以改写它。policy 必须在 model 之外的 deterministic proxy 层执行,而且最好用形式化方法验证(rule 行为符合规范)。
第五条,任何 Coding Agent 工具调用必须可观测。GitSpawn 的触发链完全不在 Agent 的执行栈上,意味着 Agent 自己都不知道自己跑了这个命令。正确的设计是任何 subprocess spawn 都要进独立审计流,任何 system command 调用都要被 monitor,任何"为什么 Agent 跑了 X 命令"的疑问都能从 audit log 里查到。
第六条,工具信任链必须定期 review。GitSpawn 在 7 个 agent 里复现了同一类问题,说明这不是单个 vendor 的 bug,而是整个 Coding Agent 生态对 git 调用路径的共同假设错误。企业 IT 应该定期对内部使用的 Coding Agent 工具做 trust chain review,而不是依赖 vendor 自己发现问题。
## 六、下一步:Coding Agent 安全工程的标准化
把这件事放到更大的图景里看,Coding Agent 安全工程正在从"被动修补单个 CVE"过渡到"主动设计工具信任链"。GitSpawn 的发现集中体现了当前主流 Agent 工具信任链的系统性缺陷,Manifold 给出了直接 mitigation,senteLabs 给出了架构级解法,接下来一年内这些方法学会被多家 Coding Agent 厂商参考和采纳。
对企业 IT 来说,这件事意味着评估 Coding Agent 平台时必须把工具信任链作为硬指标。任何还在"启动时跑 git 不 strip 配置"的 Agent 都不应该进入企业生产环境,任何不提供 subprocess 审计流的 Agent 都不应该被允许跑敏感代码,任何不把 policy 从 model 拿出去的 Agent 都不应该被允许调外部 API。
回到一开始的问题——GitSpawn 和 extensible-mcp 合起来,把"Coding Agent 工具信任链的工程级失效"这件事第一次用一篇实证披露和一篇针对性解法同时摆到台面上。剩下的就是企业 IT 在落地时把六条工程化基线都做对,把工具信任链从隐式假设变成显式设计。这是 Coding Agent 安全从 demo 时代过渡到生产时代必须过的一关,也是企业 Coding Agent 真正能承担关键业务的入场券。