Plugin4Shell 漏洞打破了 AI 编程代理的一项核心安全承诺

尽管采用了固定插件版本，Plugin4Shell 仍在四大 AI 编程代理产品家族中暴露出一条零点击远程代码执行路径。安全研究人员表示，Plugin4Shell 漏洞影响了 Anthropic Claude Code、OpenAI Codex、GitHub Copilot 和 Google Gemini CLI。

这一缺陷之所以重要，是因为这些代理不只是提供代码建议。它们能够读取代码仓库、执行命令、访问开发凭证，并与内部服务通信。恶意插件无需先攻破另一道权限边界，就可能继承这些能力。

研究人员称，Anthropic 和 OpenAI 已发布修复措施。Microsoft 对报告中的攻击路径是否仍可通过 GitHub 利用提出异议；但研究人员坚持认为，其他受支持的 Git 托管平台仍保留这一风险。Google 并未修复已弃用的消费级工具，而是建议许多 Gemini CLI 用户转向其较新的 Antigravity 环境。

这并不只是又一个提示注入故事。攻击瞄准的是插件分发层，并绕过了一项常见的软件供应链控制机制。代码审查和提交固定版本看似都能成功，但代理实际安装的可能是不同的代码。

这一反转让代理市场背后的安全模型承受压力。当客户端未能验证实际进入工作目录的内容时，仅信任经过审查的插件已不再足够。

Plugin4Shell 漏洞改变了什么

Plugin4Shell 会将一个已安装、此前受信任的插件，变成静默执行代码的途径。

Air Security 的研究人员在 2026 年 9 月 17 日披露了这一问题，此前他们已于 6 月向受影响厂商报告。其 Plugin4Shell 研究描述了编程代理在解析固定 Git 提交时存在的一项共同错误。

插件市场可以审查某个扩展，并记录包含已批准代码的确切提交。这一过程称为 SHA 固定。SHA 是一种十六进制标识符，通常指向一个特定的 Git 提交。

固定版本本应防止后续的仓库变更悄然替换已经审查过的代码。即使攻击者修改了某个分支，代理也应持续获取已批准的提交。

Plugin4Shell 在检出过程中打破了这一预期。受影响的代理会请求固定值，但未能可靠确认最终工作树与该值相符。Git 可能会将一个含义模糊的名称解释为分支或其他引用，而不是预期的提交。

研究人员演示了两种相关变体。据报道，Claude Code、Codex 和 GitHub Copilot 会因名称类似 40 字符提交哈希的分支而暴露风险。Gemini CLI 则使用了涉及 FETCH_HEAD 的另一种歧义。

在第一种变体中，攻击者必须控制插件背后的仓库。攻击者创建一个名称与固定提交哈希相同的分支，并将其设为默认分支。

代理克隆仓库后，要求 Git 检出该固定值。当一个名称既可表示分支，也可表示对象标识符时，Git 会优先匹配相应引用。它可能会发出警告，但仍会检出攻击者的分支。

随后，代理会报告安装成功。然而，其工作目录中的文件来自恶意分支，而不是已审查的提交。

在 Gemini CLI 变体中，代理会获取正确的提交并将其记录在 FETCH_HEAD 中。名称相同的恶意默认分支可影响后续检出。因此，正确获取的对象可能被忽略。

技术修复很简短。检出后，代理必须解析 HEAD 并将其与预期提交哈希比较。任何不匹配都应停止安装或更新。

后果不止于一次完整性检查失败。编程代理插件可以包含钩子、命令和指令，并以代理在操作系统中的权限运行。

研究人员将结果归类为远程代码执行，即 RCE。这个术语意味着攻击者可以从远程位置让选定代码在另一台机器上运行。

恶意替换一旦发生，无需进行新的安装。据 Air Security 称，Claude Code 和 Codex 默认启用插件自动更新。后台更新提供了零点击攻击的组成部分。

开发者可以遵循预期的安全流程，安装获批插件并固定其已审查版本。后续更新仍可能在无需再次提示的情况下将其替换。

