Plugin4Shell击中四款编程Agent

四款主流编程 Agent 被指存在零点击 RCE

AI 编程工具正在暴露一个比提示词注入更直接的风险：攻击者可能借插件机制，在开发者没有点击“运行”或批准命令的情况下取得本机代码执行能力。 9 月 18 日，安全公司 AIR Security 披露一组名为 Plugin4Shell 的漏洞，并称其影响四款主流 AI 编程 Agent，包括 Claude Code、OpenAI Codex、Google Gemini CLI 与 Cursor 所代表的智能编程工作流。

Plugin4Shell 是一类由恶意插件、项目配置或生命周期钩子触发的零点击远程代码执行漏洞。 它并不是某个大模型“回答错了”，而是编程 Agent 在载入外部内容时，把本应视为数据的插件元信息、仓库配置或自动化指令，当成了可以直接交给 Shell 执行的可信操作。

“零点击”并不意味着攻击者可以隔空控制任何安装了 Agent 的电脑。 更准确地说，它意味着在开发者打开恶意仓库、载入受污染工作区、安装或更新插件之后，危险命令可能不再触发一次清晰、独立的人工确认；从恶意内容到命令执行的最后一段链路，可以自动完成。

截至 2026 年 9 月 18 日，公开披露的重点是漏洞类别与攻击链，而不是一份可直接套用的通用利用脚本。 AIR Security 使用“top four coding agents”描述受测产品，但不同客户端、版本、操作系统与安全设置可能产生不同结果，企业不应把“同一品牌”简单等同于“所有版本必然可利用”。目前也不宜在缺少厂商公告的情况下擅自填写统一 CVE、CVSS 分数或固定补丁版本。

漏洞不在模型里，而在模型旁边

AI 编程 Agent 是能够读取代码、调用工具、修改文件并执行命令的软件代理。 与只在网页里补全一段代码的聊天机器人不同，编程 Agent 往往拥有终端、文件系统、Git、浏览器、MCP 工具以及云端开发凭证等能力，因此它一旦做出错误的信任判断，后果会从“生成错误答案”迅速升级为“在真实机器上执行错误动作”。

插件是向 Agent 注入工具、命令、工作流或项目规则的扩展单元。 插件本身并不危险，危险在于插件安装、发现、更新和初始化过程中经常需要执行脚本，而这些脚本又可能继承开发者当前账户的全部权限。

生命周期钩子是插件在安装、启动、打开工作区或调用工具等特定阶段自动运行的命令。 它类似软件包管理器中的安装脚本：设计初衷是完成环境检测、依赖准备和代码生成，但如果来源校验、签名验证与权限隔离不足，钩子就会变成一条绕过对话确认框的执行通道。

AIR Security 描述的核心问题可以概括为四步：

1. 攻击者准备一个恶意插件、受污染仓库或经过篡改的项目级配置；
2. 开发者打开项目，或让编程 Agent 自动发现并载入相关能力；
3. Agent 在初始化、工具注册或插件更新过程中触发命令；
4. 命令以开发者账户权限运行，并接触本机文件、Git 凭证、SSH 密钥或云环境变量。

这条攻击链真正危险的地方是“权限拼接”。 单独看，读取项目说明、注册工具和执行终端命令都是编程 Agent 的正常功能；但当这三项能力缺少清晰边界时，攻击者只需要控制链路前端的一份内容，就可能借 Agent 完成后续所有高权限动作。

四类产品面对的是同一道信任题

四款受测产品的共同风险不取决于底层模型能力，而取决于客户端如何处理插件、工作区内容和命令执行。 一个推理能力更强的模型，甚至可能更擅长完成攻击者植入的复杂任务；模型基准分数、上下文长度和代码生成质量，无法替代操作系统级的权限控制。

| 产品或工作流 | 主要扩展入口 | 高风险权限 | Plugin4Shell关注点 | 企业应优先检查 | |---|---|---|---|---| | Claude Code | 项目指令、工具、插件与钩子 | Shell、文件系统、Git、环境变量 | 项目级内容能否触发自动命令 | 钩子策略、项目信任、凭证继承 | | OpenAI Codex | 本地工作区、命令执行与自动化配置 | 终端、仓库、网络访问 | 工作区载入与执行批准是否分离 | 沙箱模式、审批策略、网络出口 | | Gemini CLI | 扩展、项目上下文与工具调用 | Shell、文件、MCP 工具 | 扩展初始化是否默认执行脚本 | 扩展来源、版本锁定、工具白名单 | | Cursor | 编辑器工作区、规则、扩展与 Agent 工具 | IDE 终端、代码库、开发者令牌 | 打开项目后是否存在隐式执行路径 | Workspace Trust、扩展策略、终端确认 |

