同事发来的项目压缩包，打开前先看一眼 Git 配置

原创

tcode
tcode

字节脉搏实验室

2026年10月16日 10:32
北京

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

把同事发来的项目压缩包解压，拖给AI编码助手说一句“帮我看看这个仓库”——按安全研究机构Manifold Security在2026年9月1日至2日披露的结论，恶意命令可能在你点任何确认按钮、甚至在“信任此工作区”的提示弹出来之前，就已经在这台机器上跑完了。这组漏洞被命名为GitSpawn，共8个，横跨7款主流命令行AI编码助手：Claude Code、OpenAI Codex、Cursor、Hermes Agent、Qwen Code、Grok Build和goose。

10月15日，国内一位研究者把这组漏洞的原理、影响面和交付方式边界整理成完整分析并配上了本地复现过程，环境是Windows加Git 2.55。这篇文章的价值不在于复述结论，而在于它指出了一件事：问题不在模型里，也不在任何新东西里，而在一条所有人都在用、却几乎没人检查的普通管道。

一条链，六个环节，每一步都“看起来正常”

攻击链是这样的。第一步，攻击者创建一个仓库，在仓库的Git配置里写入一个会被当作命令执行的值。第二步，把这个仓库以文件形式交付出去——压缩包、共享网盘、同步文件夹、U盘，任选一种。第三步，接收方解压，把项目文件夹交给AI编码助手。第四步，助手在会话启动时后台自动运行git status这类命令，用来搞清楚自己在哪个分支、哪些文件被改过。第五步，这些调用没有剥离仓库自带的配置，Git在刷新索引时读到了攻击者写的那一行。第六步，命令以当前登录用户的权限、在助手的沙箱之外、且不经过任何审批地执行。

六个环节里没有任何一步看起来像攻击：仓库看着正常，运行git status看着正常，助手的行为看着也正常。危险藏在“配置”这个不起眼的角落——它不是代码，不会被当成代码审查，也不出现在文件列表的第一屏。

具体到配置项，公开分析点出的第一个是core.fsmonitor。它本身是一个完全合法、有文档的性能特性，用来指定一个外部程序告诉Git哪些文件变了。但它的值就是一条Git会在刷新索引时执行的命令，而Git是从仓库自己的配置里读这个值的。分析里还验证了第二类入口，即内容过滤器，它在执行git add时对文件内容做清洗，清洗动作同样是外部命令。研究人员在本地用无害形式做了验证：写入的命令能够读到当前环境变量并留下痕迹，也就是说入口本身是成立的，把命令换成别的形态，效果随之改变。

为什么自动化的助手会踩中这个入口

这条链能成立，靠的是助手为了给出有用回答而必须做的动作。要回答“这个仓库在改什么”，助手得先知道当前分支、暂存区状态和文件差异，于是它在会话一开始就调用状态查询和差异比对这类命令，而不是等你提出具体问题。这些调用是助手派生的子进程，不是沙箱里的受控接口，因此继承的是当前用户的权限和当前目录的配置；仓库自带的配置如果没有被显式覆盖，就会跟着生效。披露方的总结是：漏洞不在模型里，而在助手启动时调用的那些普通命令里。对使用者来说，这意味着“信任此工作区”这个提示的语义比看上去弱——它管的是你允许不允许助手读取工作区，而命令在提示出现之前就已经执行过了。

走 clone 拿到的仓库不会触发

这组漏洞有一个容易被忽略的边界条件：走标准的git clone拿到的仓库，不会带上源仓库本地的Git配置，因此这条路不触发。研究者专门做了一组对照实验来验证这一点，结论是这类攻击只对“以文件形式交付”的仓库有效。

这条边界决定了排查的重点，而不是放松的理由。开发者日常里最常见的信息交换方式恰恰是“传目录”：同事打包发来的项目、顾问交付的代码、客户发来的样例、从网盘下载的项目压缩包。而“解压之后丢给助手看一眼”正在变成一种默认动作。触发概率高的不是陌生人发来的可疑文件，而是熟人链路上的普通文件。

修复状态要按“路径”看，不能按“产品”看

公开信息里最容易被误读的是修复进度。8个漏洞对应7款产品，评分从7.0到8.8不等，但已修复、部分修复和未修复是三种状态，不能只看“某产品发了新版本”就放心。

