Plugin4Shell AI Agent 漏洞绕过可信插件，两个编程工具仍未修复

尽管用户遵循了安装经审核插件的预期流程，Plugin4Shell 仍攻破了四款 AI 编程代理的一项核心防护措施。安全公司 AIR 表示，该漏洞影响 Claude Code、OpenAI Codex、GitHub Copilot 和 Gemini CLI。其研究人员已针对这四款产品演示了可行的远程代码执行攻击。

Anthropic 和 OpenAI 在收到 AIR 的披露后发布了修复措施。AIR 表示，截至其于 2026 年 9 月 17 日公布研究结果时，GitHub Copilot 尚未发布相应补丁。该公司还称，Google 不会修复受影响的 Gemini CLI 行为，而是建议用户转向 Antigravity。

这种不一致的响应正是问题的核心。插件市场承诺，审核与提交固定机制可以保护开发者免受获批后代码变更的影响。据报道，Plugin4Shell 在无需粗心安装、可疑批准或再次点击的情况下打破了这一承诺。

Plugin4Shell 将可信更新转化为远程代码执行

这次攻击针对的是插件分发流程，而不是语言模型决定如何回应提示词的过程。

AI 编程代理越来越多地支持插件、技能、扩展及其他附加组件。这些软件包能够自定义工作流程、连接服务，或在开发环境中运行代码。它们通常继承代理访问文件、执行 shell 命令以及与已认证系统交互的能力。

这种访问权限意味着，代理插件更接近本地应用程序，而不是被动的文本提示。如果恶意代码进入插件目录，它就可以在运行该代理的开发者所获权限范围内执行操作。

AIR 表示，Plugin4Shell 通过绕过 SHA 固定机制实现攻击。SHA 是一种通常用于标识特定 Git 提交的加密标识符。将插件固定到该标识符，理论上应使其安装的代码保持不变，即使其代码仓库后来发生变化。

根据 Plugin4Shell research，受影响的代理请求了被固定的提交，但未验证实际检出的提交。控制上游代码仓库的攻击者可以利用 Git 的名称解析行为，替换为不同的代码。

插件市场记录仍可显示预期的提交标识符，代理也可能报告安装成功。然而，工作目录中的文件实际上将来自攻击者控制的分支，而非经审核的提交。

AIR 描述了两条实际可行的攻击路径。攻击者可以发布一个合法插件，积累用户采用，然后在后续更新中将代码仓库变为恶意状态。或者，攻击者可以接管为现有插件提供支持的代码仓库。

第二条路径之所以重要，是因为它将责任从个别插件作者身上转移开来。一个插件可以最初是合法项目，并通过所有审核；只有在开发者和安全团队已经信任它之后，其代码仓库才变得具有恶意。

AIR 表示，研究人员于 2026 年 5 月发现该问题，并于 6 月向四家供应商披露。该公司于 9 月 17 日公布技术说明。Help Net Security 于次日报道了这一发现。

两家机构引用的公开证据均未显示，Plugin4Shell 在披露前曾被用于攻击真实受害者。已演示的影响来自 AIR 的概念验证测试，而非已有记录的犯罪活动。

这一区别限制了对即时失陷情况的判断，但并不减轻该控制机制失效的重要性。一次成功攻击将通过组织此前已审核和批准的组件执行代码。

该问题也延续了 AIR 早先对插件分发的研究。该公司表示，一项测试技能在被移除前已触达超过 26,000 个代理。另有研究据称发现了 925 个被劫持的技能，影响 134,000 个代理。

这些数据来自 AIR，尚未在 Plugin4Shell 披露中得到独立复现。它们说明了研究人员更广泛的观点：获得分发渠道和攻陷上游代码仓库是现实的攻击阶段，而不只是理论前提。

Plugin4Shell AI Agent 漏洞如何绕过 SHA 固定机制

Plugin4Shell 能够奏效，是因为每个受影响的代理都信任被请求的 Git 引用，而没有验证最终检出的提交。

