Cursor 安全复盘:第三方推理商的密钥泄露,5,000 名开发者装上带 SSH 后门的 Claude Code 扩展

5,000 名开发者,装了一个假的 Claude Code。

不是他们贪心,也不是点了钓鱼链接。他们只是在 Cursor 的扩展市场里,更新了一个自己天天用的插件。11 月 13 日,Cursor 用一篇 6 分钟的复盘承认:这把刀,是从供应商那边递过来的。

发生了什么

事情的起点不在 Cursor,在 Fireworks——一家提供模型推理服务的第三方厂商。推理(也就是模型跑一次回答)这块活,Cursor 把一部分交出去了。

Cursor 发给 Fireworks 一把访问钥匙(一把只能读数据的凭证),用来共享训练用的数据。按照 Cursor 的说法,这把钥匙是被 Fireworks 那边泄露的。攻击者拿它打开了一个只读存储桶——只能读、不能改的网盘——里面存着历史编码对话记录,大部分是 2025 年的,来自没开隐私模式的用户。

问题出在这些记录里:有一小部分,其中的接口密钥(就是调用各家 AI 服务时要出示的那串口令)忘了打码。拿到它们,攻击者一路摸进 Cursor 内部若干个 SaaS 工具(在线客服、监控这类第三方服务),读到归档的非生产源码仓库、部分客服邮件、产品使用数据、部分对话摘要,还有用户以前发给客服的凭证。

最后一步最狠。10 月 29 日,攻击者用偷来的一个市场发布凭证,把两份假的 Claude Code 扩展直接放进了 Cursor 用来分发扩展的缓存,版本号 2.1.312 和 2.1.313。从凌晨 2 点 27 分到下午 1 点 35 分,挂了大约 11 个小时。Cursor 估算,最多 5,000 名在这段时间请求了这两个版本的用户,可能装上了带 SSH 后门的版本。

(SSH 是远程登录服务器的常用通道;后门,就是有人给自己留了一把能随时进来的钥匙。)

数字与一手细节

关键数字摆齐,全部来自 Cursor 官方复盘与 10 月 29 日的安全公告:

  • 暴露时长:约 11 小时(10 月 29 日 2:27 至 13:35,太平洋时间)
  • 潜在中招人数:最多 5,000 人
  • 对话记录被波及的用户:不到 0.05%;接口密钥被波及的客户:不到 0.01%
  • 恶意版本:Anthropic.claude-code 2.1.312 与 2.1.313,仅 macOS 与 Windows
  • 最后一次攻击者活动:11 月 1 日,已被阻断

恶意代码干的事很具体:收集主机名、用户名、系统版本、工作目录、Git 邮箱和公网 IP,把攻击者的公钥(备注名 svc-telemetry)写进你的免密登录名单,再拉起一条反向隧道——从你的机器主动连出去,让外面的人能反向进来。它还会在 macOS 上装开机自启,在 Windows 上建计划任务,后台每 60 秒重试一次。

反过来说,这条后门在多数机器上其实没打通。Cursor 自己写明:开启本地 SSH 服务需要管理员权限,而恶意扩展在绝大多数 mac 和 Windows 上没有这个权限;再加上恶意代码本身有错误,这一步大概率失败。攻击者的服务器也已被托管的云厂商下线。

还有两个容易被忽略的事实:Anthropic 没有发布过这个版本,Cursor 的上游扩展源 Open VSX 里也从未出现这个恶意包。换句话说,问题不在模型厂商,也不在开源源站,而在中间那层分发缓存。

反转:挡住攻击的是运气,不是防线

这里有两层反转,值得分开看。

第一层,Cursor 的口径和事件本身是矛盾的。官方反复强调「绝大多数客户没有受影响」,从比例上讲没错——0.05%、0.01% 都是很小的数字。但对被点中的那 5,000 个人来说,比例毫无意义:他们在自己的编辑器里,装了一个带 SSH 后门的扩展。而且 Cursor 在 10 月 29 日的公告里明确写了一句:光卸载扩展可能不够,因为恶意代码会丢下独立的常驻脚本,继续跑。

第二层反转更冷酷:这次没出事,很大程度上是因为攻击者写错了代码。安全研究者复盘发现,恶意脚本在多数没有预先开启 SSH 服务的 mac 和 Windows 上都会失败。救下这批开发者的是攻击方的失误,不是防守方的能力。