因此，Plugin4Shell 反映的是验证失效，而非用户随意点击。受害者无需接受可疑文件、批准命令或安装未知扩展。

为何 AI 编程代理 RCE 的风险格外高

AI 编程代理的价值来自其访问权限，而这些相同的访问权限也决定了遭入侵后的破坏程度。

传统代码助手主要在编辑器中返回建议。智能代理工具则可检查文件、修改项目、启动测试、调用包管理器，并与云端开发系统交互。

这些能力减少了重复性工作，也使代理更接近攻击者觊觎的机密和系统。

开发者工作站可能包含源代码、SSH 密钥、软件包注册表令牌、云凭证、浏览器会话、签名材料和内部文档。环境变量还可能向开发期间启动的进程暴露额外凭证。

代理还可能继承已通过身份验证的命令行会话。当代理本身已经拥有有用权限时，恶意插件未必需要另行利用提权漏洞。

Air Security 表示，插件会继承运行代理的员工所拥有的能力。这一说法取决于各个本地配置，但准确概括了核心风险：潜在影响取决于代理的实际访问权限。

一个受到严格沙箱限制且无网络访问权限的代理，面临的是一种级别的暴露风险。运行在携带生产凭证的开发者笔记本电脑上的代理，则面临大得多的风险。

这种差异使严重性评级变得复杂。同一个检出缺陷可能影响一次性测试容器和具有高权限的工程工作站。它们造成的业务后果不可同日而语。

攻击还可通过受信任的市场跨越组织边界。攻击者可以先发布无害插件，通过审查，等待用户采用；在用户建立信任后再修改仓库。

第二条路径始于仓库接管。攻击者入侵或重新获得与合法插件作者相关基础设施的控制权。Plugin4Shell 随后会绕过原本旨在控制该事件影响的提交固定机制。

Air Security 将这一途径与其此前的 SkillJacking 和 RepoJacking 研究联系起来。该公司称，之前曾发现 925 个可被劫持的技能，影响 134,000 个代理。

这些数字来自该安全厂商，尚未在此处获得独立复现。尽管如此，它们仍表明，除模型行为外，仓库所有权和插件身份同样值得关注。

研究人员还称，此前一个恶意技能曾触及超过 26,000 个代理。该实验表明，市场曝光度能够迅速分发可执行内容，尽管它并不衡量 Plugin4Shell 的实际利用情况。

这些案例凸显了开发者工具中的一个棘手转变。当 AI 插件能够注册命令、运行生命周期钩子或影响工具执行时，它就不再只是提示模板。

组织应将这类扩展视为软件包。它们需要来源验证、受控更新、权限边界和事件可见性。

这项已报告的漏洞也促使厂商明确市场安全的边界。市场可以检查提交的代码，但实际执行安装的是本地客户端。

这种分工很重要，因为最终完整性决策发生在终端设备上。市场记录无法证明代理实际写入磁盘的内容。

因此，安全团队需要掌握已安装代理扩展的清单。他们还需要了解这些代理能够访问哪些系统，以及执行期间哪些凭证仍然可用。

开发者还面临相关的文档问题。插件设置、权限、更新行为和事件记录往往分散在代码仓库和聊天线程中。一个可搜索的工程知识库可帮助团队保留这些运营决策。

文档本身无法阻止漏洞利用。但当团队必须识别受影响的安装、责任人和预期更新策略时，它可以减少混乱。

受信任插件成了主要对手

Plugin4Shell 将受信任、固定版本插件的承诺，与未经验证的客户端检出现实直接对立。

行业的安全叙事一直依赖于几个合理步骤：审查扩展、批准特定修订版本、记录其哈希，并确保未来安装始终绑定到这一不可变对象。

在 Plugin4Shell 下，这些步骤仍可能全部发生。故障出现在最后一道边界：代理将请求的修订版本转化为文件和可执行行为的位置。

这使得该漏洞比市场中公开包含恶意代码的插件条目更令人不安。审查者可以检查正确的提交。管理员可以确认固定版本确实存在。日志也可以显示请求值已被使用。

但已安装的内容仍可能与已审查的内容不同。