这张表比较的是攻击面，而不是断言四款产品在所有版本上具有完全相同的实现缺陷。 编程 Agent 的权限模型更新很快，桌面客户端、CLI、预览版功能和企业策略之间也可能存在差异，最终修复状态应以各厂商安全公告和发行说明为准。

价格和模型性能在这次事件中不是有效的安全指标。 即使企业购买最高等级套餐，如果客户端仍以开发者身份无隔离地执行插件脚本，付费层级也不会自动阻断 RCE；相反，一个能力较弱但运行在严格容器中的 Agent，实际风险可能更低。

它为什么被叫作 Plugin4Shell

Plugin4Shell 的命名是在借用 Log4Shell 的传播记忆，但两者不是同一个漏洞，也没有证据表明它们共享代码。 Log4Shell 是 Log4j 组件对攻击者可控字符串执行危险查找所导致的漏洞，而 Plugin4Shell 指向 AI 编程工具对插件与项目配置过度信任的问题。

| 对比项 | Log4Shell | Plugin4Shell | |---|---|---| | 主要对象 | Java 日志组件 Log4j | AI 编程 Agent 与插件机制 | | 攻击输入 | 被写入日志的恶意字符串 | 插件、仓库配置、项目指令或更新内容 | | 执行触发 | JNDI 等危险查找机制 | 插件初始化、生命周期钩子或工具调用 | | 典型权限 | 服务进程权限 | 开发者账户或 Agent 沙箱权限 | | 主要资产 | 服务器、业务系统 | 源代码、签名密钥、Git 与云凭证 | | 修复思路 | 升级依赖并禁用危险功能 | 更新客户端、禁用自动执行、隔离权限并校验来源 |

两者真正相似之处是“数据被错误解释成了动作”。 Log4Shell 让一段本应被记录的字符串触发远程加载，Plugin4Shell 则让一份本应被审查的插件或工作区内容进入可执行链路；命名上的“4Shell”强调的是从外部输入直达 Shell 的效果，而不是技术栈相同。

为什么开发者机器比普通终端更值钱

一台开发者电脑通常同时持有代码、身份和发布权限。 攻击者一旦借编程 Agent 取得命令执行，不必立刻加密硬盘或弹出勒索窗口，更高收益的做法往往是静默读取私有仓库、SSH 配置、npm 或 PyPI 发布令牌、容器仓库凭证以及云平台登录状态。

开发环境中的短期令牌并不天然安全。 即使凭证只有 30 分钟或 1 小时有效期，恶意进程仍可在触发后立即调用 Git、云 CLI 或内部制品库；如果终端已经完成单点登录，攻击者甚至不需要从磁盘中找到一个长期密钥。

插件更新链路会把单点漏洞放大为供应链事件。 一个此前安全且被大量团队信任的插件，如果发布账户、源码仓库或更新服务器被攻陷，恶意版本便可能沿正常更新渠道进入开发机器。Pillar Security 此前披露的 Hackerbot-Claw 事件也显示，攻击者已经开始利用项目指令文件和编辑器扩展影响 AI Agent，而不是只盯着传统依赖包。

项目级提示词注入与 Plugin4Shell 可以形成组合攻击。 恶意仓库先通过隐藏指令诱导 Agent 调用工具，再利用插件钩子或宽松的执行策略完成落地；前者解决“让 Agent 想做”，后者解决“让系统允许它做”。这也是为什么只在模型输出端增加敏感词过滤，无法解决此类问题。

真正有效的修复不是再加一个弹窗

厂商首先需要把插件安装、插件初始化和 Shell 执行拆成三个独立的安全决策。 用户同意安装一个插件，不应自动等于同意它在未来每次打开仓库时运行任意命令；用户允许 Agent 执行测试命令，也不应自动授予其读取 SSH 目录和云凭证的能力。

插件权限应当采用最小授权而不是继承整个开发者会话。 一个只负责格式化代码的插件不需要访问公网，一个只读取仓库的审查工具不需要写入用户主目录，一个生成单元测试的 Agent也不应默认继承生产环境凭证。

