装错一个扩展，SSH 后门就住进了电脑：Cursor 市场里的 Claude Code 投毒事件

10 月 29 日上午，如果你在 Cursor 里更新了 Claude Code 扩展，你可能装上了一个不属于 Anthropic 的版本。Cursor 当天发布的安全通告说，出现在自家扩展市场里的 Anthropic.claude-code 2.1.312 与 2.1.313（Windows 与 macOS 版）是“被恶意修改过的版本”，不是 Anthropic 开发的。它会在你的电脑上装一个持久的 SSH 后门：加一把攻击者的密钥、尝试打开反向隧道、再用定时任务让隧道一直活着。窗口大约 11 个小时，从太平洋时间早上 2 点 27 分到下午 1 点 35 分。Cursor 在 X 上称至多 5000 名用户受到影响，并表示会直接联系他们。

先把最要紧的结论说在前面：如果你是在这个窗口里、从 Cursor 的扩展市场安装或更新过这两个版本之一，不要只卸载扩展就了事。Cursor 的通告写得很直白——卸载可能不够，因为载荷会丢下独立运行的持久化脚本。你要先查 SSH 授权密钥文件里有没有一把标注为 svc-telemetry 的密钥，有，就按通告的清理脚本和隔离步骤走；没有，才能松一口气。至于从微软官方市场、Open VSX 或 npm 装 Claude Code 的用户，Cursor 的说法是“没有证据表明官方发行渠道受到影响”，Socket 对 Open VSX 与 npm 注册表的核查也指向同一个方向：2.1.313 在那两个地方没有留下发布记录。

被篡改的版本到底干了什么

按 Cursor 通告的描述，这个恶意版本在扩展正常代码之前插了一段加载器，激活后做四件事。第一，收集并上报主机与用户信息：主机名、用户名、操作系统、架构、主目录路径、环境变量名、工作目录、配置好的 Git 邮箱，以及公网 IP。注意通告写的是“环境变量名”而不是变量值——这是一个值得抠字眼的细节：光看名字还拿不到你的密钥，但它足以让攻击者判断这台机器值不值得进一步折腾，而 Cursor 也提醒，单凭这一点不能排除后续经由后门拿到凭证的可能。

第二，它尝试把一把攻击者控制的 SSH 公钥写进你的 authorized_keys 文件，公钥注释是 svc-telemetry，指纹以 SHA256:0Z6R 开头。第三，它尝试打开本地 SSH 服务，并向 134.209.82.225 打开反向 SSH 隧道。第四，它给隧道装上持久化：macOS 上是一个伪装成系统组件的 LaunchAgent（标签 com.apple.sysmond），Windows 上是一个试图以 SYSTEM 身份运行的计划任务 SysMon，外加开机启动脚本兜底；后台脚本大约每 60 秒重试一次隧道。

这里有一个关键的限定，很多人转述时会丢掉：打开本地 SSH 服务需要管理员权限，而恶意扩展在绝大多数 macOS 与 Windows 主机上并没有这个权限。Cursor 的原话是，除了“Cursor 以管理员权限启动”这类极不寻常的情况，这一步会失败，攻击者也就没法通过隧道登录进来。但这绝不等于“没事”：密钥已经写进去了，持久化已经装上了，主机信息已经发出去了。通告明确要求：不管隧道有没有连通，都要走完整的清理流程。

好消息是攻击链的另一端已经断了。Cursor 说已与托管这台服务器的云厂商合作把它下线，因此反向 Shell 与主机信息上报现在都不再可用。也就是说，这次事件的“正在进行时”已经结束，但“留下的东西”还在受影响的机器上——密钥、持久化脚本、定时任务不会因为服务器下线而自己消失。

如果你在窗口期内更新过，先做这三步

第一步，查密钥，不用等任何工具。macOS 上在终端运行 Cursor 通告给出的命令：grep -qs svc-telemetry ~/.ssh/authorized_keys，如果输出“svc-telemetry key found”，机器就是受影响的；输出“No key found”，按通告的口径就是未受影响。Windows 上用 PowerShell 同时查用户目录下的 authorized_keys 和 C:\ProgramData\ssh\administrators_authorized_keys 两个文件。只查一个文件是不够的，Windows 的管理员授权密钥可能落在第二个位置。