研究人员将其描述为插件 SHA 固定绕过。这个标签很有用，因为它指出了被破坏的保证，同时并不意味着 Git 密码学本身失效。

提交哈希仍然有效。弱点在于名称解析和缺失的检出后验证。

Git 允许灵活的引用方式，因为开发者在许多工作流中使用分支、标签、远程引用和对象标识符。模糊引用处理一直是一个长期的运维问题。

编程代理将这种行为转变为自动化安全边界。它们将成功执行检出命令视为请求的提交已成为工作树的证明。

命令的退出状态只回答了 Git 是否完成操作，并不能回答最终的 HEAD 是否匹配市场固定的版本。

这一区别是从实务角度理解 Plugin4Shell 的核心。安全元数据描述的是一个对象，而实际执行的却来自另一个对象。

因此，市场和终端设备持有的是不同版本的现实。市场认为自己授权了一个固定提交；终端设备则信任 Git 的名称解析，而未比较最终状态。

自动更新放大了这一缺口。安装时的警告或许会在手动设置时引起注意；后台更新却可能在开发者进行无关工作时重复这一脆弱流程。

这一设计也削弱了“只安装受信任插件”的常规建议。安装时建立的信任无法预测上游仓库日后是否会遭入侵。

更重要的问题是：在每次更新期间，信任是否仍然可验证。这要求检查仓库身份、预期提交内容、解析后的 HEAD、可用的签名，以及插件请求的能力。

没有任何单一检查可以取代沙箱机制。即使经过正确验证的代码，也可能包含审查遗漏的漏洞或蓄意恶意行为。

因此，最小权限仍然是第二道控制措施。智能体应仅获得完成当前任务所需的文件、凭据、网络路由和命令能力。

这可能造成摩擦。当每项操作都需要人工批准，或缺少访问必要系统的权限时，编程智能体的实用性会降低。

Plugin4Shell 清楚地揭示了这种权衡。更高的自主性能够加快工作流程，而更广泛的权限则会提高任何被攻陷扩展的价值。

企业不能仅凭市场声誉来解决这种矛盾。它们需要在安装、执行、身份、网络和更新各层面部署控制措施。

正是在这里，AI 编程智能体安全开始类似于成熟的软件供应链安全。名称虽新，核心问题却很熟悉。

谁发布了这个组件？审查的是哪些确切字节？终端上运行了什么？该进程能访问什么？调查人员之后能否还原事件经过？

补丁虽有帮助，但厂商回应让风险呈现不均衡状态

当前的即时暴露风险取决于智能体、其版本、插件来源，以及厂商对可利用性的判断。

Air Security 表示，Anthropic 已在 Claude Code 2.1.179 中修复该漏洞。其称，OpenAI 在协调披露后于 0.146.0 版本中修复了 Codex。

用户应核实已安装的版本，而非假定自动更新已经完成。组织还应确认哪些受管镜像、开发容器和远程工作站仍在使用旧版本。

微软产品的情况仍存在争议。Air Security 表示，GitHub Copilot 的实现受到影响，并称微软在披露前尚未发布智能体端修复。

一名 GitHub 发言人告诉 The Register，GitHub 会阻止看起来像提交哈希的分支或标签名称。该公司认为，这一限制能够防止针对 GitHub 托管仓库的所述攻击。

这一回应解决了一个重要前提条件。如果托管平台拒绝此类名称，攻击者就无法创建存在歧义的 40 字符分支。

研究人员表示，这种主机级限制并未封堵所有受支持路径。他们的论点聚焦于通过 Bitbucket 和自托管 Git 服务托管的市场或仓库，因为这些服务可能允许 SHA 形态的分支名称。

不应将这项分歧简化为任一方已经完全解决问题的说法。GitHub 的托管限制能够阻断在 GitHub 本身演示的分支名称攻击路径。

但这并不必然证明，每个 Copilot 支持的市场来源都获得了同等保护。更广泛的问题取决于该产品接受哪些主机及其安装行为。