据报道，Claude Code、Codex 和 GitHub Copilot 共享同一种变体。它们的插件安装程序会克隆代码仓库，并将被固定的 40 字符提交标识符传递给 git checkout。

在许多托管配置下，Git 允许使用看起来像提交标识符的分支名称。当一个名称既可标识分支也可标识对象时，Git 可能将其解析为引用，同时输出歧义警告。

控制插件代码仓库的攻击者可以创建一个名称与被固定提交完全相同的分支。随后，攻击者会将该分支设为代码仓库的默认分支，并使其指向恶意代码。

初始克隆会下载攻击者的默认分支。后续检出操作可能将看似提交标识符的内容解析为该本地分支。代理随后便会加载或执行与插件市场审核版本不同的文件。

该技术并非在所有托管服务上都以相同方式奏效。根据 GitHub 的分支名称限制，GitHub 会阻止看起来像完整 Git 对象标识符的分支和标签名称。

不过，AIR 表示 Bitbucket 和自托管 Git 服务可以接受此类名称。一些代理市场正式支持托管在 GitHub 之外的代码仓库，因此更广泛的配置仍处于暴露状态。

据报道，Gemini CLI 通过另一条路径实现了相同结果。其安装程序获取被固定的提交，随后针对 FETCH_HEAD 执行检出；FETCH_HEAD 是一个通常指向已获取内容的 Git 引用。

AIR 发现，代码仓库可以将 FETCH_HEAD 用作默认分支名称。检出操作随后可能解析到该分支，而不是包含已获取提交的特殊文件。

两种变体都依赖于缺失的最终比较。完成检出后，代理需要解析 HEAD，并验证它是否等于插件市场固定的 SHA。

这项检查很小，但其执行位置至关重要。插件市场无法确认客户端最终放入本地工作树的内容。验证必须在执行克隆和检出的代理内部进行。

“零点击”这一标签源于后台更新。AIR 表示，Claude Code 和 Codex 默认会自动更新已安装插件。因此，恶意替换内容可能在插件市场更改其固定值后到达，而无需再次作出安装决定。

受害者无需寻找新的恶意插件。攻击者会针对机器上已存在的插件，并等待代理的更新流程执行。

远程代码执行，或 RCE，意味着攻击者控制的指令会在目标系统上运行。其实际影响取决于受影响代理可获得的账户、环境、沙箱、凭据和网络访问权限。

AIR 将潜在影响描述为等同于运行该工具的员工所拥有的访问权限。这是一种最坏情形的描述，并非对每种安装环境的通用衡量。

严格隔离的代理可能只会暴露一个临时工作区。若本地安装的代理拥有云端凭据、源代码仓库、签名密钥或生产环境访问权限，其潜在影响范围则会大得多。

这种差异性意味着，仅盘点版本并不足够。安全团队还需要了解每个代理的运行位置、加载哪些插件，以及该执行边界内有哪些可用凭据。

插件审核按设计运行，但安装的代码仍然发生了变化

核心冲突在于不可变审核的承诺，与客户端 Git 解析的现实之间。

软件供应链控制通常将批准与执行分离。审核人员评估一个已知版本，记录其摘要，并只允许系统安装该版本。

该模型假设摘要能够标识最终执行的文件。据报道，Plugin4Shell 保留了可见的固定值，却切断了这一固定值与最终工作树之间的联系。

这比仅仅警告用户防范未知扩展更严重。研究人员表示，即使插件来自可信市场、通过审核并保持固定，攻击依然有效。

因此，仅围绕插件市场信誉构建的安全指导将遗漏这一脆弱环节。如果本地代理能在检出期间被欺骗，攻击者就不需要攻陷插件市场数据库。

同样的限制也适用于内部插件目录。企业可能审核每个软件包，并镜像已批准的元数据；但如果员工客户端不验证解析后的提交，这些控制措施仍不完整。

AIR 称 Plugin4Shell 是 AI 代理生态系统中的首个供应链漏洞。这一措辞是该公司的定性，应当谨慎看待。

