Cursor 插件市场出现恶意 Claude Code 包

看到 Anthropic 的名字、熟悉的 Claude Code 扩展标识，再点一次更新，拿到的却可能是恶意包。原文讨论的就是这样一起事件：据 Cursor 公告，2026 年 10 月 29 日，其扩展市场曾分发恶意版本 2.1.313，暴露约 11 小时，估计最多影响 5,000 名用户。

结论要划清范围：现有材料指向 Cursor 市场中的特定安装包，没有证据表明 Claude Code 官方分发渠道遭到入侵。对每天依赖编辑器和 AI 助手的程序员，这篇文章最有用的提醒是：扩展叫什么、从哪里下载，是两件需要分别核实的事。

同名扩展，为什么不能算同一个可信软件包

原文指出，早期部分报道把恶意包归到了 Open VSX，后续根据 Cursor 的说明作了修正。研究人员报告，未在 Open VSX、Microsoft Visual Studio Marketplace 和 Claude Code 的 npm 包中发现 2.1.313。

这不是无关紧要的来源纠错。编辑器可以连接不同市场和镜像，同一个扩展名称、发布者标识，可能对应不同服务实际交付的文件。市场参与了软件供应链，不能只把它当成搜索扩展的入口。

这里要区分两个问题：发布者身份回答「谁有权在这个名称下发布」，安装包完整性回答「下载到的文件是否确实来自该发布者的构建与发布流程」。前者可信，不能自动证明后者在所有下游渠道都成立。

熟悉的名字、认证标记和合理的版本号，都不能替代对安装来源的确认。

因此，调查记录只写「装过 Claude Code」远远不够，还得保存编辑器、市场、扩展 ID、版本和安装时间。原文出现的标识包括 anthropic.claude-code，受影响路径写作 Anthropic.claude-code；判断范围时，应结合完整安装记录，不能只搜索产品名。

同样，这次事件没有证明攻击者如何进入 Cursor 市场，也没有证明 Anthropic 账号、构建系统或 Claude Code 自身存在漏洞。原文引用的材料没有交代恶意包的完整来源链条，这个问题仍然悬着。

没有管理员权限，恶意扩展还能做多少事

据 Cursor 公告，恶意包在 2026 年 10 月 29 日太平洋时间约 2:27 a.m. 至 1:35 p.m. 可供下载。它尝试收集主机名、用户名、操作系统、架构、用户目录、工作目录、Git 配置邮箱、公共 IP，以及环境变量名称。

最后一项需要读准：原文写的是环境变量的名称，没有说已经收集了所有变量值。不能据此直接断言机器上的全部 Token 都已泄露。

但它的行为也远不止收集信息。该包还尝试向 authorized_keys 添加标记为 svc-telemetry 的攻击者 SSH 公钥，启用本地 SSH 服务，建立持久化机制，并打开反向隧道。反向隧道可以理解为机器主动向外建立连接，为远程访问留下通道。

Cursor 表示，启用 SSH 服务需要管理员权限，因此这一步在多数 macOS 和 Windows 机器上会失败。这个限制确实缩小了部分攻击能力，却不能抵消添加公钥、建立持久化和上报主机信息的风险。

普通用户权限也能接触大量开发资料。对于前端和全栈工作站，仓库、配置文件和日常凭据通常就在当前用户的访问范围内。原文没有给出这些资料被实际窃取的完整证据，但足以说明：不能用「我没输入管理员密码」判断扩展是否无害。

Cursor 称攻击者服务器已经离线，并已移除恶意包、审计市场、轮换密钥，暂未发现其他扩展被篡改。这些是事件处置与调查范围的信息，不能推导为所有受影响机器都已自动恢复安全。

为什么升级或卸载之后，还要查历史记录

扩展已经不在，不代表它执行过的操作已经撤销。

这也是原文最值得开发团队记住的一点。恶意代码可以把文件、任务或进程留在扩展目录之外。删除扩展，可能仍然留下 launch agent、计划任务、SSH 公钥或运行中的隧道进程。

排查应从明确范围开始：是否在上述时间窗口内，通过 Cursor 扩展市场安装或更新过 Anthropic.claude-code 2.1.313。只看今天安装的版本不够，后续更新可能已经替换可见的软件包，但此前的代码仍可能执行过。

原文介绍，Cursor 公告提供了 macOS 和 Windows 各自的检查说明与清理脚本，覆盖扩展、已知持久化机制、隧道进程和未授权公钥。svc-telemetry 是其中一项排查线索。不过，authorized_keys 检查结果为空，也不足以证明其他行为没有发生。

如果发现载荷执行或后门安装证据，就需要按安全事件处理：隔离主机、清理持久化和隧道进程、评估是否重建系统，并从可信设备轮换受影响机器能够访问的凭据与会话。

原文没有附上具体命令和脚本内容，因此这里无法复现，也不适合自行拼一套替代命令。组织环境还应按内部响应要求先保留日志和系统镜像，避免清理过程抹去调查证据。

我的判断

作者最有说服力的地方，是把「产品信任」拆到了具体分发渠道。看到标题就认定 Claude Code 全线失守，会扩大事件范围；只看到官方渠道未发现异常就忽略 Cursor 用户的风险，又会漏掉需要处理的人。按包、市场、版本和时间窗口界定范围，更有助于采取行动。

但这篇文章是基于公告和研究报告的事件解读，没有提供作者自己的恶意样本复现、独立取证，也没有不同渠道安全性的对照数据。「记录来源、保留历史、限制权限」是合理的工程建议，不能据此宣称某种编辑器或 CLI 已被证明更安全。

我也赞成对受管开发机使用扩展白名单或批准版本策略，不过它有维护成本。相比全部自动更新，版本审批能增加一道检查；审批长期停滞，也可能让安全修复迟迟无法进入。因此，原文提出的紧急更新通道不能省略。

另一个边界是证据强度。「某渠道未发现受影响版本」只描述当前调查结果，不是对该渠道永久安全的承诺。对于一般团队，更实际的目标是让安装过程可追溯、异常能被发现、执行后的影响有办法检查，而不是寻找一个永远无需核实的下载入口。

能拿来做什么

• 给团队常用编辑器扩展补一份来源记录，至少包含市场、发布者、扩展 ID、版本和安装时间。日后排查时，就能区分具体交付路径，避免只凭产品名判断影响。
• 如果团队使用 Cursor，按此次事件的版本与时间窗口检索安装历史和终端记录。即使当前已经升级，也应确认此前是否运行过 2.1.313。
• 为可读取仓库、执行 Shell、接触本地配置的扩展制定更新规则，保留版本变更日志；需要审批时，同时明确安全修复如何紧急放行。
• 把扩展安全事件的处理步骤写进团队流程，覆盖持久化、进程、网络连接、凭据轮换和系统重建评估。前端与 Node 开发工具尽量使用普通用户权限，并减少工作站上长期可用的敏感凭据。