插件锁定提交仍可能装入恶意代码

把 AI 编程插件固定到一个审核过的 Git commit，通常被当作供应链安全的底线。Plugin4Shell 揭示的却是：即使安装界面显示可信版本，实际落到磁盘上的代码也可能已经被替换。

按原文描述，问题出在 Claude Code、OpenAI Codex、GitHub Copilot 和 Gemini CLI 的插件安装环节。它绕过的不是模型判断，而是「审核了什么，就安装什么」这条信任链。对程序员来说，这比识别可疑提示词更靠近开发环境本身。

固定了 SHA，为什么还能装进攻击者的代码

正常流程是：市场或安全团队审核某个 Git commit，记录它的 SHA，编程代理再获取对应代码。这个设计成立的前提，是安装结果确实对应那个提交。

受影响的代理在 Git checkout 时请求了固定 SHA，却没有验证检出后的工作区是否与它一致。攻击者利用 Git 引用名称的歧义，创建一个名字恰好等于可信提交 SHA 的分支，也就是一个 40 位十六进制字符串，再把它设为默认分支。

在原文描述的条件下，Git 可能把这个字符串解析成分支，而不是预期的 commit。于是，代理安装了攻击者控制的代码，仍然报告可信版本安装成功。

把 SHA 传给 Git，只完成了请求，没有完成验证。

AIR Security 的研究人员 Or Nevo、Dor Granat 和 Niv Hoffman 在 2026 年 5 月发现问题，并对上述四款工具构建了可工作的利用程序，次月向厂商披露。这里有实际利用作为支撑，但原文没有提供完整命令、Git 版本和解析条件，不能据此断言所有使用 SHA 的 checkout 都会遭遇同样的问题。

为什么只装审核过的插件也会中招

攻击路径不要求用户临时安装来路不明的东西。

攻击者可以先发布一个正常插件，通过市场审核，等它被采用后再替换代码。部分编程代理会自动更新已安装插件，用户不需要再次点击，也不需要误操作，恶意代码就可能进入环境。

审核解决的是某一时刻的代码可信度；安装校验负责把这份可信度延续到用户机器上。后一个环节失效，前面的审核就无法保证最终执行内容。

影响范围还取决于插件能接触什么。原文指出，代理插件、skills 和扩展会使用开发者的权限，可能接触源码、密钥、云环境、生产系统、内部服务和企业数据。对攻击者而言，价值不只是一份项目文件，而是这名开发者所在环境的访问能力。

这也解释了为什么插件市场无法集中修好它：缺失的验证发生在代理客户端内部，各厂商必须修复自己的安装流程。

哪些工具有补丁，哪些还没有

原文列出的修复状态如下，这些是原文报告的状态，并非本文独立核验的实时结果：

• Claude Code 已在 2.1.179 修复，原文建议升级到 2.1.179+。
• OpenAI Codex 已在 0.146.0 修复，原文建议升级到 0.146.0+。
• GitHub Copilot 已收到报告，但原文称 Microsoft 尚未发布修复。
• 原文称 Google 弃用了 Gemini CLI，并引导用户使用 Antigravity，没有为该问题提供补丁。

停止维护不会清除开发者机器上的旧安装。原文还明确表示，Copilot 和 Gemini CLI 没有能够恢复 SHA 固定保证的配置选项。

作者把 Plugin4Shell 与同年 9 月更早出现的 GitSpawn 放在一起讨论：后者通过恶意 .git/config 执行代码，涉及 Claude Code、Codex、Cursor 及另外四款代理；在 9 月 1 日复测时，仍有四家厂商未修复。

两者的共同点，是模型外围的代码获取与执行环节出了问题。市场、审核和版本固定都已经存在，但这些措施没有形成完整的验证链。

我的判断

这篇最有价值的提醒，是把「经过审核」和「实际执行审核过的内容」分开看。前者是流程记录，后者需要客户端强制保证。只在插件清单里看到一个 SHA，不足以证明供应链已经闭环。

不过，原文把它称为 AI agent 生态「第一个真正的供应链漏洞」，这是 AIR 的定性。文章没有系统比较此前的相关事件，不宜直接把这个称号当成已经确认的行业结论。

攻击影响也有环境前提。插件能否触达生产系统、云资源和企业数据，要看开发者实际持有的权限；原文没有给出真实受害规模、密钥泄露数量或各工具的默认权限对照。可工作的利用证明风险成立，不等于证明所有安装都已被攻击。

与单纯增加市场审核相比，安装结果校验更直接地对应这次缺陷；隔离环境和收紧权限则用于限制失守后的损失。两者解决的问题不同。至于「还会出现更多同类漏洞」，目前是作者基于两起事件的判断，没有对照数据支持发生频率。

能拿来做什么

• 如果团队使用 Claude Code 或 Codex，先核对实际运行版本，按原文给出的修复门槛升级到 2.1.179+ 和 0.146.0+，同时覆盖个人电脑与共享开发环境。
• 盘点各代理已安装的插件及自动更新行为，把来源、固定提交和客户端版本放在同一份记录里，避免只检查插件是否经过审核。
• 对原文所列尚无补丁的工具，检查运行环境中的密钥和生产访问权限，减少插件被替换后能够直接触达的资源；Gemini CLI 的存量安装应纳入迁移处理。
• 如果正在维护团队内部的插件安装器，把「请求指定提交」与「验证实际检出结果」作为两个独立步骤检查，不能只凭安装命令成功退出就判定版本可信。