第二步，如果查到了，先隔离再清理。通告的顺序值得照抄：隔离出现载荷执行或后门安装证据的主机；用官方清理脚本删掉恶意扩展、持久化机制、正在运行的隧道进程和攻击者密钥；macOS 的 remediate-macos.sh 要以受影响用户身份运行、不要用 root，Windows 的 remediate-windows.ps1 要用管理员身份打开的 PowerShell 运行。脚本会在还有残留时以非零状态退出——把它当成验收标准，而不是走个过场。

第三步，从一台可信的机器上轮换这台主机能接触到的凭证与会话。通告特意提醒，环境变量收集范围有限“不排除之后经由后门接触凭证”。换句话说，查密钥只是确认有没有中招，不是确认损失边界。个人开发者至少要轮换 Git 托管与云厂商的 token、重新登录关键服务；团队则要把这台机器当作一次正式的安全事件来处理，并评估是不是该重装系统。Cursor 的措辞是“评估主机是否应当重建”，对存有生产密钥的机器，我的判断是直接重建，别纠结。

还有一步容易被忽略：确认你现在装的是干净的版本。Anthropic 已发布 2.1.314，公开的发布记录直接从 2.1.312 跳到 2.1.314，中间没有 2.1.313 这一项。升级到 2.1.314 之前，先按上面的方法确认旧残留已经清掉——否则新版本装上去，旧的持久化脚本还在后台每分钟重试隧道。

最初的报道为什么指错了地方

这起事件还有一条值得单独讲的传播线。最早的安全分析把恶意版本指向了 Open VSX——那个 VS Code 官方市场之外的开源扩展 registry，Cursor、Windsurf 这类基于开源 VS Code 的编辑器正是依赖它或自建市场。随后 Socket 的核查给出了相反的证据：他们检查了 Open VSX 从 10 月 27 日到 30 日的 3392 条 registry 变更事件，里面有 2.1.312 与 2.1.314 全部八个平台构建的上线记录，却没有任何一条关于 2.1.313 的发布或删除记录；npm 上 @anthropic-ai/claude-code 的版本与发布时间记录同样跳过了 2.1.313（2.1.312 是 10 月 27 日 18:36 UTC，2.1.314 是 10 月 30 日 00:12 UTC）。Open VSX 的变更历史按设计是追加式的，即使是短暂上架又删除的版本也该留下痕迹——同一窗口里另外 21 个扩展的 42 个版本被删后都留下了记录，其中一个只活了约 90 秒。

所以更准确的叙述是：恶意版本经由 Cursor 自家的扩展市场分发，而非 Open VSX 或 npm 的官方发行渠道。Cursor 的通告也正是这么定的：问题出在“Cursor VS Code Extension Marketplace”，且“没有证据表明其他版本或官方发行渠道受到影响”。最初那篇分析后来也做了大幅修订，不再把 Open VSX 写成受影响渠道。这条纠偏本身就是教训：在安全事件的前几个小时，二手转述的渠道名最容易出错，而对普通用户来说，渠道名恰恰决定了“我要不要自查”——写错一个名字，就会让一批真正该查的人安心、让另一批不该慌的人白忙。

还有一个至今没有答案的问题：一个顶着 Anthropic 官方扩展 ID（anthropic.claude-code）的篡改包，是怎么进到 Cursor 市场里的？Cursor 的通告讲了处置——立即下架、封堵继续分发、整个市场预防性关闭、审计确认没有其他扩展被动过、轮换密钥、重建市场后恢复上线——但没有解释这个包的发布路径。Anthropic 技术员工在社交媒体上的表态是，这不是 Anthropic 自身系统或员工笔记本被攻破。在官方解释出来之前，任何关于“内鬼”或“市场审核漏洞”的说法都只是猜测，本文不采纳。

对 vibe coder 来说，真正的教训不在这一个扩展

把视线拉远一点：这不是 10 月第一起“编辑器信任边界”事件。就在几天前，同一批 AI 编程工具还曝出过内嵌浏览器被当成真浏览器利用的问题。两件事拼在一起，指向同一个现实——vibe coding 把大量信任交给了编辑器与扩展：它们能读你的代码、跑你的终端、碰你的 SSH 配置。过去我们评估一个扩展只看“好不好用”，现在必须多看一眼“它能碰到什么”。

对个人开发者，我建议把这次事件沉淀成三条固定动作。第一，扩展更新别开全自动放任自流，至少对 Claude Code 这类高权限扩展，留意版本号的跳变：公开记录里 2.1.312 之后直接是 2.1.314，任何自称 2.1.313 的构建都值得先怀疑。第二，定期看一眼 ~/.ssh/authorized_keys——这条命令 10 秒就能跑完，却是这次事件里最有效的自查手段，值得放进你的月度检查清单。第三，写代码的机器与存生产密钥的机器尽量分开权限：这次载荷恰恰因为缺管理员权限而没能把隧道走通，权限分层在真实事件里立了功。