在 The Register 的文章发布前，微软尚未向该媒体提供进一步回应。用户应关注产品公告，以了解受影响配置和支持的缓解措施。

Google 则呈现了另一种不同寻常的情况。Air Security 表示，Gemini CLI 受到了其独特 FETCH_HEAD 变体的影响，但 Google 拒绝为这款已弃用的消费者工具修补漏洞。

Google 于 2026 年 5 月 19 日宣布其 CLI transition。该公司将其消费者重点转向 Antigravity CLI 和 Antigravity 2.0。

Google 表示，Antigravity CLI 当天已正式全面推出。通过 Gemini CLI 及相关个人服务的消费者访问原定于 6 月 18 日停止。

企业访问并未在相同条件下结束。Google 的公告称，部分企业客户可以通过授权服务和企业 API 密钥继续使用 Gemini CLI。

这种区别意味着，“已弃用”一词不足以支撑风险决策。安全团队需要确定 Gemini CLI 是否仍在其环境中安装、可用并连接到插件。

Air Security 表示，Antigravity 不受所报告攻击的影响，因为它缺少相同的市场 SHA 固定机制。这一说法比“新产品不存在插件风险”要狭窄得多。

引用披露中没有公开证据表明 Plugin4Shell 已在现实环境中被积极利用。研究人员演示了概念验证及相关接管技术。

这一差距很重要。可用的利用链证明了技术可行性，但不能说明有多少终端已经被攻陷。

“数百万智能体受到影响”的说法同样需要谨慎对待。主要产品拥有庞大的用户群体，但并非每位用户都会安装市场插件或启用易受影响的配置。

是否暴露取决于已安装的插件、可控的上游仓库、兼容的 Git 主机、存在漏洞的客户端行为，以及足够的执行能力。

组织应避免走向两个极端。它们不应因为主动利用尚未得到确认就忽视这一问题，也不应将每次安装都视为已经被攻陷。

合适的响应应当针对具体配置。在评估事件严重程度前，应盘点版本、插件来源、更新记录、仓库主机和终端权限。

Plugin4Shell AI 智能体需要的不只是版本检查

更新受影响的客户端是必要的，但这无法回答恶意插件是否已到达终端。

团队应从发现产品和版本开始。他们需要在员工设备和受管开发系统中定位 Claude Code、Codex、GitHub Copilot 集成以及 Gemini CLI。

盘点必须包括远程环境。云工作站、开发容器、CI 运行器和共享构建主机都可能在传统终端管理视野之外运行智能体工具。

接下来是插件发现。团队应列出已安装的附加组件、其市场、仓库位置、固定哈希、当前解析后的提交以及自动更新设置。

仅在配置中记录固定版本并不够。管理员应将预期提交与已安装工作树中实际的 HEAD 进行比较。

他们还应审查仓库托管规则。GitHub 对 SHA 形态引用的拒绝改变了已演示的攻击面，而 Bitbucket 或自托管 Git 服务可能表现不同。

这并不意味着非 GitHub 主机天然不安全。这意味着 GitHub 所述的缓解措施依赖于平台特定的命名限制。

使用易受影响版本的组织应在已有修复时进行更新。根据 Air Security 的披露，Claude Code 用户需要使用 2.1.179 或更高版本。

根据同一指导，Codex 用户需要使用 0.146.0 或更高版本。当正式公告可用时，管理员应根据厂商维护的发布信息确认这些版本门槛。

Gemini CLI 用户应评估迁移至 Antigravity。仍保留访问权限的企业客户需要 Google 就受影响配置和补偿性控制措施提供明确指导。

Copilot 用户应关注微软的回应，同时审查其插件来源是否扩展到 GitHub 托管仓库之外。禁用插件更新或许能降低即时暴露风险，但也会延迟合法的安全修复。

这种矛盾表明，应采用受控更新而非永久冻结。企业可以镜像已批准的插件、限制来源、验证解析后的提交，并在验证后推广更新。

执行控制措施提供了另一层防护。应在隔离环境中运行编程智能体，限制其访问生产凭据，并阻止不必要的出站连接。

