GitSpawn:一个 Git 命令就让 untrusted 仓库在 Claude Code / Codex / Cursor / Grok 上跑代码

GitSpawn:一个 Git 命令就让 untrusted 仓库在 Claude Code / Codex / Cursor / Grok 上跑代码

一、Manifold Security 在 2026 年 9 月 1 日公开的 GitSpawn 报告

Manifold Security 在 2026 年 9 月 1 日发布研究报告 "GitSpawn: A Single Flaw Lets Untrusted Repos Run Code in Claude Code, Codex, Cursor, and Grok"——8 个 findings 跨越 7 个 Agent,其中 4 个在发布时仍未修复。

报告核心结论:

"AI coding agents run git commands in the background to gather context, on some agents before you type a prompt, before the workspace-trust prompt, before you have even authenticated. Improper sanitization in this context-gathering mechanism is a widespread security vulnerability across AI coding agent products, each ending in arbitrary code execution."

中文:AI coding agent 在后台跑 git 命令收集 context,某些 Agent 在你打字之前、在 workspace-trust 弹窗之前、甚至在你认证之前就跑了。这个 context-gathering 机制的 sanitization 缺陷是跨多个 Agent 产品的广泛安全漏洞,每个都能导致任意代码执行。

二、GitSpawn 的攻击机制

攻击机制非常简洁:

第一步:用户从外部(USB / 共享目录 / .zip / 协作分享)拿到一个 git 仓库

第二步:用户在 Claude Code / Goose / Grok / Hermes / Qwen / Cursor / Codex 里 `cd` 进这个目录打开

第三步:Agent 启动时自动跑 `git status` / `git diff` / 其他 git 命令"收集 context"

第四步:这些 git 命令在执行前会刷新 git index

第五步:index 刷新会读取仓库 `.git/config` 里的 `core.fsmonitor` 等设置

第六步:`core.fsmonitor` 指向一个外部命令,git 自动执行这个命令

第七步:恶意命令在用户还没看到 workspace-trust 弹窗时就已经跑完

关键观察:这不是传统的 git hook(post-checkout 等),而是 git 的内建配置机制——`core.fsmonitor` 本来是为了大仓库性能优化的合法设置,git 在 index 刷新时自动调用它。Agent 不 strip 这个配置就直接跑 git 命令,等于把自己 host 的 shell 交给了仓库作者。

三、影响范围:7 个 Agent 中的 8 个 findings

Manifold 报告披露的详细时间线:

4 个未修复:Qwen Code、Grok Build、Claude Code ultrareview、Hermes。

四、为什么 GitSpawn 跟之前的 Agent 安全问题不一样

把 GitSpawn 跟之前讨论的事件对比:

跟 Replit Agent 误删生产数据库(topic 5)对比:

- Replit 是 Agent 接到任务 → 自主决策 → 误操作

- GitSpawn 是 Agent 在接任务之前就被攻陷,不依赖 Agent 决策

跟 Anthropic 7-30 事故(topic 33)对比:

- Anthropic 是评估环境配置错误导致 Agent 意外获得网络

- GitSpawn 是 代码本身合法但执行时机错位——git 期望的配置 vs Agent 调用场景的语义冲突

跟 Agent Skill 供应链(topic 39)对比:

- Agent Skill 是用户主动 `npx skills add` 安装

- GitSpawn 是用户只是打开目录,没有主动安装任何东西,Agent 自己的 context-gathering 流程就是攻击向量

最关键的差异:GitSpawn 是零用户交互攻击。用户不需要 approve、accept trust prompt、或输入 prompt。只要打开目录就中招。

五、为什么这个漏洞这么普遍

报告里描述的核心工程问题:

"The vulnerability is not in the model, or in anything new. It is in the ordinary plumbing underneath, the subprocess an agent spawns at session startup to work out where it is. Every agent we looked at in this article had some version of that same flow, unsanitized."

中文:漏洞不在模型里,也不在任何新东西里。它在底层普通 plumbing——Agent 启动时 spawn 来定位自己的子进程。我们看的每个 Agent 都有某种同样的流程,都未 sanitized。

这是 Agent 行业的"common pattern"——所有 CLI Agent 启动时都需要 gather context,默认假设仓库是可信的。一旦打破这个假设(用户在未知来源获得仓库),整个信任链崩塌。

