5000人装了带后门的官方Claude Code扩展

10 月 29 日，太平洋时间凌晨 2:27 到下午 1:35，Cursor 插件市场里那个 Claude Code 官方扩展，多了一段 66 行的代码，装进去的人最多有 5000 个。

那段代码不弹窗，也不偷文件，它只做一件事：给一台陌生服务器配一把能反复进门的钥匙。

受影响时间窗：10 月 29 日 02:27 至 13:35（太平洋时间）

事情在 10 月 30 日下午被捅出来。安在市场里的 anthropic.claude-code 标着 2.1.313，图标、发布者、更新说明都和正版一样，被改的是包里多出来的那 66 行。溯源结果是市场本身被入侵，Cursor 短暂关停了扩展市场，Anthropic 随后在 Open VSX 和微软市场放出 2.1.314。

打开插件的那一下，钥匙就配好了

这个扩展会在两个时刻自动激活：VS Code 启动时，以及它自己的侧边面板被打开时。激活后的第一件事，是往用户主目录的 ~/.ssh/authorized_keys 追加一行公钥，注释写成 svc-telemetry，看上去像一条遥测配置。谁拿着对应私钥，谁就能凭这行登进这台机器，不需要密码。

接着它去开 SSH 服务，Windows、Linux、macOS 各有各的路径，开完再朝 134.209.82.225 建一条反向隧道。三个系统续命的方式也不同：Windows 写计划任务，Linux 改 crontab，macOS 装 LaunchAgent，重启也不掉。

它还会整理一份主机画像带走：公网 IP、主机名、用户名、系统版本与 CPU 架构、用户目录、git 全局邮箱，以及最多 40 个名字里带 KEY、TOKEN、SECRET 的环境变量。数据走未加密 HTTP，发到 8099 端口。

参与分析的研究员说了句关键的：第一次回连不带变量的值，可变量名本身就说明了这台机器接的是哪家云、哪套 CI，隧道一通，值也不用问了。

大多数机器没被真正接管，但"没被接管"不等于没事

Cursor 自己的分析里有个限定：开本地 SSH 服务要管理员权限，多数 macOS 和 Windows 主机上恶意扩展没拿到，隧道那一步会失败。听到这里容易松一口气。

可失败之前该发生的都发生了。公钥进了 authorized_keys，持久化装上了，主机信息也发走了。攻击者今天进不来，不代表锁没被换过；哪天这台机器上有人用管理员权限装了别的东西，那条隧道就能立起来。

在这段时间窗内装过或更新过这个扩展的开发机，可以按四步处置：断网隔离；打开 ~/.ssh/authorized_keys 删掉不是自己人的公钥；翻计划任务、crontab、LaunchAgent 清陌生条目；把在这台机器上登录过的凭据、token 和会话全换一遍。这套流程对开发笔记本够用，对跑着共享凭据的跳板机不够。

真正的缺口在扩展市场那一头

这条链上松了两处：上架审核没拦住被改过的包，客户端又默认开着自动更新。开发者核对的东西全对，唯一不对劲的就是包里那 66 行。

一周多以前同样的手法落在 OVHcloud 身上，有人劫持了一名贡献者的 GitHub 账号，把官方 CLI 五个已发布版本的二进制换成了窃密程序。两次都不用伪造品牌，改的是合法渠道发出去的那个产物。

也得划清一条界线：这次的事跟 Claude Code 的能力、权限设计没什么关系，出问题的是分发环节。

两个容易看错的判断

第一个：官方出的扩展总比第三方安全。这话有道理，官方账号、官方仓库、官方版本号确实比来路不明强一截；可它解释不了这次的事，恶意版本根本不是 Anthropic 开发的。更该验的是这个包由谁构建、有没有签名、装上去的版本对不对得上。

第二个：我没开 SSH，装了也无所谓。前半句常常成立，多数机器确实没跑起 SSH 服务；但它解释不了一个已经发生的事实，公钥已经进了 authorized_keys。判断标准要换成这台机器的 authorized_keys 里有没有多出陌生条目。

插件市场的审核速度，和 AI 编程工具的更新频率，眼下是两条不同速度的流水线，前者还得靠人一条条看。这两天真在 Cursor 里更新过 Claude Code 的话，今晚花十分钟翻一遍 authorized_keys，比转发这篇文章管用；翻完把上面四步丢给同组用 Cursor 的人。

作者提示含AI生成内容。作者声明本文无利益相关，欢迎值友理性交流，和谐讨论～