2026 年 9 月 17 日，安全研究团队 AIR（Air Security research lab）披露了名为 Plugin4Shell 的高危漏洞。该漏洞影响了 Anthropic 的 Claude Code、OpenAI 的 Codex、Microsoft 的 GitHub Copilot 以及 Google 的 Gemini CLI 四大主流 AI 编程智能体，波及以百万计的智能体实例。
表面上看，这是一起由 Git 分支命名解析歧义引发的实现失误；本质上，它是 AI 智能体生态首个分发层供应链漏洞。过去的智能体安全研究多集中于模型本身或提示词注入，而 Plugin4Shell 直接攻击了智能体底层的插件市场分发机制，彻底击穿了下游流程依赖的安全基石。
漏洞机理：Git 歧义如何瓦解 SHA 固定
主流编程智能体在安装市场插件时，普遍采用 SHA 固定（SHA pinning，即把插件版本死死锁定在某一次经过安全审阅的代码提交哈希串上，拒绝运行未经审核的新代码）作为核心防线。各智能体在安装时均遵循类似流程：先执行 git clone 拉取仓库，再执行 git checkout <pinned-sha> 切换版本，却从不校验当前工作区是否真正落在了该哈希对应的提交上。这一疏漏为攻击者留出了两条利用路径。
第一条路径覆盖了 Claude Code、Codex 与 GitHub Copilot。Git 的底层解析规则规定：当一个名称既是合法引用（如分支名）又是对象 ID（如提交哈希）时，Git 会优先选择引用，仅向终端输出一行 refname is ambiguous 的警告。攻击者控制插件仓库后，可以创建一个名称恰好为 40 位十六进制哈希的分支，并将其设为仓库的默认分支。当智能体执行常规克隆时，该分支被下载为本地同名分支，随后的 git checkout <sha> 便直接解析到了攻击者构造的恶意分支上。此路径依赖两个前提：一是分支命名协议允许 40 位十六进制字符串（Git 自带的 git check-ref-format 工具与部分托管平台均允许）；二是该分支必须是默认分支，否则非默认分支仅作为远程跟踪分支被拉取，检出时会自动退回提交哈希。
第二条路径针对 Gemini CLI。Gemini CLI 采用 --ref 参数固定版本，安装拆分为三步：git clone --depth 1、git fetch origin <sha> 以及 git checkout FETCH_HEAD。虽然 fetch 命令准确拉取了目标提交并写入本地文件，但如果仓库的默认分支名称本身就叫 FETCH_HEAD，随后的检出指令将优先匹配名为 FETCH_HEAD 的恶意分支，而实际取回的安全提交则被静默丢弃。
零点击扩散：后台自动更新沦为代码执行通道
Plugin4Shell 的破坏力不仅体现在安装时刻，更在于其具备零点击（zero-click，无需受害者进行任何交互或点击确认即可触发）的远程代码执行（RCE）能力。相同的检出逻辑会在插件后台自动更新时重新运行，而在 Claude Code 与 Codex 中，后台自动更新默认处于开启状态。
当市场将固定哈希切换为一个新的提交时，更新机制随即触发。攻击者无需诱导用户安装新插件，只要恶意逻辑被推送到已经处于信任列表中的插件上，恶意代码就能直接抵达受害者机器。
攻击者的完整利用链分为五个步骤：
- 植入（Plant）：攻击者发布一个完全良性的插件，固定在合规提交上并通过市场安全审阅。
- 采用（Adoption）：用户在智能体中安装该插件，智能体将其锁定在审阅通过的提交上。
- 版本更新（Version bump）：攻击者提交合规的版本更新，市场重新固定到新的良性提交哈希。
- 割袍（Rug-pull）：攻击者在仓库中建立一个以该新哈希命名的默认分支并注入恶意载荷，原提交内容完全保持不变。
- 自动更新到 RCE（Auto-update to RCE）：市场哈希变动触发智能体后台静默更新，Git 解析偏向恶意分支并执行代码，全程无提示、无交互。
在实际场景中，攻击者既可以通过提交良性插件逐步转变为恶意插件，也可以利用供应链缺陷劫持合法作者维护的旧插件仓库，强行将恶意版本推送到所有存量设备。
攻击生命周期剖析
| 阶段 | 核心问题 | 留下的硬伤 |
|---|---|---|
| 分发与审阅 | 市场仅审阅特定提交哈希，缺乏对仓库元数据与分支命名的校验机制 | 信任链止步于市场数据库，未能将审核结论与客户端实际检出强绑定 |
| 客户端安装 | 智能体在 git checkout 之后未比对当前工作区解析后的 HEAD 对象 | 默认信任 Git 检出返回值，忽略了引用同名导致的歧义警告 |
| 后台生命周期 | 自动更新机制在无隔离沙箱与无交互提示的状态下直接拉取并执行代码 | 扩大了供应链攻击面，使既有信任资产随时可被反向武器化 |
厂商响应与修复现状
安全团队 AIR 于 2026 年 5 月完成了针对四大智能体的概念验证（PoC），并在 2026 年 6 月通过协同披露机制向各厂商通报了缺陷。
各厂商的处置进度与现状如下：
- Anthropic：于 2026 年 6 月 17 日确认修复，在 Claude Code 2.1.179 版本中补齐了校验逻辑。
- OpenAI：于 2026 年 8 月 12 日完成验证，在 Codex 0.146.0 版本中修复了分支歧义绕过问题。
- Google：于 2026 年 8 月 4 日确认不对 Gemini CLI 发布补丁，原因是该工具已被废弃，官方建议用户迁移到 Antigravity（该产品不包含可被绕过的市场插件 SHA 固定逻辑）。
- Microsoft：同类缺陷已通报给 GitHub Copilot 团队，但截至披露当日仍未发布对应修复补丁，相关客户端用户仍处于未修补状态。
创作者与开发者加固自查方案
对于使用 AI 编程智能体的开发者与团队，单纯依赖插件市场的安全承诺无法彻底规避风险。AIR 给出的底层修复断言逻辑非常直接：在执行检出后，必须在智能体内部直接校验当前解析出的真实哈希，一旦不匹配立即中止执行。
在脚本与自建工作流中，可采用如下命令进行严格校验：
test "$(git rev-parse HEAD)" = "<pinned-sha>" || abort
这一校验必须运行在智能体客户端内部，且必须比对解析后的 HEAD 指针，而非比对传入的引用字符。
此外，代码托管平台的策略差异直接影响漏洞的成立条件。GitHub 在平台层禁止创建 40 位十六进制格式的分支名，天然阻断了第一类利用路径；但 Bitbucket 以及各类企业自建 Git 服务器均允许此类分支名，而这些自建平台均在 Anthropic 等厂商的官方市场支持名单中。开发者若在自建 Git 环境下分发或加载插件，必须在服务端限制分支命名规则，禁止推送与哈希冲突的分支名称。
综合判断与误读澄清
Plugin4Shell 带来的核心判断在于：这不是单纯的开发者安全意识淡薄问题，而是 AI 工具链在集成传统软件基础设施时的语义断层。
当下存在一个常见误读，即认为“只要团队严格遵守安全规范，只从官方市场安装经过多轮人工审阅并固定了 SHA 的插件，就能免受供应链攻击”。Plugin4Shell 打破了这种假设。在受影响的环境中，安全团队越是严格执行审阅并锁定提交哈希，越容易因信任该机制而开启自动更新。攻击者正是利用了审阅流程与 Git 底层解析之间的脱节，在不动原始安全提交的前提下，将恶意代码精准投递给规范操作的用户。
未解决的问题
尽管主流厂商已陆续在客户端追加 HEAD 哈希比对逻辑，但智能体插件生态的信任边界划分仍未解决。目前插件市场无法在服务端强制保障客户端检出的精确性，而各个托管平台（如 GitHub、Bitbucket 与自建 Git）的分支命名规范与对象解析标准短期内无法统一。当智能体被赋予越来越高的系统执行权限，如何在不牺牲自动化更新体验的前提下，构建出跨越网络层、市场层与本地 Git 工具链的端到端不可篡改验证体系，依然是整个生态面临的工程难题。
引用来源
- AIR Security research lab. Plugin4Shell: Zero-click RCE across AI coding agents. 2026-09-17. https://www.air.security/blog-posts/plugin4shell
- Hacker News. Discussion on Plugin4Shell zero-click RCE. 2026-09-17. https://news.ycombinator.com/item?id=49745809
- AIR Security research lab. Research Blog Index. 2026-09-17. https://www.air.security/blog
- Simon Willison. Self-generated prompt injections in compaction summaries. 2026-09-17. https://simonwillison.net/2026/Sep/17/compaction-summaries/
- Simon Willison. OpenAI agents attacked RubyGems back in May. 2026-09-12. https://simonwillison.net/2026/Sep/12/openai-agents-rubygems/
- AIR Security research lab. MCPJacking: Hijacking official Model Context Protocol registries. 2026-08-27. https://www.air.security/blog-posts/mcpjacking