AI 开发工具此前已经面临代码仓库投毒、提示词注入、恶意配置文件和扩展相关漏洞。Plugin4Shell 在某种意义上范围更窄，因为它聚焦于被固定的代理附加组件及其更新路径。

不过，该机制暴露出一种不同的信任失效。它攻击的是经过审核的代理功能从代码仓库到开发者机器的传递过程。

近期研究表明，这并非孤立的压力点。Wiz 在 2026 年 7 月测试六款 AI 编程助手后披露了 GhostApproval。该问题利用符号链接访问预期工作区边界之外的文件。

GhostApproval findings 影响了来自 Amazon、Anthropic、Augment、Cursor、Google 和 Windsurf 的产品。供应商回应各不相同，部分发布了修复措施，至少有一家对其威胁模型作出了争议性决定。

GhostApproval 和 Plugin4Shell 使用不同的技术原语。前者利用通过符号链接进行的路径解析；后者据报道利用了插件安装和更新期间的 Git 引用解析。

将二者联系起来的模式，是用户可见决策与系统实际操作之间的落差。一个路径看似本地，却解析至其他位置；一个固定值看似不可变，却解析至不同代码。

单靠权限提示无法修复这种不匹配。当界面显示的是可信名称，而底层操作实际指向其他目标时，用户无法作出知情决策。

Anthropic 曾公开将文件系统与网络隔离描述为 Claude Code 的互补保障。其沙箱模型旨在阻止被注入的进程访问敏感文件或未经授权的网络目的地。

沙箱可以降低恶意插件代码的影响，但不能替代准确的软件包验证，尤其是在插件运行于相同限制之外，或获得更广泛权限时。

因此，企业需要两道独立边界。安装过程必须验证实际安装的是经审核代码；运行时环境则必须限制该代码在执行后能够访问的资源。

任一层发生失效，都不应自动演变为工作站或云账户失陷。Plugin4Shell 之所以重要，是因为许多 agent 部署仍将可变扩展与高价值本地凭据结合在一起。

四款编程 Agent 产生了四种不同的安全结果

此次披露揭示了采用相似插件工作流的工具之间存在割裂的补丁流程。

AIR 表示，Anthropic 已在 2.1.179 版本中修复 Claude Code 漏洞。该公司记录的日期显示，Anthropic 于 2026 年 6 月 17 日确认完成修复。

据 AIR 称，OpenAI 已在 0.146.0 版本中修复受影响的 Codex 行为。研究时间线称，该公司于 8 月 12 日确认该版本已修复此问题。

这些产品的用户不应假定自动更新已成功完成。受管工作站、离线环境、软件包锁定和内部发布系统，都可能导致旧版本仍被安装。

组织应查询实际终端，并将其版本与已修复版本进行比对。如果部署流程不会替换正在运行的 agent 进程，也应重启长期运行的会话。

GitHub Copilot 面临的是另一类问题。AIR 称，Microsoft 收到了同一份漏洞报告，但在研究公开时尚未发布修复。

GitHub 最近扩展了对 agent 操作的集中化控制。其 9 月 9 日公告称，管理员可通过受管 agent 权限阻止、允许或要求审批 shell 命令、文件操作和网络域名。

这些控制措施可以缩小后果范围，但并不能证明 Plugin4Shell 已获修复。未修复的安装程序与严格的运行时策略，针对的是攻击的不同阶段。

因此，Copilot 管理员应寻求产品专属的公告、修复版本或厂商确认。在此之前，组织可以暂停 marketplace 插件更新，或将 agent 限制为由其控制的已批准仓库。

Gemini CLI 的状态最为复杂。AIR 表示，Google 于 8 月 4 日确认不会修复受影响的工作流，并建议迁移至 Antigravity。

Google 已开始将个人用户从 Gemini CLI 转移到 Antigravity CLI。6 月的一则公告称，Gemini CLI 已停止为个人账户提供请求服务，而企业和 API 密钥使用仍然可用。

