Plugin4Shell：AI 编程代理信任了错误的哈希值

他们信任的哈希，并非他们实际运行的哈希

AI 编程代理在验证自身扩展时存在一处安静却结构性的深层缺陷，现已暴露。AIR Security 将其命名为 Plugin4Shell，这个名字精准地揭示了问题所在：代理将固定的提交哈希视为永久保证，却在后续下载中未能验证实际获取的代码是否与之一致。

其结果是引发了一条 零点击远程代码执行 路径，无需社会工程学或钓鱼手段，用户甚至无需任何主动交互——只需代理在后台完成一次插件更新即可触发。

本次事件涉及四大主流平台：Anthropic 的 Claude Code、OpenAI 的 Codex、GitHub Copilot 以及 Google 的 Gemini CLI。截至 9月18日，Anthropic 与 OpenAI 均已发布修复版本。GitHub 与 Google 的回应仍不完整或尚不明确。目前该漏洞未分配 CVE 编号，公开层面也暂无证据表明存在现实中的活跃利用。这种严重性与实际活跃度之间的落差，值得密切观察。

SHA 固定机制为何失效

这些代理的插件商店依赖一种名为 SHA 固定（SHA pinning） 的机制。开发者安装或更新插件时，代理会记录特定的 Git 提交哈希，并假定此后每次拉取都会返回相同的代码。这一模型在理论上简洁而可靠：锁定哈希，你就绝不会运行未经明确核验的代码。

缺陷恰恰存在于“固定”与“核验”之间的断层。据 AIR Security 披露，部分代理在请求固定哈希对应的提交时，并未对下载的内容重新计算哈希值以确认一致性。如果攻击者控制了该仓库，便可托管一个在表面上哈希匹配、但实际文件内容与原始审查版本不同的提交。

这不是理论上的边缘案例。根据各平台 Git 实现方式的差异，攻击面通过两种途径打开。

对于 Claude Code、Codex 和 Copilot，研究人员利用了 Git 接受形似提交哈希的分支名 这一特性。GitHub 已收紧规则，现在会拒绝形如 40 位十六进制字符串的分支名，这意味着直接托管在 GitHub 上的插件受到了一定程度的防护。但 Bitbucket 和自托管 Git 服务器并不强制执行相同的限制，导致相关环境仍处于暴露状态。

Gemini CLI 则沦陷于另一种验证绕过机制。具体路径不同，但结果如出一辙：被固定的代码与实际执行的代码早已背离。

自动化如何将漏洞转化为武器

漏洞本身已属严重，但 自动更新功能 将其彻底武装。

Claude Code 与 Codex 均会在后台静默下载插件更新。一旦攻击者接管插件仓库或攻破开发者账号，代理便会推送恶意更新，并在开发者环境中以完全权限直接运行代码——无需确认弹窗，无需人工审批。

AIR Security 将该路径定性为零点击远程代码执行，因为用户根本无需安装任何新组件。一个原本安全的插件只需自动完成更新，便会悄然执行恶意代码。两种典型的攻击模式如下：

1. 攻击者先发布一个干净的插件，等待广泛采用，随后篡改仓库以大量用户基础为靶心推送恶意软件。
2. 攻击者直接攻陷已有可信插件的开发者账号或仓库，强行注入恶意代码。

权限的乘数效应

普通 IDE 扩展已携带可观风险，而 AI 编程代理的风险则呈数量级放大。

这些代理日常会读取源代码、修改项目文件、执行终端命令，并访问 Git 仓库、认证令牌、云凭证、SSH 密钥、CI/CD 流水线及内部开发基础设施。恶意插件无需提权，因为代理本身就已经拥有这些权限。

AIR Security 的定性极为精准：不应将插件视为小型附加组件，而应视其为继承用户完整权限的应用。正是这种继承模型，使 Plugin4Shell 在性质上区别于典型的扩展漏洞。

补丁现状与剩余漏洞

Anthropic 已在 Claude Code 2.1.179 中修复该问题。OpenAI 则在 Codex 0.146.0 中予以解决。两项修复均已上线，使用这些工具的企业组织应立即更新。

GitHub Copilot 尚未发布专项补丁。当前的实际缓解措施依赖于 GitHub 的分支命名限制，该限制已阻断针对托管在 GitHub 本身插件的“类哈希分支”攻击。然而，使用外部插件市场、Bitbucket 或私有 Git 服务器的团队依然处于暴露状态，而 GitHub 对此类环境的指引目前仍属空白。

Google 的 Gemini CLI 的应对态度暧昧。据报道，Google 引导用户转向新的代理环境，而非修复现有 CLI 的底层问题，但文档并未明确说明该底层验证缺陷在所有部署配置中是否已彻底解决。

从漏洞看 AI 代理供应链的隐忧

Plugin4Shell 并非孤立事件，而是针对 AI 代理软件供应链 构建方式的结构性质疑。随着这些工具从实验性开发团队走向企业核心工作流，曾经重创传统软件的供应链风险正以全新形态重现。

两条教训已清晰浮现：

• 仅固定哈希却不重新核验，不等于安全。 任何只记录哈希却从未在下载完成后对工件进行哈希比对的系统，在根基上就是破损的。修复方案很直接：每次拉取后、执行前，必须验证哈希。
• 缺乏细粒度信任边界的自动更新本身就是攻击面。 后台自动更新既为用户消减了摩擦，也为攻击者扫清了障碍。企业环境必须对插件更新设置明确的审批门禁，尤其是那些继承高权限的插件。

企业当下应采取的措施

当务之急是落实以下实用步骤：

• 将 Claude Code 升级至 2.1.179 或更高版本，将 Codex 升级至 0.146.0 或更高版本。
• 审计已安装的插件清单、固定的哈希版本，以及托管这些插件的仓库地址。
• 将安装范围限定于已批准的插件市场，并在策略层面拦截未经认可的外部来源。
• 密切监控所用可信插件的仓库归属变更及维护者账号安全。
• 在可能的情况下缩减代理权限，尤其针对 CI/CD 凭证和内部基础设施访问权限。
• 对于使用 Bitbucket 或自托管 Git 服务器的团队，在厂商发布更明确的修复指引前，应默认视为已暴露。

未被解答的疑问

无 CVE 编号，无确凿的现实攻击记录。这种组合对于一个如此关键的缺陷而言并不寻常，随之而来的是一个疑问：Plugin4Shell 会长期休眠，还是已被秘密囤积？

促成此次漏洞的架构——固定哈希却不重新核验、权限继承、无人值守的自动更新——正在更广泛的 AI 代理生态中被复制。尚未修补或仅部分修补的平台，实质上仍在运行同一套脆弱模型。

Plugin4Shell 不会是同类缺陷的终点。它理应是各组织真正严肃对待的第一课。