对团队来说，这次事件是一个现成的演练素材：你们能不能在一小时内回答“团队里谁在窗口期内从 Cursor 市场更新过 Claude Code”？如果答不上来，缺的不是一次通告阅读，而是一份扩展安装台账与统一的版本基线。把高权限扩展的版本钉在一个已知干净的号上，比事后逐台 grep 要便宜得多。

最后说一句分寸感的话。这起事件的实际破坏被两道偶然防住了：载荷自身的权限缺陷，以及攻击服务器被迅速下线。至多 5000 名用户这个数字是“装过恶意构建的人数上限”，不是“被成功入侵的机器数”——Cursor 没有公布后者，任何把它说成“5000 台机器被黑”的标题都是夸大。但反过来，把它说成“虚惊一场”同样不对：密钥与持久化是实打实装到机器上的东西，服务器下线只断了遥控，没清掉留守。正确的心态是按通告走完自查，该清理的清理，该轮换的轮换，然后把扩展供应链放进你日常的安全清单里。

为什么是 Cursor 的市场，而不是微软的市场

要理解这次事件的渠道之争，得先讲清楚 VS Code 扩展市场的三角关系。微软的 Visual Studio Marketplace 按使用条款只服务于微软自家的产品，基于开源 VS Code 代码库做的编辑器——Cursor、Windsurf 都在这个范围里——不能直接用它。于是出现两条路：用 Eclipse 基金会运营的开源 registry Open VSX，或者像 Cursor 这样自建市场。日常使用中，这两条路对用户来说几乎没有差别：你点一下“安装”，扩展就装上了，背后的 registry 是谁并不显眼。但出事之后，差别立刻显现：你得先搞清楚自己是从哪个市场装的，才能判断自己在不在影响范围里。

这正是最初报道指错渠道危害最大的地方。很多 Cursor 用户同时也装着 VS Code，或者在不同机器上混用两个编辑器，看到“Open VSX 出问题”的标题，第一反应可能是去查 VS Code 那边的扩展——查完没事就安心了，而真正该查的 Cursor 市场反而被跳过。Socket 的核查之所以有价值，不只是纠正了一个名字，而是把自查范围重新钉回了正确的地方：Cursor 市场、2.1.312 与 2.1.313 两个版本、10 月 29 日太平洋时间 2 点 27 分到下午 1 点 35 分这个窗口。三个条件同时满足，才需要走清理流程；缺一个，就不在影响范围里。

这也引出一个更深的问题：自建市场的审核责任在谁手里。微软市场有微软的审核流程，Open VSX 有基金会的治理，而 Cursor 的市场由 Cursor 自己运营。当一个顶着 Anthropic 官方 ID 的包出现在 Cursor 市场里，用户没有任何简单办法从客户端分辨真假——扩展详情页显示的发布者标识正是攻击者冒用的那个。客户端能做的核验其实非常有限：版本号在官方发布记录里是否存在，是一条；但用户不可能每次更新都去翻 GitHub 发布页比对。真正能兜底的，是市场一侧的签名与发布者身份校验：只有持有 Anthropic 发布凭证的提交才能以 anthropic.claude-code 的名义上架。Cursor 的通告说“轮换了密钥、重建了市场”，这句话暗示了问题可能出在市场一侧的凭证或流程上，但通告没有明说，本文也不替它补全这个推断。用户能做的，是等官方的事后分析，而不是猜。

对 vibe coder 来说，这个三角关系还有一层现实意义：你很可能同时是多个市场的用户。同一台机器上，VS Code 里装一个版本的 Claude Code，Cursor 里装另一个版本，CLI 里再跑一个 npm 装的版本——三个分发渠道，三套更新节奏。建议你给自己定一条简单规则：高权限的编程助手扩展，只从一个渠道装、只跟一个更新源；如果必须在多个编辑器里用，至少记下来每个编辑器里的版本号来自哪个市场。出事时，这张清单能帮你把自查范围从“所有机器”缩小到“某几台机器的某个市场”。

给团队的 24 小时处置清单

