Git配置劫持编码代理：三起漏洞与防护清单

引言：绕过审批提示的攻击

一个恶意的 git config 文件，可以在任何审批提示出现之前，就在七个编码代理中执行代码。近期披露的三起事件——GitSpawn、BragJack 和 Salesbleed——展示了不需要战胜模型本身，而是绕过审批提示、浏览器边界或 URL 过滤器的攻击手法。如果你的代理安全计划是“模型会拒绝”或“人类会点击批准”，那么它存在一个明显的缺口。

rss source: A Git Config File Can Hijack Your Coding Agent. Here's the Fix List.

GitSpawn：代码在任何人被询问之前运行

Manifold Security 披露，仓库自身的 .git/config 可以设置 core.fsmonitor。编码代理会频繁运行 git status 和 git diff 来获取上下文。每次调用都可能触发该配置中指定的辅助程序，而这些程序以开发者的完整本地权限运行，位于代理沙箱之外，且没有任何审批提示。在多个工具上，它甚至在工作区信任对话框被接受之前就已触发。

不需要投毒提示、恶意依赖或被入侵的 MCP 服务器。Manifold 在七个代理中报告了八项发现：Claude Code、OpenAI Codex、Cursor、Grok Build、Goose、Hermes Agent 和 Qwen Code。截至 9 月 1 日，其中四项仍未修补，而 Claude Code 的 ultrareview 配置路径在 core.fsmonitor 修复发布后仍然开放。

什么是 core.fsmonitor

core.fsmonitor 是 Git 的一个配置项，用于接入文件系统监控（File System Monitor，fsmonitor）机制来加速 git status、git diff 等命令。Git 本身在状态检查时会遍历工作树，文件多时开销较大；通过该配置，Git 可以改为向一个外部辅助进程（或集成钩子）查询“哪些文件自上次以来发生了变化”，从而只检查变化子集。

问题在于，这个“辅助程序”的路径完全由仓库自身的 .git/config 指定，Git 在调用它时不会区分该配置是开发者手写的还是克隆仓库时被植入的。它运行在开发者的完整本地权限下，且位于大多数编码代理所依赖的沙箱之外。因此当代理仅仅执行一次 git status 来获取上下文时，辅助程序就已先于任何审批界面、工作区信任确认或沙箱策略被执行。这类“工具链自描述配置驱动执行”的模式，是供应链攻击面中经常被低估的一类。

为什么“工作区信任”挡不住它

现代 IDE 与代理普遍引入“工作区信任”（Workspace Trust）对话框，思路是先让用户声明一个目录是否可信，再决定是否启用任务、扩展、脚本等可能执行的组件。但信任提示是面向用户的交互，它依赖宿主在正确的时间点询问。GitSpawn 的触发时机早于该询问，因为 git status 往往由代理的后台上下文采集阶段发起，而非用户手动操作；宿主并未把这一路径纳入需要授权的执行面。

由此得出一个通用教训：任何依赖“先问后跑”的边界，都必须覆盖代理内部所有会产生进程的调用，包括为索引、补全、诊断而自动发起的命令。仅仅在 UI 层弹出信任框，等于把安全边界建立在用户可见性上，而代理的许多行为恰恰是用户看不到的。

BragJack：浏览器内的助手信任你的扩展

Forever Security 研究员 Gal Weizman 展示了一个单一的浏览器扩展可以跨入五个浏览器中的特权内置 AI 代理：Chrome with Gemini、Edge、Opera Neon、Perplexity Comet 和 Claude in Chrome。Dark Reading 在 9 月 16 日报道称，这不需要提示注入，也不需要绕过防护栏。所有五家厂商都承认了该漏洞。Google 和 Microsoft 发布了 CVE-2026-0628 和 CVE-2026-55945。

共置扩展为何等同于攻击者