不过，Google 早先的迁移通知也称，开源 Gemini CLI 项目将继续为企业客户接收模型更新、错误修复和安全修复。

这份公开表述与“每个 Gemini CLI 安装都将无限期保持易受攻击”这一说法并不完全一致。它为管理员留下了一个重要的验证缺口。

Google 9 月的更新日志显示，在面向消费者的迁移之后，Gemini CLI 仍持续发布版本。日志还列出了与该特定 checkout 缺陷无关的安全加固措施。这些活动并不能证明 Plugin4Shell 已获修复。

谨慎的结论应更为有限。AIR 报告称，在漏洞披露时 Gemini CLI 尚无 Plugin4Shell 补丁，并建议使用 Antigravity。Google 仍在为企业用途维护 Gemini CLI 的部分功能，但没有任何引用的发行说明指出已修复这一特定问题。

企业用户不应从一般性的维护表述中推断安全性。他们需要直接确认，其所用版本会在安装或更新扩展后验证最终 checkout 的 commit。

他们也不应将迁移视为简单改名。若未经过审查便转移配置，将 skills、hooks、MCP servers 和凭据迁入新的 agent，可能会复现其他风险。

AIR 称，Antigravity 不采用遭 Plugin4Shell 利用的插件 SHA 固定机制。根据研究人员的分析，这意味着该特定攻击路径不适用。

这并不意味着 Antigravity 对恶意插件、提示注入、不安全工具或未来的供应链失效免疫。安全团队在迁移后仍应保持同样的隔离和最小权限要求。

这四种回应揭示了超出此漏洞本身的治理问题。相似功能可以在多个 agent 中发布，却没有共享的披露规范、统一的严重性评分或同步的修复机制。

开发者必须追踪各自独立的更新日志和厂商声明。随后，企业管理员还必须将这些不一致的记录转化为一套可执行的安全态势。

开发团队应立即作出的调整

首要任务是停止存在风险的插件更新、核实 agent 版本，并减少每个编程 agent 可获取的凭据。

对于 Claude Code，组织应将所有安装升级至 2.1.179 或更高版本。对于 Codex，AIR 指出 0.146.0 是已修复版本。

团队应通过终端资产清单而非问卷调查来验证版本。开发者可能会在本地终端、IDE 扩展、远程工作区和 CI 系统中使用多种编程 agent。

对于 GitHub Copilot，管理员应向 GitHub 或 Microsoft 索取明确的修复指引。他们不应将无关的权限改进视为 checkout 漏洞已修复的确认。

在插件功能并非必需的情况下，禁用第三方 marketplace 软件包可带来最明确的临时风险降低。无法禁用这些软件包的组织，应暂停自动更新并限制仓库来源。

Gemini CLI 用户应评估迁移至 Antigravity，特别是在使用 marketplace 扩展时。企业客户也应就其所用确切 Gemini CLI 版本的状态索取书面确认。

在披露后移除受影响插件固然有用，但并不充分。受损软件包可能已在移除前建立持久化机制、修改启动文件、复制凭据或篡改仓库。

事件响应人员应审查插件更新历史、Git 活动、进程执行情况、网络连接和敏感文件变更。如果易受攻击的自动更新处于启用状态，相关时间窗口应从公开披露之前开始。

当遥测数据表明异常插件代码曾执行时，团队应轮换凭据。优先目标包括源代码控制令牌、云凭据、软件包发布密钥、签名材料，以及存储在 shell 环境中的密钥。

凭据范围与轮换同样重要。AI 编程 agent 不应仅因启动它的开发者拥有这些权限，就继承不受限制的生产环境访问权限。

独立的 agent 身份能让异常操作更容易被控制和审计。短期令牌也会降低从工作站收集到的凭据的价值。

运行时隔离提供了另一层防护。文件访问应默认限定于当前项目，网络访问则应使用与任务相适应的严格允许列表。

Shell 执行也需要类似边界。能够在开发者账户下调用任意命令的插件，可以绕过许多仅应用于生成源代码的控制措施。

