AI 快讯 | Plugin4Shell 零点击 RCE：四款编码代理共用，Anthropic 与 OpenAI 已修、Copilot 与 Gemini CLI 未修

文档资源
, , , ,
1

:fire: 一句话核心：安全公司 AIR 于 9 月 17 日披露 Plugin4Shell——Claude Code、OpenAI Codex、GitHub Copilot、Gemini CLI 四款编码代理共有的一枚零点击远程代码执行（RCE）漏洞。攻击者只要控制某个已被信任的插件仓库，把默认分支指向恶意版本，代理的插件自动更新就会在用户毫无操作的情况下装上恶意代码：原因是代理检出了市场钉扎（pinning）的那个 commit，却从未校验它是否真的落在那里。修复状态并不一致——Anthropic 与 OpenAI 已修，GitHub Copilot 未见修复，Gemini CLI 已被弃用、Google 明确不修。

AIR Security 研究报告《Plugin4Shell – Zero Click RCE Vulnerability found in top 4 most popular coding agents》（2026-09-17）
AIR Security 研究报告《Plugin4Shell – Zero Click RCE Vulnerability found in top 4 most popular coding agents》（2026-09-17）1568×882 206 KB

:pushpin: 背景脉络：这是同一个研究系列的第三篇

AIR 把这条线索做成了三篇连续研究，前两篇解释了「技能/插件供应链」为什么脆：

  • 第一篇（The Story of Skills）：他们自建了一个恶意技能，看着它「病毒式传播」，并称控制了超过 26,000 个 agent——结论是「把代码放进一个人们信任的市场，不是难的部分」。
  • 第二篇（SkillJacking）：他们称无需植入任何东西——925 个已在使用的技能被从原维护者手中劫持，影响 134,000 个 agent，方式是接管技能背后的代码仓库。
  • 第三篇（Plugin4Shell）：行业对此类「rug-pull」的答案是 SHA 钉扎（审阅某个 commit、把它钉住，相信此后运行的就是它）。Plugin4Shell 讲的正是这条防线失效。

（上述三组规模数字均为研究方自述，本轮未见第三方复核。）

:key: 机制：钉扎为什么没生效

  • 攻击链：攻击者发布一个真正无害的插件并钉扎在 commit aaa...aaa → 通过审阅、被用户安装 → 攻击者接管该仓库、把默认分支指向恶意版本 → 同名 ref/分支与 commit 冲突时 git 优先取 ref，检出结果解析到了分支 → 恶意代码被执行。
  • 为什么是「零点击」：插件自动更新默认开启（Claude Code 与 Codex 均如此），所以当上游那个被钉扎的 commit 被替换，已安装的插件会被直接换成恶意版本——没有安装步骤、没有确认提示、没有可察觉的动作。研究员原话是：暴露面不限于「随手装插件的人」，只要你装过一个来自你信任市场、并且按安全模型那样被审阅和钉扎的插件，就处在风险中。
  • 市场侧修不了：钉扎是在 agent 内部解析的，因此市场无法可靠地约束本地 git 客户端如何解析 pin——必须由客户端侧修复。这也是 Google 选择弃用 Gemini CLI 而不是打补丁的原因。
  • 两种变体：Claude Code、Codex、GitHub Copilot 共享同一变体（与 git 如何处理分支名有关）；Gemini CLI 是另一条机制（fetch 与 checkout 钉扎提交的方式），但后果相同。

:bar_chart: 厂商修复状态与时间线（研究方披露）

代理 状态 版本 / 时间
Claude Code 已修复 2.1.179（Anthropic 于 2026-06-17 确认修复）
OpenAI Codex 已修复 0.146.0（2026-08-12 验证修复）
GitHub Copilot 未提供修复 研究方称已披露给微软，暂未出货修复；GitHub 对媒体表示该攻击不影响 GitHub，研究方认为其缓解措施不足以阻断
Gemini CLI 不会修复 Google 于 2026-08-04 确认不再修复（该 CLI 已被弃用），建议迁移到 Antigravity

研究方的完整时间线（AIR 报告 Timeline 节原文）是：2026 年 5 月由 AIR 安全研究实验室发现，并对四款代理均做出可用 PoC；6 月按协同披露流程通报四家厂商；6 月 17 日 Anthropic 确认 Claude Code 2.1.179 已修复；8 月 4 日 Google 确认不会出货修复（Gemini CLI 已弃用）；8 月 12 日验证 Codex 0.146.0 已修复。