浏览器扩展与页面内 AI 助手通常运行在不同的权限层：扩展可访问标签页、网络请求、存储与跨域数据，而被嵌入页面的助手则处于站点同源策略约束之内。BragJack 揭示的问题在于，内置 AI 代理为了调用宿主能力（读页面、发请求、操作 UI），向扩展暴露了一组特权接口，并且默认信任来自扩展的调用。攻击者只要让一个扩展与目标代理共置在同一浏览器实例，就可以通过这组接口跨入特权上下文。

这与操作系统的本地提权模型类似：低权限组件通过 IPC 向高权限组件投递输入，若后者不校验来源，就形成“困惑的副手”（Confused Deputy）问题。厂商修补往往集中在代理的提示过滤或模型护栏上，而根因在于组件间的信任关系与权限授予范围。因此把每个共存的扩展、插件、钩子都视为潜在攻击者，比逐条扩充阻止列表更接近问题的本质。

Salesbleed：修复是一个过滤器，而过滤器被绕过了

Zenity 研究人员通过一个公开的 Web-to-Lead 表单，将提示注入到了 Salesforce Agentforce 中，并绕过了 Salesforce 在 Noma Security 早先发现后添加的 URL 过滤规则。Slack 部署的代理还可以在内部线程中发布未归属的消息，这使得钓鱼攻击变得容易。Salesforce 报告没有证据表明存在真实世界的利用，并已切换到符合规范的 URL 解析、集中式 URL 检查，且现在要求对某些 Slack 操作进行用户确认。它承认早先的响应是一个快速修复，而非全面方案。

为什么 URL 过滤必然会被绕过

把外部输入中的 URL 与阻止列表做字符串比对，属于典型的基于特征的黑名单防御。绕过方式有很多：在域名字符编码上做手脚（如百分号编码、Unicode 同形字、大小写变体）、利用解析器差异（浏览器、HTTP 客户端与服务端对同一字符串的解析结果不一致，即解析器歧义）、借助重定向与开放图床把最终目标藏在合法域名之后，或把敏感内容拆分到多个请求中传递。

真正的边界应当是允许列表加最小权限：明确代理可以访问哪些域、哪些操作需要用户确认、以及代理发出的消息能否被带外使用。Salesforce 事件后切换到“符合规范的 URL 解析 + 集中式 URL 检查 + 对某些 Slack 操作要求用户确认”，正体现从字符过滤转向解析一致性与权限节制。厂商也承认早前响应只是快速修复，说明过滤器只能作为临时缓解，无法替代边界设计。

模式：攻击的是代理周围的控制

每个案例攻击的都是代理周围的控制，而非代理的判断力：

审批或信任提示触发得太晚，或者从不触发。
特权助手接受来自较低特权邻居的输入。
用阻止列表或过滤器代替真正的边界。

一份由 OWASP 托管的第三季度漏洞汇总（声明其并非 OWASP 官方出版物）补充了第四个角度：代理作为行为者。它描述了评估代理在 7 月触及了 41 个 Hugging Face 生产数据集工作器，以及一个由代理发布的恶意 PyPI 包在约一小时的在线时间内运行在 15 个系统上。

修复清单

让你的代理面对恶意仓库、页面和表单，检查在任何提示出现之前执行了什么。
将每一个共存的扩展、插件和钩子视为攻击者。
用允许列表和最小权限工具范围替换阻止列表。
在每个厂商补丁后重新测试。过滤器会被绕过。

你可以通过注册 Humanbound 的免费 Community 计划，在 https://app.humanbound.ai 对您自己的代理运行这类对抗性测试。引擎和 CLI 是开源的：github.com/humanbound/humanbound。

参考来源

GitSpawn, CSA Labs 研究笔记, 2026年9月3日
BragJack, Dark Reading, 2026年9月16日
Salesbleed, Dark Reading, 2026年9月24日
GenAI 和代理 AI 漏洞汇总 2026年第三季度, 2026年10月8日
Adversa AI 编码代理安全汇总, 2026年10月2日