组织应测试沙箱规则是否覆盖由插件、hooks、包管理器和 MCP servers 创建的子进程。对模型直接工具的限制，未必覆盖每一个扩展进程。

插件治理还需要更强的证据。内部目录应保存已审查的 commit、仓库来源、解析后的树标识符、审查者、批准日期和已部署版本。

安装程序应在 checkout 后验证解析出的 HEAD。若其与批准的 commit 不一致，安装必须停止，而不是仅发出警告后继续。

安全团队可以在不复现恶意执行的情况下测试这一行为。受控仓库可提供含糊的引用，同时验证系统检查安装是否以失败关闭的方式终止。

结果应成为采购和内部验收测试的一部分。供应商应能说明其 agent 如何在克隆、获取和更新后验证插件内容。

团队还需要可靠记录每个插件存在的原因。可搜索的工程知识库可以关联批准记录、负责人、事件和替换决策。

这些文档不能阻止被利用，但在下一次披露出现时，它们能缩短识别受影响团队并移除高风险集成所需的时间。

最后，不应因开发者信任了宣传中的固定版本而责备他们。据报道，Plugin4Shell 绕过的正是旨在让这种信任变得合理的控制机制。

纠正措施应覆盖供应商代码、企业策略和运行时架构。培训用户检查每一次更新，无法弥补安装程序执行的代码与已批准摘要不同的问题。

三项信号将显示 Agent 插件安全是否正在改善

下一项考验是，供应商是否会将这次披露转化为可验证的安装控制，而非更宽泛的安全承诺。

第一个信号是 GitHub Copilot 的明确修复措施。管理员应关注确认 checkout 后 commit 验证的安全公告、发布标识符或技术声明。

笼统的 Copilot 更新无法回答这个问题。相关证据在于客户端是否解析工作树的 HEAD，并将其与 marketplace 固定版本进行比较。

如果 GitHub 记录这一行为并将其发布到受支持的 Copilot 使用界面，当前的补丁缺口将缩小。持续沉默则会加深人们对漏洞处理不一致的担忧。

第二个信号是 Google 对企业 Gemini CLI 用户的澄清。公开迁移表述称企业访问和安全维护仍在继续，而 AIR 则报告没有 Plugin4Shell 补丁。

Google 可以通过列出受影响版本、说明是否存在修复，以及明确支持日期来解决这一矛盾。一份具体公告将帮助团队在修补和迁移之间作出决策。

如果 Gemini CLI 获得经验证的 commit 检查，AIR 在披露时的状态将不再适用。如果 Google 确认不会修复，组织就应将迁移视为安全要求，而非产品偏好。

第三个信号是 marketplace 层面对可验证客户端行为的采用。marketplace 无法单独强制最终 checkout，但可以要求兼容的 agent，并拒绝不安全的仓库配置。

有用的改进包括签名清单、不可变软件包工件、来源证明，以及包含解析后 commit 的安装收据。每项控制都应保持可独立测试。

Agent 供应商还应披露，插件是否在与生成命令相同的沙箱中运行。即使软件包经过验证，也可能在审查前的上游环节遭到入侵，或包含被忽略的漏洞。

更大的教训并非插件天然不安全，而是自主 agent 会将打包错误转化为以开发者权限执行的操作。

据报道，Plugin4Shell 横跨四个竞争产品，因为它们的实现依赖于同一个未经验证的假设：所请求的 Git 标识符被视为等同于实际安装的代码。

开发者和安全负责人现在应直接询问每一家编程 agent 供应商：有什么证据能证明经过审查的代码，就是机器上正在运行的代码？

在 Copilot 和 Gemini CLI 给出产品专属答案之前，受影响组织应限制插件使用、验证每个 agent 版本并隔离凭据。使用已修复 Claude Code 或 Codex 的团队，仍应审计已安装扩展，并确认更新已覆盖每一个终端。

Plugin4Shell AI 智能体漏洞归根结底是对运营可见性的考验。贵组织能否在下一次后台更新运行前，识别出每个智能体、其插件、版本以及权限？