也就是说：6 月到 8 月厂商已经修完了该修的，9 月新的是研究方把整件事公开。 修复状态的差异不是「时间不够」，而是各家自己的选择。

另一个容易混淆的点值得写清：这套攻击的「分支名变体」只在允许 40 位十六进制分支名的 git 托管方上生效——GitHub 直接拒绝这种分支名，而 Bitbucket 与自建 git 服务器允许（Anthropic 官方文档把这两类后端列为受支持的市场配置）。所以「GitHub 拒绝该分支名」与「GitHub Copilot 未出货修复」是两件不同的事：前者是托管方的行为，后者是客户端厂商的修复状态。

:money_bag: 成本与影响面

本次不涉及定价。可量化的成本有三块：暴露面（装有市场插件的编码代理数量）、客户端升级的运维成本（唯一完整缓解手段是把 agent 升到修复版本）、以及在无补丁情况下的处置成本（Copilot 用户需要在客户端修复前自行控制自动更新与插件来源）。研究方的判断是：更新 agent 是唯一完整的缓解措施。

:balance_scale: 辩证评估

  • 价值：它把「AI 插件/技能供应链」从概念讨论推进到了有编号、有机制图、有修复状态与时间线的具体漏洞，并给出了明确可执行的缓解路径。对任何在生产环境跑编码代理的团队，这是一条可以直接落地检查项的安全通告。
  • 反向视角：其一，三组规模数字（26,000 / 925 / 134,000）是研究方自述，没有第三方复核，引用时应标注；其二，厂商与研究方在 GitHub Copilot 上存在分歧——GitHub 称不受影响，AIR 认为其缓解不足，读者应同时看到两种口径；其三，这枚漏洞的根因在客户端（本地 git 解析），市场侧无法兜底，意味着生态里「谁负责」的边界仍未理清；其四，与 9 月初披露的 GitSpawn（走 .git/config）是两起不同的漏洞，不应合并叙述；其五，修复依赖用户主动升级——已知未修复或不再维护的客户端会长期留在暴露状态。
  • 一个更大的信号：同一家研究机构连续三篇证明「技能/插件 = 可执行代码 + 可被接管的分发链」。这与技能生态正在走向「有 ID、有版本、跨平台引用」的制品化趋势叠加，意味着技能治理（来源、审阅、版本、自动更新策略）会很快从可选变成必选。

一条身份说明（引用其数字时应知悉）：AIR 是商业安全厂商，本报告的页面带有面向企业的产品推广，并自述其 Air Marketplace 与 Air Filter 用户不受该漏洞影响。这不影响漏洞机制层面的证据（多家独立安全媒体已交叉报道机制与修复状态），但引用其规模数字时，应把厂商立场一并纳入考量——这也是本文明明标注「研究方自述」的原因。

:white_check_mark: 已知 vs 待验证

已交叉印证（研究方披露 + 多家独立安全媒体报道）：Plugin4Shell 的机制（SHA 钉扎绕过 + 自动更新触发）、影响范围（四款编码代理）、各厂商修复状态与版本号、以及时间线（6 月上报、8 月两次厂商确认、9 月 17 日披露）。

待验证：26,000 / 925 / 134,000 三组规模数字（研究方自述，无第三方复核）；GitHub 的「不受影响」主张与研究方的反驳之间的孰是孰非；GitHub Copilot 修复的具体时间表（研究方未提供）。

:compass: 给读者的建议

  • 立刻可做：把 Claude Code 升到 2.1.179 或更高、Codex 升到 0.146.0 或更高——这是唯一完整的缓解。
  • Copilot 用户：在官方修复前，收紧插件来源、关闭不必要的插件自动更新，并关注微软的修复公告。
  • Gemini CLI 用户：该客户端已被弃用且不会修复，建议按官方指引迁移到 Antigravity（研究方称该攻击不触达）。
  • 所有跑编码代理的团队：建立插件/技能清单（装了哪些、来自哪个仓库、钉扎在哪个版本），并把它当作可执行代码来做审阅与变更记录。
  • 安全与平台团队：把「自动更新 + 第三方插件市场」视为一条高风险链路，在流程上补上版本冻结与更新审批。

:link: 来源

研究原文

独立来源