AI Agent插件能绕过权限？Cursor攻击揭示安全漏洞

写在前面

人类在使用编码类 Agent 时，早已习惯层层权限确认。读取文件要授权，执行命令要批准，访问网络要放行，部分操作还能提前配置固定范围。这些机制确实约束了 Agent 的行为。可一旦换一个视角追问：当寄生在 Agent 周围的第三方插件本身就藏着恶意代码，前面的权限确认还靠得住吗？答案并不乐观。最近的两起事件把这个问题摆到了台面上：Cursor 扩展市场出现被恶意篡改的 Claude Code 扩展，欧盟计算机应急响应团队 CERT-EU 则用实验证明，第三方插件能绕过模型的工具调用流程，在后台采集并外传凭据。Agent 的安全问题，已经不再局限于模型本身，插件及其运行环境同样进入威胁面。

一次看似寻常的扩展更新

2026 年 10 月 29 日，Cursor 扩展市场在约 11 小时内出现两个被恶意修改的 Claude Code 扩展版本，编号分别是 2.1.312 和 2.1.313。两个版本都沿用了合法扩展的标识，但恶意改动与 Anthropic 无关。微软的分析确认，官方 Visual Studio Marketplace 与 npm 发布渠道都没有受到影响，问题集中在 Cursor 自身的扩展分发环节。

安装或更新编辑器扩展，本是最普通的一件事。长期使用的工具自动更新后，用户甚至不会留意版本变化。攻击者恰恰借用了这个入口，把恶意代码塞进扩展的 JavaScript 文件，让它随扩展模块的加载自动执行。

恶意代码先收集主机名、用户名、操作系统、工作目录、Git 邮箱等信息，随后尝试改写本地 SSH 配置。它会向 authorized_keys 追加攻击者控制的公钥，再尝试开启 SSH 服务，通过反向 SSH 隧道建立远程访问通道。为了维持连接，恶意代码还会按操作系统写入启动配置：macOS 上创建 LaunchAgent，Windows 上创建计划任务，并准备备用启动脚本。这意味着即便用户关闭编辑器，相关脚本仍可能继续运行。

更隐蔽的是，扩展原本的功能依旧正常。恶意代码刻意压低可见输出，执行失败时也会藏起错误。照常使用扩展的人，未必能察觉后台正在发生的异常动作。这次攻击并非每个环节都成功：恶意代码自身存在错误，加上启用 SSH 服务需要管理员权限，远程登录在多数 macOS 和 Windows 主机上并未奏效。Cursor 随后下架相关版本，并与服务商协作关闭了攻击者的服务器。可远程登录失败，并不代表此前的恶意行为没有发生。SSH 公钥写入、持久化脚本创建、主机信息收集仍可能执行。Cursor 因此在安全公告中特别提醒：仅卸载或更新扩展，无法保证清除已经写入系统的恶意文件。

Agent 权限控制的覆盖范围

使用编码 Agent 时，权限确认并不陌生。Claude Code 在执行部分命令前会请求用户批准，也允许用户配置文件的访问范围、工具的使用权限以及 Hook。既然存在这些限制，为何恶意扩展仍能读写本地文件，甚至改动 SSH 配置？关键在于，Agent 权限控制与操作系统进程权限是两套体系。

以编码 Agent 为例，运行环境包含模型、Harness、工具与第三方扩展。模型负责理解任务并生成操作指令，Harness 负责组织执行流程、调用工具并管理权限，第三方扩展则借助运行环境提供的接口参与协作。当模型请求读取文件或执行命令时，Harness 能检查操作是否需要授权。但第三方扩展里的 JavaScript 或 Python 代码，同样可能在加载、初始化或特定事件触发时自行执行。只要运行环境放行，这些代码就能调用系统 API、访问本地文件、发起网络请求，整个过程未必经过模型的工具调用流程。举例来说，一个插件为了读取项目配置，可能拥有访问工作目录的权限。一旦使用者把 SSH 密钥、API Token 或云服务凭据存放在该目录，恶意插件就能借已有权限直接读取。也就是说，即便模型严格遵循工具调用的权限规则，也无法保证运行环境里的所有代码都受到同等约束。类似问题在传统 IDE 插件与软件供应链中同样存在。随着 Agent 接入更多工具和外部资源，第三方组件能参与的执行环节、能接触的任务数据都在增加，权限管理随之变得更加复杂。

藏在插件中的触发机制

2026 年 10 月 30 日，CERT-EU 发布的安全研究触及同一议题。研究人员在隔离环境中，分别对 Pi 1.3.0 与 Claude Code 2.1.304 使用的第三方组件进行修改，在原有事件处理逻辑中植入隐藏代码，使其能绕过模型的工具调用流程。具体做法是：在 Pi 中注入 before_agent_start 事件处理器，在 Claude Code 中利用插件已有的 UserPromptSubmit Hook 规则处理流程。这些入口能在 Agent 执行正常任务时被触发，无需模型主动发起工具调用。