插件完整性校验必须同时覆盖来源、版本和内容。 仅展示发布者名称不够，客户端还应支持签名验证、哈希锁定、版本固定和更新前差异审查；企业环境则需要集中白名单，阻止开发者随意安装来源不明的 Agent 扩展。

项目可信与命令可信必须分开处理。 即使一个 GitHub 仓库来自知名组织，仓库里的分支、Pull Request、子模块和自动生成文件仍可能由外部贡献者控制，因此“信任仓库”不应永久放行其中所有脚本。

沙箱必须限制文件、网络和进程三类能力。 只把 Agent 放进容器还不够，如果容器挂载了用户主目录、Docker Socket 或宿主机凭证，攻击者仍可能越过隔离；只禁止联网也不够，因为恶意代码可以修改源码并等待开发者后续提交。

团队现在应该做什么

使用相关编程 Agent 的团队应立即完成版本、插件和执行记录盘点。 在厂商给出明确修复版本前，最稳妥的做法是把所有自动载入的项目配置和插件钩子视为不可信代码。

建议按以下顺序处理：

• 升级客户端与扩展： 安装厂商最新稳定版本，并重新检查预览功能是否默认开启；
• 暂停自动钩子： 暂时关闭打开工作区、安装插件和更新插件时的自动命令；
• 启用项目信任： 对新下载仓库、外部 Pull Request 和压缩包使用受限模式；
• 隔离高价值凭证： 不要让 Agent 进程直接继承生产云账号、发布令牌和长期 SSH 密钥；
• 收紧网络出口： 默认阻止开发容器访问云元数据地址、内部控制面和未知域名；
• 审计子进程： 搜索 Agent、编辑器或插件进程异常拉起 Shell、下载器、Git 和云 CLI 的记录；
• 检查持久化： 排查 Shell 启动文件、Git hooks、任务计划、IDE 启动项和本地插件目录；
• 必要时轮换凭证： 如果曾打开来源不明的仓库并允许自动执行，应按潜在失陷事件处理。

凭证轮换不能只更换一个 Git Token。 企业还需要检查该令牌访问过哪些仓库、是否创建过新密钥、是否修改了 CI/CD 配置，以及攻击者是否利用提交签名或发布权限植入了更持久的供应链后门。

安全团队也不应直接禁用所有 AI 编程工具。 一刀切会把使用行为赶到无法审计的个人设备和非受管环境，更合理的方案是提供受控版本、隔离运行环境、统一插件目录和可查询的工具调用日志。

这次事件给 AI Agent 行业提了一个醒

Plugin4Shell说明，Agent 安全的核心已经从“模型会说什么”转向“模型能够做什么”。 当 AI 只能生成文本时，错误回答主要影响信息质量；当 AI 可以写文件、执行命令和发布软件时，每一次工具调用都应像云平台权限变更一样被建模、限制和审计。

插件生态正在重复浏览器扩展和软件包管理器走过的老路。 开放扩展可以快速增长能力，但如果市场审核、签名、权限声明、更新审查和撤销机制没有同步建立，插件数量越多，供应链攻击面就越大。

这次披露最值得重视的不是“四款产品都中招”，而是四款产品可能共享同一种错误假设。 这个错误假设是：进入开发工作区的内容大体可信，Agent 为提高效率可以少问一次。对于传统 IDE，这可能只是便利性取舍；对于拥有终端权限的自主 Agent，这就是一条通向远程代码执行的捷径。

在厂商公布完整修复矩阵前，开发者应把 AI 编程 Agent 当作一个高权限自动化账户来管理。 不要因为它使用自然语言交互，就把它当成没有权限边界的聊天窗口；从系统安全角度看，它更接近一个能读代码、拿凭证、开进程并访问网络的持续集成执行器。

参考来源

• Model Context Protocol Specification：MCP 官方规范仓库，用于理解 Agent 工具与外部能力之间的信任边界。
• Anthropic Claude Code：Claude Code 官方仓库，可查询版本更新、安全说明与问题追踪。
• OpenAI Codex：OpenAI Codex 官方仓库，可核对本地执行、沙箱与发行版本变化。
• Google Gemini CLI：Gemini CLI 官方仓库，可查询扩展机制、安全公告和修复进展。
• GitHub Security Lab：GitHub 安全研究项目，用于参考代码供应链与开发工具攻击面的研究方法。

注：Plugin4Shell 的核心事件依据 AIR Security 于 2026 年 9 月披露的同名研究报告；受链接域名限制，本文不在参考列表中附其站外地址。