官方插件被投毒：装了这版 Claude Code 的，现在去查

10 月 30 日，安全公司 Phorion 披露了一起供应链投毒：Cursor 市场上的「官方 Claude Code for VS Code」扩展，有两个版本的安装包被植入后门，装完会在你的机器上开一个持久的 SSH 入口。

受影响的是 2.1.312 和 2.1.313。Cursor 已经把这俩版本从市场下架，Phorion 在 10 月 31 日又更新了一次公告，把 2.1.312 补进了范围。

时间线也值得记一笔：10 月 30 日 05:30 UTC 首次发布，09:13 把受影响的市场从「VS Code」修正为「Cursor」，10 月 31 日 00:43 又把 2.1.312 补进受影响版本。三个修正说明一件事——事件初期连安全公司都会搞错范围，你从群里转发的截图里看到的版本号，未必是全的。如果你装过这个扩展，先别急着关页面，下面有五分钟能跑完的自查。

它是怎么进来的

关键点在于：这不是有人伪造了一个同名插件，是官方扩展的包里被塞了东西。

攻击者在 extension.js 的最前面插了一段立即执行函数，比扩展本身的 activate 还早跑。也就是说，你打开编辑器、扩展加载的那一瞬间，代码就执行了——你不需要点任何按钮，也不需要真的用它写代码。

扩展在 IDE 里是以你的权限运行的。这意味着它一加载，就能读你的源码、配置文件、SSH 目录，能起子进程，能联网。Phorion 在报告里写得很直白：扩展拿到的是 IDE 和用户的全部权限。

它到底做了什么

整个过程分四步，每一步都很「脚本小子」，但组合起来很致命。

第一步，往 ~/.ssh/authorized_keys 里追加一把攻击者的 Ed25519 公钥，注释写着 svc-telemetry。有了这把钥匙，对方就能以你的身份登录这台机器。

第二步，从内嵌的私钥连出去，建一条反向 SSH 隧道到 134.209.82.225，把对方服务器上的某个端口转发到你本地的 22 端口。之后他连自己的服务器，就能落到你的机器上，拿到一个完整 shell。

第三步，做持久化。macOS 上写一个伪装成系统组件的 LaunchAgent（com.apple.sysmond.plist），指向 ~/.config/.smt；Linux 上往 crontab 塞 @reboot；Windows 上尝试建一个叫 SysMon 的计划任务，失败就丢进启动文件夹。

第四步，回传主机信息：主机名、用户名、系统、当前目录、git 全局邮箱、公网 IP，以及最多 40 个环境变量的名字——只拿名字不拿值，用来判断你机器上有哪些云凭据值得下手。

（判断）这不是偷一次数据就跑的脚本，是给你留了一扇长期的门。

为什么选编辑器扩展？因为它是开发者机器上权限最高、审查最少、更新最自动的一类软件。它随 IDE 启动，能读整个工作区，能起进程，能联网；而绝大多数人对它的信任，来自「它在官方市场里」。这次的事说明，市场本身也会被绕过。

一个乌龙，但不能当护身符

报告里有个细节挺有意思：在 macOS 上，这段恶意代码其实有个 bug。

它想检查「远程登录」开没开，用的是 systemsetup -getremotelogin，但没加 sudo。普通用户跑这条命令，系统会回一句「需要管理员权限」然后正常退出；脚本判断输出里有没有 Off，结果没匹配上，就以为「已经是开的」，于是跳过了启用 SSH 那一步。

所以如果你本来就没开远程登录，它的入站路径其实是断的——隧道能连出去，但对方连回来会撞在关闭的 22 端口上。

另外两个平台也有各自的问题：Linux 走 systemctl，失败后回退到 service 和 init.d；Windows 想用 PowerShell 装 OpenSSH Server，但把命令交给了一个写死 /bin/sh 的辅助函数——在标准 Windows 上基本跑不通。跨平台写得越急，破绽越多。

但这只能算运气。公钥已经写进去了，持久化也已经装上了；你哪天开了远程登录，或者用了一台本来就开着 SSH 的机器，这扇门就是通的。Phorion 自己也是这么说的：不要把这个 bug 当防御。