公开披露时的情况是：Codex CLI（CVE-2026-19592，7.3）已在新版本中修复；goose（CVE-2026-72718，7.0）已修复；Claude Code（CVE-2026-55607，8.8）属于部分修复——它的一条触发路径已经修复，但研究者复测时另一条路径仍然存在；Hermes Agent（CVE-2026-71963，7.5）在披露时未修复。8个漏洞在披露时有4个仍未修复。这些工具的合计月下载量超过7700万次，这意味着“没修的那一半”分布在相当数量的开发机上。

评分也不完全反映实际危害。因为命令执行发生在“信任工作区”这道防线生效之前、且完全绕开沙箱，实际风险往往高于评分给出的印象：在部分产品上，命令在提示被接受之前就执行；在其中一款工具上，甚至在用户完成认证之前。

收到压缩包之后，按顺序做这三件事

第一步，先别让助手碰它。解压之后，用文本编辑器或文件管理器打开项目根目录下的Git配置目录，重点看四个位置：指定文件变更检测程序的配置项、代码钩子目录、内容过滤器的定义，以及属性文件配置。这几项的正常值要么是空，要么指向确实安装在本机的程序；如果值里出现了完整的命令行、管道符、下载动作或指向陌生地址的内容，就不要在这个目录里启动任何Git相关工具，记下来源与时间，把目录整体隔离。

第二步，把自己的工具版本对一遍。已修复的产品要确认版本号达到修复版本以上；被列为部分修复或不完全修复的产品，不要只看版本号，因为同类入口可能有多个。公开分析提到的问题模式是“助手运行Git时不清洗仓库配置”，因此最稳妥的做法是：对来源不明的目录，先禁用助手对工作区的自动读取，再用命令行单独检查配置。

第三步，把“文件形式交付”当成一个需要流程的环节。在团队内部约定：收到的压缩包先在隔离环境解压检查，或者干脆改为从受控仓库克隆。这一步的收益不限于这组漏洞——任何以“解压即执行”为前提的投递方式，都会受同一条规则保护。

披露与修复之间有一段空窗

把这组漏洞的时间线排开，会看到另一件值得注意的事：研究机构在9月初披露，国内完整分析出现在10月15日，中间隔了约六周。对装机量以千万计的开发工具来说，这段时间里最麻烦的不是公开披露本身，而是“已修复”与“未修复”混在同一个产品名下的状态——团队盘点时按产品名圈范围，就会把没修的那部分漏掉。更实用的口径是按“工具加路径”盘：同一款助手的哪条触发路径已经修好、哪条还没有，分别对应到哪个版本号上。

一句话核验和一个边界

如果在你的机器上只能记一句话，就记这三问：这个项目是怎么到我这里的？解压目录的Git配置里有没有会被当成命令执行的项？我的编码助手版本覆盖到已修复的那条路径了吗？三问里任何一问答不上来，就先别让助手打开这个目录。

边界要说清楚。本文的事实来自安全研究机构的公开披露和国内研究者的公开分析与本地复现，没有企业或个人被确认因此失陷的公开案例；这组漏洞的危害取决于攻击者放入的命令内容，公开材料演示的是无害形式。受影响产品的修复版本与状态以厂商后续公告为准，披露之后仍可能有新的修复版本发布。另外，“关掉某个配置项”不是解决方案：用户侧能做的是检查来源、隔离目录、对齐版本，而不是假设自己记得住每一个可疑的配置名。

来源

FreeBuf《一个恶意 .gitconfig，如何让 7 个 AI 编码助手在打开仓库的瞬间执行你的命令》，2026-10-15 12:11:24（国内原创分析，含 Windows + Git 2.55 本地复现过程）。https://www.freebuf.com/articles/ai-security/506604.html

Manifold Security 对 GitSpawn 的公开披露，2026-09-01 至 2026-09-02（由上述分析文章引用；本次未直接取到该机构原始页面）。

FreeBuf 同批分析《AI编码助手配置投毒攻击链：从.cursorrules到MCP工具劫持的纵深分析》，2026-10-15 11:29:57（同类攻击面背景）。https://www.freebuf.com/articles/ai-security/506596.html

新建一个吹水群，主要针对转行和失业的兄弟姐妹们吐槽，广告和技术交流可以去大群联系我即可，该群主要提供情绪价值，互助跳出抑郁情绪和环境。