为了验证攻击效果，研究人员设置了一个触发条件：只有当输入中出现"lgtm, ship it"时，隐藏代码才运行。这是代码审查里很常见的一句话，大意是代码看起来没问题、可以合并或发布。其余场景下，插件保持原有功能，也不向外发送数据。实验结果中，两套环境都成功触发了凭据收集与信息传输，涉及主机信息、网络配置、环境变量及工作目录中的凭据文件。与此同时，Agent 仍正常回复用户，模型没有主动请求读取敏感文件，也没有留下明显的恶意工具调用记录。研究人员还测试了相关安全控制：在当时的实验配置下，针对模型文件读取工具的限制，无法阻止插件事件处理器自行访问文件；工具调用检查机制也未能发现后台的数据传输。这说明，即使模型的工具调用受限，运行在同一环境中的第三方代码，仍可能通过其他执行入口触碰敏感资源。

需要补充的是，这项研究在隔离环境中完成。研究人员仅修改了本地组件副本，没有向公开仓库发布恶意版本，也没有使用真实用户凭据。实验展示的是第三方组件可能带来的风险，并不意味着 Pi 或 Claude Code 的官方组件存在相同后门。此外，触发词由用户输入，但类似内容也可能出现在日志、邮件或 Agent 读取的文件中。若插件能检查工具返回的数据，攻击者就能把触发条件藏进外部内容，让 Agent 在处理正常任务时激活恶意逻辑。

Agent 的信任边界正在扩大

Agent 能访问的资源越多，第三方组件引入的风险就越复杂。过去安装 IDE 插件，关注点集中在代码访问、命令执行与依赖安全。如今，Agent 还会连接代码仓库、云服务、数据库、内部知识库以及各类 MCP Server，接触更多业务数据和敏感信息。为了减少人工操作，团队又会配置自动运行的 Hook、长期有效的凭据和常驻后台的服务。这些配置提升了执行效率，也放大了第三方组件可触及的资源范围。一旦插件被恶意修改或入侵，影响可能越过 Agent 原本承担的任务。

这里需要区分两种权限。一种是模型能够请求执行哪些操作，例如使用 Bash、修改文件或访问网络；另一种是 Agent 进程及其插件所持有的系统权限，例如读取用户目录、启动子进程或访问凭据文件。前者可通过 Harness 的工具授权机制管理，后者还需要操作系统权限、进程隔离、文件访问控制与网络策略共同约束。如果 Agent 以日常账户运行，且能访问大量本地资源，那么加载到同一进程的第三方代码，也会继承这些访问权限。因此，评估 Agent 的安全性，还要关注插件的安装来源、更新过程、Hook 的执行环境，以及外部网络连接是否受限。这些因素共同决定了第三方组件能访问什么，以及安全问题发生时影响的范围。

运行环境的权限管理

对个人开发者和团队来说，可以依据第三方组件的执行能力与资源访问范围，对 Agent 的运行环境做适当限制，降低插件被恶意修改后的安全风险。

• 插件来源与更新。市场里的名称、下载量、发布者信息只能作参考，不能保证每个版本都安全。对能执行本地代码的扩展，团队应建立组件白名单、固定版本，并在更新前审查代码变化，减少恶意版本进入开发环境的机会。
• 限制敏感资源的访问范围。若 Agent 只需读写某个项目，就没有必要开放对整个用户目录和长期有效凭据的访问。可使用专用的低权限账户收窄运行环境；必须使用的 API Token，也尽量采用短期有效、权限范围明确的令牌。
• 网络访问限制。Cursor 事件与 CERT-EU 实验都涉及向外部地址建立连接或传输信息。限制不必要的出站连接，能降低敏感信息外传的风险。
• 运行环境可观测性。Agent 的工具调用日志只能记录显式操作，插件自行发起的系统调用未必会写入其中。对接入内部系统的 Agent，还应监控进程启动、敏感文件访问、扩展更新与异常网络连接等行为。
• 无人值守场景。在 CI/CD 及其他自动化工作流中，Agent 可能长时间无人值守，人工检查机会更少。此时提前配置权限隔离、网络限制与运行审计，能减少对人工监管的依赖，也便于及时识别异常。

值得留意的一点是：当多个模型和多个服务需要通过同一套凭据体系对外暴露能力时，凭据的集中托管与动态签发就变得关键。一个 API 网关能统一收敛 token 的获取、轮换和按租户隔离，例如 koalaapi 这类网关把密钥从业务代码里抽离，再叠加短期令牌与最小权限策略，从而压缩凭据散落在工作目录里被恶意插件读取的概率。这类治理手段并不替代进程隔离，但能把"凭据外泄"这一常见损失面收窄到单一、可控的入口。

结语

Cursor 的恶意扩展事件说明，一次正常的软件更新就可能把恶意代码带进开发环境。CERT-EU 的实验则展示了另一种可能：插件能绕过模型的工具调用流程，在后台访问敏感资源，而 Agent 依旧正常完成用户任务。因此，Agent 的安全管理必须覆盖环境中的第三方组件及其运行环境，包括插件的执行权限、资源访问范围和后台行为。除了检查 Agent 被允许执行哪些操作，更要关注运行环境中的代码究竟能做什么。安全评估的对象，正从一行提示词，延伸到它脚下整片运行环境。