五分钟自查

这次能被发现，靠的是端点安全产品在文件层看到「IDE 的辅助进程在改 authorized_keys」——正常开发时不会发生这件事。沙箱、云 IDE 这类隔离环境天然风险更低，因为它们通常没有你的 SSH 目录，也没有你本机的凭据。

先看版本。在 Cursor 或 VS Code 的扩展面板里找到 Claude Code，看版本号；是 2.1.312 或 2.1.313，就按下面的步骤处理。已经升级到更新版本的，风险大幅下降，但仍建议查一遍下面三项——因为你不知道它是什么时候被装上的。

查公钥：grep -n "svc-telemetry" ~/.ssh/authorized_keys。有输出就是中招了，把那一行删掉，并且立刻换掉你自己所有的密钥。

查持久化：ls ~/Library/LaunchAgents | grep -i sysmond（macOS）、crontab -l | grep -i smt（Linux）、任务计划里找 SysMon（Windows）。再顺手看一眼 ~/.config/.smt 和 ~/.config/.smtk 这两个文件在不在。

查外连：lsof -i | grep 134.209.82 或者 netstat -an | grep 134.209.82。这条能看到当前有没有活的隧道。

中招了怎么办

顺序很重要：先断网，再删东西，最后换凭据。

断网是为了不让隧道继续连着；删掉 authorized_keys 里那行、删掉 LaunchAgent 或 crontab 条目、删掉 .smt/.smtk，是切断持久化；最后一步是把你机器上用过的密钥、token、云凭据全部轮换——因为对方已经拿到了你环境变量的清单，知道该试哪些。

如果你的机器上跑着生产环境的凭据，做完上面这些之后，建议再检查一遍云侧的访问日志，看有没有异常来源的登录。

团队层面，我更建议把扩展当成依赖来管：固定版本、关掉自动更新、升级前看一眼发布说明；对能读文件、能起进程的扩展，默认按「它可能是恶意的」来配权限，比如把敏感凭据放在它读不到的地方。这些做法不酷，但它们是唯一能缩短暴露窗口的东西。

没装过这个扩展的人，也别把这篇当新闻看。同样的手法可以套在任何「能读文件、能起进程」的插件上——翻译插件、主题、格式化工具，只要它在你机器上跑，就有这个能力。区别只是这次被公开了。

能做的其实只有三件小事：装之前看一眼发布者和版本历史；装之后定期清一遍不用的扩展；把「这台机器上有哪些凭据」当成一个需要定期盘点的清单。

最后

这件事真正值得记住的，不是某个版本号，而是它暴露的攻击面：AI 工具的生态，正在变成新的供应链入口。

以前我们担心的是 npm 包、Docker 镜像、CI 脚本；现在多了一类——编辑器扩展。它比 npm 包更隐蔽，因为你会主动装一个「官方」扩展，然后默认它是安全的这里有个常被误解的点：市场里的「官方」标识，认证的是发布者账号，不是这一次上传的包内容。账号被盗、构建流水线被污染、或者内部有人动了发布脚本，都能让一个「官方扩展」变成投毒载体，而你在界面上看不出任何区别。安装量和评论也帮不上忙——它们只能说明过去是好的。；它也比 CI 脚本更危险，因为它跑在你自己的电脑上，带着你的全部权限。

对团队来说，处置还要多一步：排查范围。一个人装了，可能整个组都装了；装过的机器，凭据都要当作已泄露处理。Phorion 的报告里提到一个检测难点——恶意代码是直接用 Node 的文件 API 往 authorized_keys 里追加的，只监控 shell 命令的规则抓不到，得看文件修改事件。这也是为什么事后排查比事前拦截更现实。

（判断）AI 工具装得越多，你的信任边界就越长

个人用户也别觉得「我不值得被攻击」。这类后门是批量撒网，不是定向；脚本只看你有没有可用的凭据，不看你是谁。真正该问的不是「会不会盯上我」，而是「我中招之后多久能发现」。，而边界上最薄的一环，往往是一个你没看过的安装包。

所以下次装扩展前，多花十秒看一眼版本号和发布者；发现官方渠道有异常，先停用再查，不要等公告。