类似的"common pattern"问题在软件行业反复出现:

- npm install 默认执行 package.json 里的 postinstall

- Docker 默认信任镜像

- pip 默认执行 setup.py

AI Agent 的"git status 信任 .git/config"是新一代的 common pattern 漏洞。

六、修复方法:极简单,但厂商修复慢

报告里给出的修复建议:

给 Agent 厂商:Sanitize git config on context-gathering calls——例如 `git -c core.fsmonitor=false status`。

就是加一个 `-c core.fsmonitor=false` flag,完全消除攻击向量。

给收仓库的用户:Inspect `.git/config` before opening——任何 naming-a-program 的设置都可能跑它。

修复方法的极简性和漏洞的严重性,形成了强烈对比。4 个 Agent 厂商到 2026 年 9 月还没修复,反映了 AI Agent 安全响应速度的滞后。

七、为什么 Hermes 的情况最严重

Hermes 的情况值得单独点出来:

"Six contact attempts across five channels, the private GHSA advisory was never triaged."

中文:6 次联系尝试跨 5 个渠道,私有 GHSA advisory 从未被分类处理。

6 次报告,5 个渠道,仍没修复,也没回应。Manifold 最终从独立 CVE Numbering Authority(VulnCheck,不是厂商)拿到了 CVE-2026-71963。

这是 AI Agent 开源项目安全响应的典型问题:没有专门的安全响应团队。Claude Code / Cursor / OpenAI / xAI / Goose 都是大公司,有专门 SRC;Qwen Code 有 Alibaba SRC 但 patch 慢;Hermes / 类似的小项目可能根本没有响应流程。

八、对企业的现实启示

短期(立刻):

- 不要让 Claude Code / Cursor / Codex 等 Agent 打开未确认来源的仓库——同事分享的 zip、邮件附件、GitHub PR fork、Stack Overflow 复制的代码,先在 VM 里检查 `.git/config` 再用 Agent 打开

- 如果必须打开,先用 `git -c core.fsmonitor=false status` 手动跑一下,确认没有异常设置

- 关注企业内是否有人用 Hermes Agent——这是 4 个未 patch Agent 之一,且厂商无响应

中期(3-6 个月):

- 建立"untrusted repo 处理 SOP"——所有外部来源的代码必须经过扫描再进入 Agent 工作流

- 关注 patch 状态——Qwen Code / Grok Build / Claude Code ultrareview / Hermes 这 4 个 Agent 在用前确认是否 patch

- 关注类似 common pattern 漏洞——`core.fsmonitor` 不会是最后一个,Agent 行业普遍存在的"启动时收集 context"流程都有类似风险

长期(1 年+):

- AI Agent 安全的"common pattern"问题会成为系统性问题——npm 已经有 postinstall 漏洞几十年,AI Agent 会有类似"10 年常见漏洞"

- 企业 IT 需要专门的 Agent 安全响应能力——光靠厂商 SRC 不够,企业自己必须有 Agent 漏洞评估流程

- 第三方 Agent 安全审计会成为新行业——Manifold Security 这类公司正在做"Agent runtime monitoring"基础设施,未来会有更多专业公司出现

九、回到题目:GitSpawn 真正改变了什么

GitSpawn 揭示了一个长期被 AI 行业忽视的事实:Agent 安全不只是模型安全,还包括 Agent 调用的所有外部命令的安全。

`git status` 这个看似人畜无害的命令,在 AI Agent 的 context-gathering 流程里,变成了 zero-interaction attack surface。这不是 git 的问题,是 Agent 调用 git 时不 sanitized config 的问题。

类似的"看似无害的命令被 Agent 自动化后变成 attack surface"的例子会越来越多:

- `git status`(本文)

- `npm install`(postinstall)

- `curl | bash`(任意 shell injection)

- `git submodule update`(子模块自动 clone + checkout)

- `git config --get` 或 `--set`(任意 git config 读写)

AI Agent 行业的安全问题不是"模型会不会说错话",而是"Agent 自动调用的命令会不会成为攻击向量"。

2026 年下半年,任何还在用"trust the repo"假设的 Agent,都会被 GitSpawn 这种漏洞打穿。

对企业来说,评估 Agent 安全性时,要看的不只是模型本身,还有 Agent 调用的所有外部命令。这是 Agent 安全的新维度——也是 2027 年 Agent 行业必修的工程课。