如果你是团队里负责安全或工程效能的人，可以把下面这份清单直接当作事件响应模板。它的时间起点不是“看到新闻”，而是“确认团队有人在窗口期内更新过”。第 0 到 1 小时：发一条内部通知，写清三个条件——Cursor 市场、2.1.312 或 2.1.313、10 月 29 日太平洋时间 2 点 27 分到下午 1 点 35 分——让每个人先自查 authorized_keys，而不是先卸载扩展。卸载会删掉证据，也删不掉持久化脚本，顺序错了反而添乱。

第 1 到 4 小时：收集自查结果，分成三类建表。第一类是命中 svc-telemetry 密钥的机器，立即隔离、走官方清理脚本、评估重建；第二类是在窗口期内更新过但没命中密钥的机器，同样跑一遍清理脚本并检查持久化位置（macOS 的 LaunchAgents 里的 com.apple.sysmond、Windows 的 SysMon 计划任务与开机启动脚本），因为通告的持久化清单比一把密钥更长；第三类是没在窗口期内更新的机器，记录版本号、不用处理。分类的意义在于，别让“没命中密钥”直接等于“没事”——通告的指标清单里，文件、进程命令行、网络信标都是独立的证据点。

第 4 到 24 小时：做三件收尾的事。一是轮换：所有命中机器能接触到的凭证与会话，从可信机器上轮换一遍，包括 Git 托管 token、云厂商密钥、内部系统会话。二是定基线：把团队内 Claude Code 扩展的版本统一钉到 2.1.314，并记录这次事件的三个版本号——2.1.312、2.1.313、2.1.314——写进内部知识库，注明 2.1.313 不存在于官方发布记录，今后任何自称这个版本的构建都先当作可疑。三是复盘市场信任：评估团队是否需要对高权限扩展启用统一管理——比如只允许从固定渠道安装、禁止个人随意更新大版本，或者至少做到“谁装了什么版本”可查询。这次事件里最贵的不是清理本身，而是“不知道谁装过”带来的不确定性。

个人开发者可以把这份清单缩成一句话版本：查密钥、跑脚本、换凭证、钉版本。四件事做完，这次事件对你就结束了。不要做的事也有三件：不要只卸载扩展就宣称处理完毕；不要从非官方渠道下载所谓“干净版”覆盖安装；不要在没隔离的情况下继续用命中机器提交代码或访问生产环境。

这次投毒和以往的 npm 投毒有什么不同

过去几年，JavaScript 生态的供应链事件大多发生在包 registry 层面：某个流行包的维护者账号被盗，或者某个新包冒充知名包的名字（typosquatting），开发者在 npm install 时把恶意代码拉进项目。防御思路也相对成熟：锁版本、审依赖、跑 SCA 扫描。Cursor 这次事件的攻击面不一样：它不在你的项目依赖里，而在你的编辑器里；你不是在安装某个库时中招，而是在更新一个你每天都在用的官方工具时中招。

权限级别也不一样。项目依赖里的恶意代码通常只能在项目目录和构建流程里折腾，拿到的是你跑构建时的用户权限；而编辑器扩展天生就被授予了读代码、跑终端、改配置的权限，Claude Code 这类编程助手扩展的权限尤其大。恶意版本瞄准的正是这个位置：SSH 授权密钥文件、持久化任务、反向隧道，这些都不是普通依赖包会去碰的东西。换句话说，攻击者选的不是“最容易进来的门”，而是“进来之后站得最高的地方”。

还有一个区别值得注意：这次事件的载荷有明显的“半成品”特征。隧道步骤因为缺管理员权限在大多数机器上失败，持久化却用了相当系统化的手法（LaunchAgent 伪装、SYSTEM 计划任务、开机脚本兜底、60 秒重试）。这种“部分成功”的形态，恰好说明了为什么不能只看“有没有被远程登录”来定性损失。主机信息已经外泄，密钥已经写入，持久化已经就位——即使远程登录没走通，攻击者也已经拿到了“下次再来”的立足点。服务器下线断的是遥控，不是立足点本身。理解这一点，才能理解 Cursor 为什么坚持要求所有窗口期用户走完整清理流程，而不是只让“确认被登录过”的人处理。

来源说明：本文核心事实来自 Cursor 官方安全通告（事件窗口、载荷行为、指标与清理步骤均按通告原文）；至多 5000 名用户、市场重建上线等说法来自 Cursor 在 X 上的声明及 Socket、The Hacker News 等二手报道的转述；Open VSX 与 npm 无 2.1.313 记录的核查来自 Socket 的公开分析。Cursor 尚未解释篡改包进入其市场的路径，本文对此不做推测。