用 AI 编程工具打开一个不熟悉的代码仓库，几乎是每个开发者的日常。但 9 月初曝出的这组漏洞告诉你：打开仓库这个动作本身，就可能让你的电脑被远程攻击者接管。
安全公司 Manifold Security 披露了一组代号 GitSpawn 的漏洞：8 个安全缺陷，波及 7 款主流命令行 AI 编程工具，包括 Claude Code、OpenAI Codex、Cursor、GitHub goose 等。截至 9 月 1 日复查，仍有 4 款工具未完全修复。
一、攻击原理：一个”合法”的 Git 配置被利用了
这组漏洞攻击的不是模型本身，而是编程 Agent 和 Git 的交互层。
Git 有一个性能优化特性叫 core.fsmonitor：开发者可以给它指定一个外部命令，让 Git 在检测文件变化时调用它，从而加快 git status、git diff 这类操作。问题在于——Git 允许仓库自己的 .git/config 文件直接定义这个配置。
AI 编程工具启动时会自动执行 git status、git diff 来了解仓库状态，好决定接下来怎么干活。恶意仓库就把 core.fsmonitor 指向一段攻击者控制的命令，Agent 一跑 Git 命令，这段命令就以你的用户权限在后台执行了——绕过 Agent 的沙箱、不弹任何确认框。
更糟的是执行时机：研究者发现，Claude Code 和 Hermes Agent 能在用户点”信任此工作区”之前就执行负载，Qwen Code 能在用户登录认证之前触发，Grok Build 甚至在你敲下第一个键时就发作。你以为的安全确认环节，全被绕过了。
二、攻击要成功，靠的不是 clone 而是”文件传输”
有个细节值得注意：这种攻击不能通过正常的 git clone 传播——clone 不会保留攻击者的仓库配置。真正危险的场景是：
- 从网上下载的压缩包解压后打开；
- 通过共享网盘、同步文件夹（Dropbox、OneDrive、百度网盘等）收到的项目；
- 同事用 U 盘拷给你的代码；
- 客户或外包发来的源码归档文件。
只要项目以”文件形式”到达你手里、同时保留了 .git 目录，攻击者埋好的命令就等着 Agent 打开它。所以越是对外接活、常收外部代码的开发者，风险越高。
三、受影响版本清单，快自查
我把目前公开的受影响与修复状态整理成表（截至 9 月初复查）：
| 工具 | 受影响版本 | 修复状态 |
|—|—|—|
| GitHub goose | 1.44.0 之前 | 已修复（1.44.0+） |
| OpenAI Codex CLI | 0.102.0–0.130.0 | 已修复（0.131.0+） |
| Codex Desktop（macOS/Windows） | 260202.0859–26.513.31313 等 | 已修复 |
| Cursor CLI | 受影响（未公开具体版本） | 已推送修复 |
| Claude Code | fsmonitor 路径 2.1.196 已修 | 另一路径（claude ultrareview）未修复 |
| Hermes Agent | 0.18.2 / 0.21.0 | 未修复 |
| 通义 Qwen Code | 0.19.6 / 0.22.3 | 未修复（报告已受理） |
| Grok Build | 0.2.93 / 1.0.13 | 未修复 |
OpenAI 已为 Codex 发布 CVE-2026-19592 等三份 CVE 公告，明确承认”易受攻击的辅助进程在 Codex 命令沙箱外执行、且无用户批准提示”。GitHub 为 goose 分配了 CVE-2026-72718（CVSS 4.0 基准 7.0），另有 CVE-2026-55607（Claude Code）、CVE-2026-71963（Hermes Agent）在列。
四、现在该怎么做：升级 + 关掉 fsmonitor + 改习惯
修复优先级很明确，三步走：
第一步，升级工具。 Claude Code、Codex、Cursor、goose 用户先把自己用的版本升到最新——这几个官方修复已发布，别停在旧版。
第二步，全局关掉 core.fsmonitor。 执行这条命令，从根上堵住这个攻击面：
git config --global core.fsmonitor false另外建议检查手头项目的 .git/config，看有没有可疑的 core.fsmonitor、core.hooksPath、attr.tree 配置，见到不认识的直接删。
第三步，改掉”收到代码就打开”的习惯。 从压缩包、网盘、U 盘来的项目，先删掉或检查它的 .git 目录再打开；能走 git clone 就别用文件传输。对仍处于未修复状态的工具（Hermes、Qwen Code、Grok Build），在厂商出补丁前，尽量别用它们打开不可信来源的仓库，或在隔离环境里跑。
五、老达点评
这个漏洞真正值得警惕的地方，不是某个工具写崩了，而是暴露了 AI 编程工具一类共通的架构盲区：Agent 把”打开仓库”当成了完全可信的操作，而实际上仓库本身可能是攻击载体。
回头看 9 月初的Claude Code 一次”安全审查”删掉 700GB那件事，那是 AI 自己决策出错；这次 GitSpawn 则是攻击者利用 Agent 的自动化流程反向入侵开发者——一内一外，把 AI 编程的安全问题补全了。我之前写Claude Code 给 auto 模式加了条碰不得的安全红线时就提醒过，Agent 权限越大、自动化程度越高，它和系统底层交互的地方就越值得怀疑。Git 就是那个”没人检查的底层”。
三个判断供参考：
1. “供应链投毒”的下一个目标就是开发者的 Agent。 过去投毒靠恶意依赖包、靠 npm/PyPI 植入，现在攻击者发现更省事的入口：不用骗你装依赖，只要骗你打开一个仓库。对所有让 AI 自动跑 Git 命令的工具，这都不会是最后一个同类漏洞——Manifold 自己就说”受影响工具比公开名单更多”。
2. 沙箱不是保险箱。 这次攻击能绕过沙箱和信任弹窗，说明”Agent 沙箱内执行”的安全模型有天花板：Agent 主动发起的子进程（Git、Shell、构建工具）是沙箱管不到的地带。真正可靠的做法是把不可信代码挡在门外，而不是指望 Agent 内部防御。
3. 接外包、常收外部代码的人，风险等级最高。 如果你经常用 Claude Code、Codex 打开客户发来的项目，请把”先查 .git 再打开”变成肌肉记忆。AI 编程工具的安全实践，我会持续更新在 AI编程工具专题 和 AI智能体与自动化专题；之前整理的Anthropic 官方开发手册解读里关于 Agent 权限边界的部分，现在回头看更有现实意义。工具越能干，越要管住它碰的东西。