短期凭据可降低从被攻陷会话中获取的机密的价值。独立的开发身份也能防止一台工作站被攻陷后接触到生产管理权限。

网络监控应查找来自智能体或插件进程的意外连接。终端工具应保留进程树、命令历史、修改过的文件以及凭据访问事件。

团队应检查插件生命周期钩子，因为这些路径可能在开发者开始正常对话前执行。后台任务应获得与可见智能体命令同等的关注。

仓库维护者也负有责任。他们应通过强身份验证保护插件仓库，审查所有权变更，并从市场列表中移除被废弃的基础设施。

即便无法完全修复客户端漏洞，市场仍可改善来源可信度和监控能力。它们可以限制受支持主机、重新验证仓库所有权、标记异常的默认分支变更，并暂停可疑更新。

不过，终端仍必须验证检出的提交。Git documentation 解释了 checkout 如何接受分支、标签和提交标识符，从而形成客户端必须安全处理的歧义。

安全教育应反映这种新的执行模型。开发者需要理解，智能体技能和插件可能是可执行软件，而不是无害的指令包。

清晰的内部 AI workflow 可以帮助负责人追踪缓解工作和未解决的厂商问题。实际防御措施仍必须落实在终端和访问控制中。

最后，团队应准备好调查触发阈值。提交不匹配、无法解释的插件更新、异常子进程或意外网络请求，都应触发更深入的审查。

这些信号并不能证明发生了 Plugin4Shell 利用，但它们提供了保留证据并检查受影响智能体权限范围的具体理由。

三类信号将表明风险是否得到控制

下一阶段将由厂商清晰度、利用证据和更强的市场验证机制决定。

第一个信号是微软或 GitHub 发布涵盖受支持插件来源的安全公告。它应说明 Copilot 是否接受 GitHub 之外的市场，以及客户端验证是否会发生变化。

仅针对 GitHub 分支命名的狭窄声明，仍会留下有关 Bitbucket 和自托管仓库的问题。验证解析后提交的产品修复，将增强研究人员更广泛的结论。

如果有文档化结论表明 Copilot 从不处理这些来源，则会削弱这一结论。无论哪种结果，都会为企业用户提供更清晰的行动依据。

第二个信号是现实世界利用的证据。如果安全厂商、事件响应团队和产品制造商发现恶意 SHA 形态分支或被替换的插件内容，就应发布相关指标。

确认的攻陷会使 Plugin4Shell 从已演示的漏洞进入活跃事件类别。持续未发现滥用行为将降低即时紧迫性，但不会消除修补的必要性。

检测质量在这里很重要。组织可能缺少智能体插件的资产清单，而后台更新可能看起来像正常的开发者活动。

第三个信号是插件验证设计的变化。智能体厂商应开始在每次安装和更新后检查解析后的 HEAD，然后通过日志公开该结果。

市场可以增加签名、发布者身份控制、可复现打包和更清晰的权限声明。这些功能都不应取代终端验证。

Plugin4Shell 即使在所涉版本退出历史舞台后，可能仍具现实意义。其核心教训适用于任何这样的情况：安全元数据引用的是一个构件，而客户端实际执行的却是另一个构件。

AI 编程代理让这种不匹配的后果更加严重，因为它们集代码检索、工具调用、本地执行和企业访问权限于一身。它们的价值依赖于这些能力，而这些能力同样会扩大遭入侵后的影响范围。

在信任某个代理扩展之前，开发者应先提出一个务实的问题：系统能否证明，已审核的代码就是当前正在运行的代码？

安全负责人还应提出第二个问题：如果这一证明失效，代理在有人察觉之前能够访问什么？

Plugin4Shell 漏洞表明，这两个问题都应纳入日常工程治理。及时更新已修复的客户端是眼前任务；验证执行内容、限制权限并保留证据，则是更长期的要求。

使用 Claude Code、Codex、Copilot 或 Gemini CLI 的团队应立即盘点自身版本和已安装的插件。他们应将预期的固定版本与实际解析出的提交进行比对，并记录任何尚未明确的、厂商特定的风险。