Cursor 插件被投毒：Claude Code 后门自查与清理步骤

10 月 29 日，Cursor 扩展市场里的 Claude Code 有两个版本被植入 SSH 后门，存续约 11 小时，最多 5000 人可能拿到恶意构建。11 月 13 日 Cursor 公布了完整调查：源头是服务商泄露的一把密钥。如果你在那天装过 2.1.312 或 2.1.313，卸载插件清不干净——后门留在 SSH 公钥和开机启动项里。

事件链：一把密钥怎么变成你机器上的后门

按 Cursor 11 月 13 日的调查，链条是这样的：

1. 供应商泄露密钥。Fireworks 是 Cursor 的推理服务商，Cursor 给它签发过一把访问密钥，这把密钥被泄露了。
2. 只读存储桶被复制。攻击者用密钥读走了桶里的 Coding Agent 运行轨迹，主要是 2025 年、未开启隐私模式的会话。
3. 轨迹里有没脱敏的凭证。少量记录带着明文 API 凭证。Cursor 称涉及不到 0.01% 的客户。
4. 横向进入内部工具。用这些凭证，攻击者摸到了 Cursor 的部分 SaaS 工具，拿到归档的非生产代码、客服邮件、部分对话摘要，以及用户曾经发给客服的凭证。
5. 篡改市场缓存。10 月 29 日，攻击者用偷来的内部凭证，直接把改动过的 Claude Code 塞进扩展市场的缓存，版本号 2.1.312 和 2.1.313。

几个边界值得记住：Anthropic 没有发布这两个包，它的系统也没被入侵；Open VSX、VS Code 官方市场、npm 上的 @anthropic-ai/claude-code 都不在影响范围。受影响的只有从 Cursor 市场拿到那两个缓存版本的用户。

恶意代码干了什么？加载时收集主机名、用户名、系统版本、架构、家目录、工作目录、环境变量名、Git 配置的邮箱和公网 IP，然后尝试往 authorized_keys 追加一个标签为 svc-telemetry 的 SSH 公钥，开启 SSH 服务并挂一条反向隧道。

持久化方式分两套：macOS 写 LaunchAgent 保证重启后复活，Windows 建计划任务，后台脚本大约每 60 秒重试一次。

有两点降低了实际危害：攻击者的服务器已被云厂商下线，隧道连不回去；开启 SSH 服务需要管理员权限，加上恶意代码自身也有缺陷，多数机器上这一步直接失败了。但公钥已经追加、启动项已经写入、主机信息已经采集——这些操作在失败之前就完成了。

Cursor 的原话是：无论如何都要按下面的步骤处理。

确认机器有没有中招

第零步：先看版本号

绝大多数人停在下面这张表的第一行，不用跑任何脚本。

查版本最直接的办法：Cursor 里打开扩展面板，搜 Claude Code，看版本号。命令行也可以：

cursor --list-extensions --show-versions | grep -i claude

版本低于 2.1.312，或已经是 2.1.314 及以上，都不在这次投毒的包范围内。

但升级不等于清理——升级只换了插件文件，之前写进系统的公钥和启动项不会自己消失。所以只要在窗口期装过那两个版本，后面的检查照样要做。

第一步：查 SSH 公钥（最关键）

macOS / Linux 终端：

grep -qs svc-telemetry ~/.ssh/authorized_keys && echo "发现 svc-telemetry 公钥" || echo "未发现"

Windows PowerShell：

Select-String -Path "$HOME\.ssh\authorized_keys","C:\ProgramData\ssh\administrators_authorized_keys" -Pattern "svc-telemetry"

这一步之所以最重要，是因为它是唯一"卸载插件也不走"的东西。公钥一旦进了 authorized_keys，对方就能用对应私钥直接登录，跟插件在不在没关系。

第二步：查持久化

macOS：

ls -l ~/Library/LaunchAgents/com.apple.sysmond.plist ~/.config/.smt ~/.config/.smtk

Linux 还要多看一行 cron：

crontab -l | grep -F .smt
ls -l /tmp/.stk_* ~/.config/.smt ~/.config/.smtk 2>/dev/null

Windows（管理员 PowerShell）：

Get-ScheduledTask -TaskName SysMon | Select-Object -ExpandProperty Actions

这些路径全部来自 Cursor 官方公告的 IOC 清单，不是猜的。文件不存在会报"找不到"，那就是没有。

第三步：查隧道进程

ps aux | grep -E "autossh|ssh -N -R" | grep -v grep

正常情况下应该没有输出（除非你自己就在跑反向隧道）。官方公布的命令行特征包含 ssh -N -R '*:0:localhost:22' 和 autossh -M 0。有输出的话，先记下 PID 和命令行，别急着 kill——那是证据。

第四步：翻网络日志

官方公布的攻击者地址是 134.209.82.225，反向隧道走 TCP 22，外联信标是 8099 端口的 HTTP POST。如果你有防火墙或代理日志，把 10 月 29 日的记录筛一遍这个 IP，比只看当前文件状态更可靠——文件可以被删，日志不会。

结果怎么读

中招之后：按这个顺序清理

顺序不能乱。先删证据再想排查，等于把现场毁了。