把镜头拉远,Cursor 不是孤例。安全厂商 Wiz 把这轮针对 AI 开发平台的连环入侵叫「黑色十月」:10 月 9 日 Fireworks 首次披露,10 月 15 日 Lightning AI,10 月 16 日 OpenCode,10 月 20 日 Railway,10 月 23 日 Warp,10 月 30 日 Northflank,再加上 Cursor 与 Fireworks 的第二次。平台 Zeabur 已经因为这起事件宣布关停。

其中 Railway 公布的一手数据最能说明这门生意的规模:最多 1.85% 的工作区(约 10 万个) 的环境变量可能被解密,1,852 名用户的关联令牌被重置,被偷走的钥匙造成的未授权消费估计达到 74 万美元。攻击者在数据库里按正则表达式专门筛「AI 供应商密钥」这一类变量,还专门挑环境变量数量多的客户下手。

动机并不神秘:偷到的 AI 凭证可以转卖给路由网关,用来做大模型盗刷(行话叫 LLMJacking,也就是盗用别人的账号额度,转手把模型调用卖出去),也可以拿去炼自己的模型——行话叫蒸馏,意思是拿别人的模型输出去训练自家的模型,省下大笔训练成本。Wiz 记录的两个下游滥用案例,光按标价计算就烧掉了超过 10 万美元。

对你意味着什么

如果你用 Cursor、VS Code 或任何带扩展市场的编辑器,这件事的关键不在「Cursor 安不安全」,而在这条链条有多长:

你的编辑器信任扩展市场,扩展市场信任发布凭证,发布凭证来自内部系统,内部系统被一把发给第三方推理商的钥匙打开,那把钥匙被推理商泄露。

五层里,你只能看见第一层。你点「更新」的时候,实际是在替后面四层一起背书。

更值得记住的是数据侧的教训:一份 2025 年的历史对话记录,因为几句忘了打码的密钥,就能把攻击者从「只读」抬到「能写入」。这不是某家公司的疏忽,而是整个行业为了做模型训练而长期保留对话数据这个默认设置带来的结构性风险。这也是为什么 Cursor 这次的处置里,最彻底的一条是把所有推理流量从 Fireworks 整体迁走。

我该做什么

按优先级,四件事。

一,先自查。恶意扩展会在免密登录名单里留一个备注为 svc-telemetry 的公钥。macOS 终端执行:

grep -qs svc-telemetry ~/.ssh/authorized_keys && echo "命中" || echo "干净"

Windows 在 PowerShell 里查 %USERPROFILE%\.ssh\authorized_keys 与 C:\ProgramData\ssh\administrators_authorized_keys 两个文件,搜 svc-telemetry。命中就按 Cursor 公告里的清理脚本处理,并考虑重装系统。

二,判断自己在不在名单里。开了隐私模式的用户,对话记录不在那个存储桶里;没开的,如果当时装了这两个恶意版本,你应该已经收到 Cursor 的站内通知或邮件——Cursor 说没收到通知,你的数据就不在这批记录里。

三,轮换凭证,别只卸载。只要你的机器在 10 月 29 日那两个版本期间装过扩展,就从一台干净设备上重置这台机器能碰到的所有密钥,尤其是你曾经发给过客服的那些。

四,对团队来说,把供应商事故写进自己的应急清单。这次真正的入口是一家你大概率没听说过的推理服务商。提问方式可以很简单:我们交给第三方的数据,留存多久、存在哪、谁能读、泄露了怎么通知我们。答不上来的,就是风险敞口。

—

过去一个月,同一个剧本在至少七家 AI 开发平台上重演了一遍,Cursor 只是其中第一个把完整链路公开到「一把钥匙怎么变成 5,000 个后门」的公司。这类事故还会再来,因为只要 AI 凭证能直接换成钱,撞供应商的门就永远比撞你的门便宜。

关注 AI商业快讯,每天一篇 AI 热点深度解读。

相关阅读:

参考来源:

  1. Cursor 官方复盘《An update on our recent security incident》(2026-11-13,一手)https://cursor.com/blog/security-incident-update
  1. Cursor 官方安全公告《Security notice — malicious version of Anthropic.claude-code 2.1.312 and 2.1.313》(2026-10-29,一手)https://cursor.com/blog/claude-code-extension-security-notice
  1. BleepingComputer《Cursor confirms security breach led to malicious Claude Code extension》(2026-11-14)https://www.bleepingcomputer.com/news/security/cursor-confirms-security-breach-led-to-malicious-claude-code-extension/
  1. Wiz《”Black October” for AI Developer Platforms》(安全厂商分析)https://www.wiz.io/blog/black-october-for-ai-developer-platforms
  1. Railway 官方事件报告《Incident Report: October 21st Security Attack》(2026-11-10,一手)https://blog.railway.com/p/incident-report-october-security-incident

发表评论