假Claude Code插件入侵Cursor市场：AI编辑器供应链风险警示

一款冒充Claude Code的恶意插件在Cursor官方市场上架约11小时，攻击者通过同名扩展植入远程登录密钥和卸载后仍残留的脚本。这起事件虽未造成大规模账号失守，却把AI编辑器生态的插件供应链风险摆到了台面上。

事件还原：11小时的同名陷阱

据YouTube视频披露，10月29日，一个与官方插件同名的编辑器扩展出现在Cursor市场中，发布者并非Anthropic，而是第三方攻击者。该扩展在市场上停留了大约11小时。

这个插件做了两件事：一是添加一个密钥，让陌生者可以远程登录；二是植入在卸载后依然留存的脚本。Cursor方面的回应是，陌生者的远程登录「一般会失败」，但插件仍然外传了计算机名称等细节信息。也就是说，即便登录环节被拦下，信息泄露已经发生。

对于当天在Cursor中安装过该扩展的用户，视频给出的建议很直接：无论如何都按Cursor的安全公告做一次清理。

为什么同名插件能骗过用户

这起事件的核心问题不在于攻击手法有多高明，而在于它利用了一个所有人都习以为常的盲区：市场里熟悉的名字，并不告诉你这个插件实际会做什么。

Cursor作为AI代码编辑器，其扩展市场沿用了传统IDE的信任模型——用户看到名字、图标和简介，就默认它是官方出品。攻击者正是把「同名」当作伪装，用最低的成本换取安装量。11小时的窗口不算长，但对于一个面向开发者的工具市场而言，已经足够完成一轮分发。

说个细节，这次事件针对的是Cursor的编辑器扩展，而不是Claude Code的插件。但视频特别提醒，这两类东西的风险边界正在变得模糊。

信任模型（Trust Model）指系统设计中对“谁是可信的”以及“信任如何建立与传递”的基本假设。传统IDE插件市场和移动应用商店普遍采用“平台审核+用户识别”的信任模型：平台负责上架前把关，用户则依赖名称、图标、下载量等信号判断真伪。这种模型隐含一个前提——上架内容已经过基本安全审查。但AI编辑器市场扩张迅速，审核往往滞后于插件数量增长，攻击者便利用“同名”低成本绕过用户的识别环节。信任模型一旦被静默打破，用户仍按旧习惯行事，风险便由此产生。

Claude Code插件同样能执行代码

Anthropic的文档明确指出，Claude Code的插件也可以在用户计算机上运行代码。这打破了不少人「插件只是配置文件」的错觉。

在Claude Code中，用户可以通过输入斜杠命令plugin并选择插件来查看详情。安装前，界面会展示一个标题为「Will Install」的区域，列出这次安装会带来什么。

关键要看三类内容：

• Skills：用于引导Claude的行为方向；
• Hooks：可以自行运行程序；
• MCP servers：同样具备自主执行程序的能力。

真正需要警惕的是Hooks和MCP servers。视频给出的判断方法是：看安装预览里是否列出了Hooks，或者干脆没有任何清单。如果有，就打开插件的代码仓库，逐条阅读hooks.json和.mcp.json里的命令。这两个文件才是插件实际执行逻辑的落脚点。

Hooks 是Claude Code插件中的生命周期钩子机制，允许插件在特定事件（如工具调用前后、会话开始或结束）触发时自动执行预设程序。它与普通配置文件的本质区别在于：配置文件只描述行为，而Hooks直接运行本地命令，因此具备与用户账号同等的文件与网络访问权限。攻击者若在hooks.json中写入恶意命令，插件一旦安装即可在后台执行，无需用户主动触发。这也是安全审阅中应优先检查Hooks的原因——它把“插件”从被动描述变成了主动执行者。

MCP（Model Context Protocol）是Anthropic提出的一种开放协议，用于让AI助手以标准化方式连接外部工具、数据源和服务。MCP server即实现该协议的服务端程序，它可以在用户本地或远程运行，并向Claude暴露可调用的工具接口。问题在于，MCP server本身是一个独立进程，具备自主执行程序的能力，插件通过.mcp.json声明要启动哪些server、传入什么参数。若声明中夹带恶意server或篡改启动命令，插件就获得了在用户机器上运行任意代码的通道。因此审阅.mcp.json与审阅hooks.json同等重要。

安装前的三道检查

面对无法完全信任的插件，视频提供了从轻到重的三层验证方式。

第一层是安装预览。利用Claude Code的「Will Install」清单，先确认插件会引入哪些组件，尤其是Hooks和MCP servers是否存在。

第二层是源码审阅。直接打开仓库，阅读hooks.json和.mcp.json中的命令内容。这一步需要一定的技术判断力，但它是唯一能看到插件「实际做什么」而非「声称做什么」的方法。

第三层是自动化扫描。NVIDIA提供的免费工具SkillSpecter可以扫描插件文件中的风险模式，作为额外的交叉检查。

如果走完这三步仍然说不清插件会运行什么，视频的建议是：跳过它。这个判断标准看似保守，但对于拥有你本地代码和凭证访问权的工具来说，谨慎是合理的默认值。

供应链信任需要重新校准

把这次Cursor事件和Claude Code的插件机制放在一起看，会发现一个共同的趋势：AI编程工具的扩展生态正在复刻传统软件供应链的老问题，但风险系数更高。

传统IDE插件的权限通常有较清晰的边界，而AI编辑器插件往往需要读取项目上下文、调用外部服务、甚至代表用户执行命令。一旦恶意插件获得安装，它拿到的可能不只是文件读取权，还有与AI助手等同的信任级别。

Cursor的11小时窗口和「远程登录一般失败」的结果，某种程度上是运气和防御机制共同作用的结果。但它暴露出的事前审核缺口并不会自动消失。对开发者而言，能做的不是等待市场平台完善审核，而是把「安装前检查」变成肌肉记忆——看清单、读配置、必要时用扫描工具兜底。

插件市场的名字可以伪造，仓库里的命令不会。检查发生在运行之前，才有意义。

软件供应链攻击指攻击者不直接攻击目标系统，而是入侵或伪造目标所依赖的组件（插件、库、更新包等），借由正常的分发渠道把恶意代码送入目标环境。这类攻击的可怕之处在于它绕过了外围防御——用户主动安装、平台正常分发，恶意代码却随之进入。AI编辑器插件生态尤其脆弱：插件需要读取项目上下文、调用外部API、代表用户执行命令，权限边界远宽于传统工具。Cursor事件中攻击者仅靠“同名”即可完成分发，正是供应链信任被利用的典型样本。防御重心因此从“平台是否审核”转向“安装前是否核验组件实际行为”。