10 月 29 日，一款披着官方外衣的恶意更新悄悄出现在 Cursor 的 VS Code 扩展市场：Anthropic.claude-code 的 2.1.312 与 2.1.313 两个版本被掺入恶意代码，尝试在开发者机器上植入持久化的 SSH 后门。这两个版本并非 Anthropic 开发，却在约 11 个小时的窗口里以正常更新的身份推送给用户，开了自动更新的开发者几乎无感中招。Cursor 官方给出的影响口径是最多 5000 名用户，并表示会直接联系受影响者。这件事为什么值得每个用 AI 编程工具的人关注，下面按官方通告把来龙去脉捋一遍。
假更新怎么混进 Cursor 扩展市场的
时间线很紧凑。太平洋时间 10 月 29 日凌晨 2:27 到下午 1:35，被篡改的 Claude Code 扩展在 Cursor 的扩展市场上架，覆盖 Windows 与 macOS 两个平台。它不是又一个高仿的「李鬼」扩展，而是直接顶着 anthropic.claude-code 这个官方扩展 ID 与版本号发布的更新——对开发者来说，这与日常的版本迭代看不出任何区别。
海外安全研究团队的分析显示，恶意载荷是一段约 66 行的加载器代码，被插在正常扩展代码的最前面，扩展一加载就会执行，不需要打开任何对话窗口，也没有任何需要用户确认的提示。安全公司 Phorion 的研究人员随后在终端上发现异常并拉响警报。至于攻击者究竟通过什么途径拿到了官方发布通道的权限，目前各方都没有给出定论，Cursor 只确认这是一次波及其市场系统的安全事件，并强调恶意版本不是 Anthropic 开发的。
后门手法拆解：先摸底，再埋钥匙
按 Cursor 官方通告的描述，这段恶意代码分三步走。第一步是摸底：收集主机名、用户名、操作系统、架构、主目录路径、工作目录、Git 邮箱和公网 IP，外加最多 40 个名称里带 KEY、TOKEN、SECRET、PASS、AWS、GCP 字样的环境变量名，通过 HTTP POST 上报到攻击者服务器的 8099 端口。注意它只拿走变量名而不是值，但研究者提醒，这份清单本身就已经暴露了机器上配置了哪些云厂商和凭据类型，等于替攻击者做了一份「回访名单」。
第二步是埋钥匙：往 ~/.ssh/authorized_keys 里追加一个标签为 svc-telemetry 的 SSH 公钥——这个名字伪装成遥测服务，肉眼很不容易起疑。第三步是挖隧道并持久化：尝试开启本地 SSH 服务，建立反向 SSH 隧道连回 134.209.82.225，之后每隔约 60 秒重试一次；同时在 macOS 上注册名为 com.apple.sysmond 的 LaunchAgent，在 Windows 上创建尝试以 SYSTEM 权限运行的 SysMon 计划任务并用启动脚本兜底，让隧道在重启后依然活着。
为什么多数机器躲过了最坏结果
这里有个颇具戏剧性的细节：开启本地 SSH 服务需要管理员权限，而恶意扩展在绝大多数 macOS 和 Windows 主机上并没有这个权限，加上恶意代码本身存在错误，反向隧道这一步在大多数机器上其实是失败的。Cursor 也已联合云服务商把攻击者服务器下线，反向 shell 与信息上报通道都已失效。
但官方同时强调，别因为隧道没建成就当无事发生——攻击者的 SSH 公钥、持久化机制和摸底数据上报，这些都已经发生了。研究者还指出一个隐患：如果机器本来就开着远程登录，或者之后出于任何原因打开了 SSH 服务，那把埋好的钥匙仍然躺在 authorized_keys 里等着被用。所以官方的建议是，只要装过这两个版本，无论隧道有没有建成，都按受影响机器来处置。
影响范围：最多 5000 名开发者的口径从哪来
5000 这个数字来自 Cursor 官方通告，指的是在 10 月 29 日那个时间窗口内安装或更新到恶意版本的用户上限，官方称会直接联系受影响用户。海外科技媒体报道称，目前没有证据显示恶意构建波及 Open VSX 或微软官方市场，Anthropic 也已将干净的 2.1.314 版本发布到这两个渠道。
值得留意的是，Claude Code 扩展的装机量以千万计，5000 这个数相对来说不算大，但这恰恰说明下架和拦截动作够快——从上架到移除只有约 11 个小时。海外安全研究者的提醒更直白：任何开了自动更新的 Claude Code 实例，都可能在这段时间里默默拉取过恶意版本。目前还没有观察到第二阶段载荷，但反向隧道本身就是一条现成的通道，后续利用的空间不能排除。
开发者怎么自查和处置
自查很简单，官方给了一条命令级的判断方法：检查 authorized_keys 里有没有 svc-telemetry 字样。macOS 上在终端执行 grep -qs svc-telemetry ~/.ssh/authorized_keys，Windows 上用 PowerShell 检查用户目录下的 .ssh\authorized_keys 和 C:\ProgramData\ssh\administrators_authorized_keys 两个文件。
如果命中，就要按官方流程处置：隔离主机，删除未授权密钥、持久化机制和隧道进程，再评估是否需要重装系统。这里有个关键提醒——卸载扩展并不等于清除后门，因为恶意载荷丢下的持久化脚本是独立运行的，编辑器关了它还在。此外，应当从一台可信的干净设备出发，轮换那台机器能接触到的所有凭据和会话，包括 Git、云平台和 CI 令牌。官方为两个平台各准备了一个修复脚本，跑完后若有残留会以非零状态退出。确认没中招的，把扩展更新到 2.1.314 或更高版本即可。
网友评论
- 「公司电脑全开着自动更新，明早安全团队又要全员加班排查了，这种供应链攻击是真的防不住啊。」
- 「刚 grep 了一下没有 svc-telemetry，悬着的心放下了，不过 Git 邮箱和公网 IP 多半是发出去了，想想还是不舒服。」
- 「顶着官方 ID 发恶意更新，这已经不是高仿号的事了，是发布通道本身被人撬了，市场方得给个交代。」
- 「问个小白问题：只装了官方 VS Code 市场版的是不是就没事？报道说没波及，但保险起见更新前还是先自查一遍。」
总结
这起事件真正值得警惕的地方，不在某一段恶意代码写得多刁钻，而在信任链条本身被撬动。开发者对扩展市场的默认假设是：官方 ID 加自动更新等于安全。当发布通道被入侵，这两个假设同时失效——AI 编程工具又恰恰握着源代码、云凭据和 CI 管线这些最值钱的入口。就在这次事件前几天，海外还曝出云服务商 OVHcloud 官方 CLI 的旧版本文件被人替换成窃密程序的同类操作，针对开发工具链的供应链攻击明显在升温。
对个人开发者，养成「敏感环境关掉自动更新、装完更新看一眼 authorized_keys」的习惯不亏；对团队，把扩展当成依赖来管理——锁定版本、校验来源、对密钥文件变更做告警，这些老办法在 AI 时代一点都没过时。工具越聪明，入口越要守好。