1. 留证。 把 authorized_keys、plist 或计划任务定义、.smt 系列脚本复制到移动盘或另一台机器。后面要查"它什么时候进来的、还动了什么"，全靠这些。

2. 断网。 拔网线或关 Wi-Fi。服务器虽然下线了，但阻断比观望便宜。

3. 删公钥，只删那一行。 打开 authorized_keys，找到含 svc-telemetry 的那一行删掉，其它公钥保留。整文件清空会让你自己和其他服务一起登不上。删除前建议先比对官方公布的指纹 SHA256:0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk，确认删的是攻击者的那把，别误删你自己的 ed25519 公钥。

4. 删持久化。 macOS 先 launchctl unload 再删 plist；Windows 用 Unregister-ScheduledTask -TaskName SysMon，再清 sysmon.cmd、smt.cmd、smtk 这几个文件。

5. 结束隧道进程。 按第 3 步记下的 PID 处理，然后重启，重启后再跑一遍第一步的命令确认没复活。

6. 判断要不要重装。 这台机器上有生产环境密钥、客户数据、支付或财务权限，直接重装。判断标准不是"我清干净了没有"，而是"我能不能百分之百确定清干净了"。清不干净的成本远高于一个下午。

7. 从另一台干净机器轮换凭证。 注意是另一台。在中招机器上登录控制台改密码，新密码照样经过被控环境。

要换的清单：SSH 私钥、云厂商 AccessKey、CI/CD Token、数据库密码、代码托管平台的 Personal Access Token，以及那段时间在这台机器上登录过的账号会话。

Cursor 也提供了 remediate-macos.sh 和 remediate-windows.ps1 两个脚本，会一并清扩展、持久化和公钥，有残留时以非零状态退出。用之前先读一遍脚本内容——这是在别人机器出过事之后，你自己该有的习惯。

8. 升级到 2.1.314 或更高。 这一步放在最后，因为升级会覆盖现场，不利于前面留证。

为什么"官方发布"没拦住这次投毒

很多人第一反应是：这不是 Anthropic 官方插件吗，怎么会有后门？

因为被改的不是包的身份，是分发通道。攻击者没有伪造签名，而是拿到了 Cursor 内部的凭证，直接往市场缓存里放了两个包。你看到发布者写着 Anthropic，插件也确实从 Cursor 市场装进来，但构建它的不是 Anthropic。

第三方逆向分析提到一个细节：恶意代码是在 extension.js 开头插了一段加载逻辑，原有功能代码基本没动。这意味着插件装完照常工作，功能上挑不出毛病——而绝大多数人不会为一个"官方插件"去读打包后的源码。

这件事真正的教训不是"官方不可信"，而是："发布者显示为官方"只证明身份，不证明这条链路上每个环节都没被借道。 供应商、缓存、CDN、更新服务器，任何一环被拿下，签名都救不了你。

长期防护：六个能落地的动作

1. 把扩展来源收窄。 团队里限定可安装的发布者白名单，个人至少做到不从第三方市场装同名插件。
2. 新版本冷却 24 小时。 自动更新是这次能波及 5000 人的直接原因——恶意版本上线 11 小时，自动更新帮你"及时"装上了。能关自动更新的工具就关，或者延迟一天再升。
3. 敏感仓库开隐私模式。 这次泄露的轨迹全部来自未开隐私模式的会话。这个开关不花钱，只是少一点训练数据贡献。
4. 密钥不进对话框。 不要往 AI 对话里贴 .env、连接串、云厂商密钥。这次事件里被拿走的，就包括用户曾经发给客服的凭证。
5. 用短时、限域的令牌。 一个只能读某个仓库、7 天过期的 Token，泄露后的损失是有上限的；一个永久全权限的 AccessKey 没有上限。
6. 把供应商列进攻击面清单。 写下来：你把代码和日志发给了谁。这份清单越长，越该有人负责盯他们的安全公告。

几个常见疑问

我只用 VS Code 官方市场，受影响吗？ 不受影响。恶意包只出现在 Cursor 的扩展市场缓存里，Open VSX 和 VS Code 官方市场都没有。

npm 全局装的 Claude Code 呢？ 也不受影响。npm install -g @anthropic-ai/claude-code 装的包没有被篡改。

我已经升到 2.1.314 了，还要查吗？ 要。升级覆盖的是插件文件，不碰 authorized_keys 和启动项。查完再决定要不要轮换凭证。

没收到 Cursor 的邮件，是不是就安全？ 只能说明你的会话轨迹不在被复制的范围内，不代表你没下载过恶意版本。这两件事是分开统计的。

Linux 用户要查吗？ Cursor 点名的是 macOS 和 Windows 构建，但 Cursor 官方的 IOC 清单里同样列了 Linux 路径。花 30 秒跑一遍 grep，比判断"我大概不在范围里"划算。

这次事件的成本结构很不平均：攻击者只需要一把泄露的密钥，5000 个用户却要花几个小时排查、可能还要重装系统。防御上能做的其实很有限，无非是把更新慢一点、密钥小一点、来源窄一点。

如果你想从更上游想清楚工具该怎么选，AI 编程工具的四个层级 那篇讲了能力与风险的对应关系；自己搭 Agent 时怎么管 Key，Cline 插件的成本结构 里有相关讨论。