标签： DeepSeek V4 Pro · Qwen3.7 Max · Kimi K3 · GLM 5.3 · Claude Opus 4.6## 事件回顾：一份文件夹就是一份 RCE2026 年 9 月 1 日，Manifold Security 的 Francisco Rosales 公开了一类被他命名为 GitSpawn 的漏洞利用方式。它的攻击载体不是提示词，不是 MCP 服务器，不是某个第三方 Skill，而是一份仓库的 .git/config 文件本身。原理极其朴素：Git 有一个性能开关叫 core.fsmonitor，作用是让 Git 在每次刷新索引（git status、git diff 等命令都会触发）时调用一个外部辅助程序来加速变更检测。这个辅助程序的路径，恰好写在仓库自己的 .git/config 里——也就是说，任何控制仓库的人都可以指定 Git 该调用哪个程序。而 AI 编程 Agent 为了在打开项目时立刻构建上下文，会在用户敲下第一个提示词之前就在后台静默运行 git status、git diff 这样的命令。命令一跑，索引一刷新，仓库控制的 core.fsmonitor 就被 Git 当作合法配置执行——攻击者写在 .git/config 里的任意命令，会以开发者本人的全部用户权限、在 Agent 沙箱之外、被静默执行。不需要提示词，不需要权限弹窗，不需要工作区信任确认。在某些 Agent 上，甚至不需要先登录。披露影响 7 款主流 CLI 编程 Agent（Claude Code、OpenAI Codex、Cursor、Goose、Hermes Agent、Qwen Code、Grok Build），合计 GitHub 星标接近 50 万、Claude Code 仅 npm 包就有 7700 万月下载量。其中 Claude Code 主路径已在 v2.1.196 修复、Goose 在 v1.44.0 修复并获 CVE-2026-72718（CVSS 7.0）、Cursor 与 Codex 已各自打补丁；但截至 9 月 1 日复测，Claude Code 的 claude ultrareview 第二路径、Hermes Agent 0.21.0（VulnCheck 代发 CVE-2026-71963、CVSS 8.8）、Qwen Code 0.22.3、Grok Build 1.0.13 四项仍可被利用。Hermes Agent 维护方甚至对 6 次联系尝试完全未回应。传递向量也同样朴素：git clone 不会从远端同步本地的 .git/config，所以攻击不走 clone 路径。它走的是文件传递——同事通过 Slack 发来的压缩包、共享盘里的"项目交接"目录、U盘交的项目、邮件附件里的 zip——只要 .git 目录完好无损地到达受害者本地，攻击就已经就位。## 深度分析：四个被忽视的范式GitSpawn 与过去半年 SkillCloak、GuardFall、Amazon Q MCP、JadePuffer、Claude Code 隐写术那批"Agent 安全事件"看似同类，但内核完全不同——它揭示的是 Agent 安全的结构性失守，而非某个具体产品的孤立缺陷。### 1. 攻击面从"模型层"下沉到"基础设施层"过去 12 个月，AI Agent 的攻防围绕"提示词注入"“输出审查”“Skill 供应链"展开，攻防双方默认的边界是模型与开发者之间的对话通道。GitSpawn 把这条边界彻底绕开——攻击发生在 Agent 调用 git 这一基础设施命令时，而这条命令的语义 Git 自己负责。Agent 厂商既没有控制 Git 的 core.fsmonitor 行为，也不可能把"调用 git"做成权限弹窗（否则 Agent 就丧失了自动构建上下文的全部能力）。这意味着 Agent 的安全边界需要重画：不是"模型 + Prompt + 输出审查”，而是"模型 + 宿主 OS + 一切 Agent 用作上下文探测的外部程序"。Manifold 给出的修复建议只有一行——git -c core.fsmonitor=false status——但这一行代码需要在每一处背景 git 调用前都加上，遗漏一处就是攻击面。### 2. “打开文件夹 = 执行代码"是信任模型的范式转变工程师的传统心智模型是：clone URL = 可信（远端 .git/config 不会被信任），未 clone 的本地文件夹 = 可读但不可信。GitSpawn 把这条边界抹掉了——本地文件夹不仅可读，Agent 一旦主动去"探测"它，就等同于执行了它。更糟糕的是，Agent 为了追求"打开即用"的体验，正在把这条边界往工程师心智模型相反的方向推：以前你必须 clone 才能让 IDE 索引代码，现在 Agent 直接打开本地文件夹就开始干活。这个体验改进的代价，是"打开陌生文件夹"从"风险可控的本地操作"变成了"等价于运行未签名代码”。Manifold 在博客里写得很直接：“开发者从未运行任何东西。是 Agent 用他们的权限、替他们运行了。“这不是 Agent 厂商能靠产品修复单独解决的问题——它需要整个行业重新划定"信任区”：Agent 打开一个文件夹之前，是否需要像浏览器对待 HTTPS 证书那样，向用户确认该目录的可信级别？### 3. 修补响应曲线揭示了 Agent 厂商的"安全治理成熟度"披露时间表本身就是一张厂商体检报告：- Claude Code：主路径 6/26 报告，7/3 在 v2.1.196 修复，但 claude ultrareview 第二路径 7/15 报告，至 9/1 复测仍未修——同一家厂商两轮披露间隔一个月，说明对核心.fsmonitor 的修复并未覆盖整个命令面。- Goose：7/13 报告，9/1 复测时已修，且拿到了 CVE 编号。- Cursor / Codex：独立研究者也报告了同类问题，修复较快但都属于"被多人重复报告后才被严肃对待”。- Qwen Code：阿里安全响应中心接受报告但未修复——9/1 复测仍可利用。- Hermes Agent：维护方完全沉默 6 次联系，由 VulnCheck 代发 CVE-2026-71963。- Grok Build：xAI 无公开响应，1.0.13 仍可利用。结论：一个用了同一种 Git 行为、有同等文档可查的漏洞，A 家 9 天修完、B 家沉默 1 个月、C 家彻底不响应。这不是技术难度问题，是 Agent 厂商对"安全运营"的投入与承诺差距。### 4. 国产 Coding Agent 的"修补沉默"反而成了 Taotoken 模型的反向卖点Qwen Code 在 GitSpawn 列表中位列未修复名单，这件事对国内开发者社区有两层含义。短期信号：Qwen Code 的安全响应流程需要被严肃拷问。如果阿里安全响应中心已经接受报告但仍未交付修复，说明 Coding Agent 这条产品线在国内大厂内部的优先级，可能仍处于"功能体验 > 安全运营"的阶段。这与 Qwen3.7 Max 在编程榜单上突飞猛进的对外形象形成了内部反差。长期逻辑：Agent 安全事件的反复曝光，正在改变企业的模型采购决策标准。当闭源 Agent 的"安全补丁依赖厂商节奏"成为显性风险时，DeepSeek V4 Pro、GLM 5.3、Kimi K3 这一类权重可本地化、运行路径可审计的国产开源模型，反而获得了"安全可解释性"这一新维度的竞争力——不是性能更强，而是当供应链出事时，企业可以自己看代码、自己打补丁、自己决定升级节奏。这一点对国内信创、金融、政务等强监管行业的 Agent 选型尤为关键。GitSpawn 这类攻击的本质是"代码即配置"，而开源模型对应的"模型权重即代码"恰好是同一种可审计性逻辑的延伸——当 Agent 本身成为高价值资产，能审计比能跑得更快更重要。## 观点预判1. Agent 厂商会在 3-6 个月内集体加入 .git/config 清洗层：参照浏览器对 mixed content 的处理方式，预计 Claude Code 会在 2.2.x 系列中加入 core.fsmonitor=false 的全局默认；Cursor 跟随；Qwen Code 若不修复将被国内信创客户用脚投票。2. "Agent OS"概念会在 GitSpawn 之后被重新定义：单一命令的边界治理（core.fsmonitor=false）只是补丁，真正需要的是 Agent 运行时的 syscall 白名单 + 文件 IO 过滤层。这会催生一个细分品类：Agent 沙箱运行时（如 E2B 类项目的下一代形态），其核心卖点不再是"安全地跑代码"，而是"安全地跑 git"。3. 国产 Coding Agent 的安全运营会进入"军备竞赛"：当阿里 Qwen Code 因为 GitSpawn 沉默而丢掉一批信创客户时，字节豆包、智谱 GLM Coding、DeepSeek-Coder 等会迅速把"已修复 GitSpawn 类攻击"写进产品 PR。这不是技术胜负，是采购合规的胜负。4. "打开陌生文件夹"的信任弹窗会成为 Agent UX 标配：参照 macOS Gatekeeper、Chrome HTTPS 警告，未来 12 个月内 Agent 打开非 clone 来源的本地目录时，会弹出"该目录来源不可信，是否启用受控模式"的统一提示。这条 UX 会成为产品差异化竞争点。## 实操建议### 给开发者（立即执行）1. 打补丁优先级：Claude Code 升到 v2.1.196+，Goose 升到 1.44.0+，Cursor/Codex 升级到最新版；Hermes Agent / Qwen Code / Grok Build 在补丁发布前避免打开非 clone 来源的本地项目。2. 全局禁用 core.fsmonitor：执行 git config --global core.fsmonitor false。注意这是全局开关，对所有仓库生效，对性能影响极小（除非你的仓库超过 10 万文件）。3. 对"文件夹交接"建立最小信任流：收到 zip / 共享盘 / U 盘 / 内部 artifact store 的项目，先 unzip 到临时目录，用 grep -E '^\s*\w+\s*=' .git/config 人工审查可疑配置项，再决定是否让 Agent 打开。4. 启用 GitHub 仓库的 hooks / pre-push 审计：CI 中加一条规则：禁止任何包含 fsmonitor、hooksPath、attr.tree 的 commit 进入主分支。### 给 Agent 厂商 / 平台方（3 个月内）1. 统一约定背景 git 调用：所有后台 git status、git diff 都强制加 git -c core.fsmonitor=false -c core.hooksPath=/dev/null 前缀，不依赖仓库配置。2. 建立"未签名本地目录"信任模式：Agent 第一次打开本地未 clone 的目录，必须强制要求用户在工作区信任弹窗中确认；该确认信息写入会话级白名单，跨 Agent 实例共享。3. 修补响应承诺 SLA 化：参考 CVE 流程，公开承诺从研究者报告到补丁交付的天数上限（如 14 天）。做不到就公开说明原因——沉默是最差的响应。4. 把"可审计性"写进产品 PR：尤其是面向信创 / 金融 / 政务客户的国产 Agent，把"开源 + 权重可下载 + 补丁节奏公开"作为对外宣传的硬指标。### 给采购方 / 安全团队（季度级）1. 建立"Agent 供应链事件响应预案"：参照开源软件 CVE 响应流程，预设值班人、临时禁用清单、回滚路径。GitSpawn 提醒我们：当 Agent 漏洞披露时，企业最缺的不是技术修复流程，而是"哪些 Agent 必须立刻关停"的决策权。2. 优先采购"开源权重 + 私有部署"路径的模型：DeepSeek V4 Pro、GLM 5.3、Kimi K3 这类模型既可以在私有化环境中运行、也可以在 Agent 出事时快速替换或降级，避免被单一闭源 Agent 锁定。3. 构建内部"Agent 风险看板"：追踪每个团队在用的 Coding Agent、当前版本、最新已知漏洞、补丁状态。每周自动同步 GitHub Advisory、Check Point Research、CSA 简报里的相关条目。4. 设置"Agent 提权门槛"：禁止 Agent 默认拥有提交、push、Docker exec、kubectl exec、SSH 等高权限操作，所有这类调用必须经由显式工作流触发，且每次触发都要进入审计日志。GitSpawn 的全部危害，本质上是把 core.fsmonitor 这条命令的权限等同于"开发者本人"——而开发者本人的权限边界，在绝大多数团队里都远远超过"读这个仓库"。GitSpawn 不是 Agent 安全故事的终点，而是 Agent 时代信任基础设施尚未建立这一现实的开端。当 Agent 能跑 git、能跑 npm、能跑 docker、能跑 kubectl，GitSpawn 揭示的问题只会以指数级规模重演——下一轮被武器化的不会是 core.fsmonitor，而是 core.hooksPath、core.sshCommand、或者某种 npm postinstall 的等价物。真正能保护 Agent 生态的不是某一个补丁，而是"代码即配置、配置即代码"这条认知本身——Agent 安全本质上是供应链安全，供应链安全本质上是开源治理，而开源治理的前提，是让每一个参与方都有能力自己看代码、自己打补丁、自己承担责任。
扫一扫
206
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
