四款 AI 编码代理把插件钉在了提交哈希上，却没人核对真正装进来的是什么

主流的 AI 编码代理安装插件的方式如出一辙：市场发布插件，代理把它钉（pin）在某个具体的 git 提交上，而这个「钉住」被当作安全保证。提交哈希是内容寻址的，无法被悄悄改写。在各类软件包生态中，钉住版本正是应对供应链风险的标准答案——也正因如此，编码代理的插件市场一直被当成已经解决的问题。

如今 AIR Security 的研究人员公开的报告显示，四款主流产品——Anthropic 的 Claude Code、OpenAI 的 Codex、GitHub Copilot 和谷歌的 Gemini CLI——都向 git 索取了被钉住的提交，却从未确认返回的就是那个提交。他们把这个漏洞称为 Plugin4Shell。四款中有两款已经发布修复，另外两款尚未发布，其中一款今后也不会修。

钉住被核对了，结果没有

缺陷不在哈希本身，而在「索取一个提交」与「随后验证工作区里实际是什么」之间的空隙。OpenAI 自己的修复说明把底层行为讲得很直白：git「可能把请求的提交 SHA 解释成分支名」，从而让代理最终拿到「与它所钉住的并不相同的提交」。如果插件仓库托管在允许模糊引用名的地方，仓库所有者就能让这个「钉住」解析到市场从未审核过的代码。

AIR 对这个缺陷的概括更短：

代理检出了市场所钉住的那个确切提交，却从不验证自己真的落在了那里。

严重性来自紧接着运行的东西。编码代理握着开发者的 shell、凭据和源码树。随插件进来的代码，也就进到了这一切之中。

后台自动更新才是它成为「零点击」的原因

安装插件是开发者只做一次的决定，但保持插件为最新则是代理持续在做的决定——因为插件默认会在后台自动更新。这是整份研究中最该让防守方警惕的部分，研究人员也说得很直接：

这不只是安装时的缺陷，正因如此它才是零点击的：同样的 git 检出会在后台自动更新时再次执行。

也就是说，一个在三月经过审查并安装的插件，可能在九月被替换，而开发者什么都不必做。没有弹窗，没有安装步骤，也没有任何一刻需要由人来批准这份新代码。

修复进展

AIR 表示，该问题于五月发现，六月向四家厂商全部报告。截至 9 月 18 日尚未分配 CVE 编号，四家厂商也都没有发布安全公告——这意味着安全团队平时盯着的那些渠道，根本不会告诉他们这件事。研究人员称目前没有发现野外利用的证据。

GitHub 说自己不受影响。那是关于托管的说法，不是关于代理的说法

GitHub 的立场是：由于它限制了平台上仓库可以使用的名称，这个问题触及不到它的用户。

GitHub 不允许用户创建形似提交 SHA 的分支名或标签名……因此所报告的漏洞无法在 GitHub 上被利用。

在其适用范围内这是准确的，也正是托管在 GitHub 上的插件不受这一变种影响的原因。研究人员的异议在于：这把修复放错了层。Copilot 和其他代理同样可以从别处托管的市场安装插件——Bitbucket、自建 git 服务器、企业内部镜像——而这些地方都不会继承 GitHub 的命名规则。用 AIR 的话说，「修复必须随代理一起发布，更新是唯一彻底的缓解措施」。

这场分歧的意义超出这一个漏洞。平台侧的限制保护的是该平台的用户；而代理是决定执行什么的那个部件，也是每一次安装、每一个来源都必然经过的唯一部件。微软称财富 500 强中近 90% 使用 Copilot，其企业吸引力的一部分正来自对内部市场的支持——而这恰恰是 GitHub 命名规则覆盖不到的配置。

现在该做什么

把 Claude Code 升级到 2.1.179 或更高，把 Codex 升级到 0.146.0 或更高；对这两款而言，这就是完整的修复。Copilot 没有补丁，因此可用的手段是管理性的：限制开发者可以安装插件的市场来源，并在微软发布客户端改动之前优先使用托管在 GitHub 上的市场。Gemini CLI 完全不会得到修复，这让迁移变成一项安全决策，而不是路线图决策。

更大的问题在于，围绕编码代理生长出来的插件层，跑得比审核它的机制更快。AIR 此前针对同一生态的研究发现，一个通过了安全审核、随后更换了外部拉取资源的伪造技能，在被下架前已触达约 26,000 个代理。Plugin4Shell 是同一种失败发生在更低一层：审核确实做了，钉住确实记录了，而记录下来的意图与机器实际运行的东西之间，留着一道空隙。

Sources: AIR Security: Plugin4Shell · Help Net Security · The Register · The Hacker News