10 月 29 日凌晨，如果你顺手在 Cursor 里点了那个"更新"，你装上的 Anthropic Claude Code 扩展，不是 Anthropic 发的。11 月 13 日，Cursor 交出完整复盘。链条比"插件市场混进一个假货"长得多。CursorCursor
起点是一家你可能没听说过的供应商
第一环不在 Cursor，也不在 Anthropic，在 Fireworks——Cursor 的第三方推理与训练供应商。攻击者拿到一把由 Cursor 签发、又从 Fireworks 一侧泄露出去的访问密钥，用它从一个只读存储桶里拷走了一批编程智能体的链路追踪数据，主要是 2025 年、没开隐私模式的会话。Cursor微博知乎
这批数据里有少量记录带着没脱敏的凭据，API 凭证遭泄露的客户不到 0.01%。攻击者顺着它摸进 Cursor 在用的部分 SaaS 工具，拿到已归档的非生产代码仓库、部分客服数据与邮件往来、产品使用指标，以及一部分智能体对话摘要。Cursor
最后一步才轮到扩展：10 月 29 日，攻击者用偷来的凭据，把篡改过的 Anthropic.claude-code 2.1.312 和 2.1.313 塞进了 Cursor 扩展市场的分发缓存。上游 Open VSX 从头到尾没有这个包，Anthropic 没发过它，也不是 Claude Code 自身的漏洞。恶意构建挂了约 11 小时，最多 5000 名用户可能拿到。知乎Cursor微博
最坑的一句安慰：“攻击代码有 bug”
Cursor 说，开启本地 SSH 服务需要管理员权限，绝大多数机器上这一步会失败，攻击者没法通过反向隧道登进来。听着像虚惊一场——但同一份公告紧接着还有另一句：扩展已经把攻击者的 SSH 公钥加进了 authorized_keys、装好了持久化机制、并把主机信息发了出去。失败的是"进门"，不是"撬锁"。要是你那台机器本来就开着 SSH——常年跑远程开发的 Mac、当服务器用的 Linux 工作站——authorized_keys 里多出来的那把 svc-telemetry 就是一张现成的门卡，隧道成不成都不影响对方直连。Cursor知乎
所以卸载扩展没用
卸载扩展解决不了问题。恶意载荷落地的是独立脚本和自启项，跟扩展生命周期没关系：Cursor
macOS：~/Library/LaunchAgents/com.apple.sysmond.plist（名字伪装成苹果系统进程），执行 ~/.config/.smt，约每 60 秒重试一次
Windows：计划任务 SysMon，权限不够就退化成启动文件夹里的 sysmon.cmd
Linux：~/.config/.smt 与 .smtk，往 crontab 加 @reboot
一分钟自查，只读不改。macOS 终端里跑：知乎
```bash
grep -qs svc-telemetry ~/.ssh/authorized_keys && echo “found” || echo “not impacted”
```
Windows 在 PowerShell 里查 `$HOME.sshauthorized_keys` 和 `C:ProgramDatasshadministrators_authorized_keys` 有没有 svc-telemetry。
有输出就是中招。别自己上手删，按官方顺序：隔离主机 → 跑官方修复脚本（macOS 用 remediate-macos.sh，以受影响用户身份而非 root；Windows 用 remediate-windows.ps1，管理员 PowerShell）→ 换一台可信机器，轮换中招机器能碰到的所有凭证和会话。Cursor
攻击者服务器 134.209.82.225 已被云厂商下线，信标和反向 shell 都失效了。但这只意味着"没人再来"，不意味着"痕迹没了"。知乎
谁可以先松口气
开了隐私模式：提示词和代码不受影响。没开：链路追踪数据泄露的用户占比不到 0.05%，Cursor 已逐一直接通知——没收到通知，说明你不在这批数据里。Cursor 应用本体、官方更新、其他扩展、客户代码仓库、生产系统都没被动过，市场里其余扩展已验证为正版并重建过。最后一次观察到的攻击者活动在 11 月 1 日，已被拦截。微博Cursor
真正该记住的一件事
这次没有漏洞利用，没有内存破坏，全是合法 API：child_process、fs、os、http、crypto。VS Code 系编辑器的扩展宿主本身就是一个 Node 进程，拿的是启动 IDE 那个用户的全部权限——读文件、起子进程、连网络，一个不缺。知乎
对比一下就很尴尬：npm 好歹有 lockfile、有 audit、团队能卡版本；IDE 扩展是点一下装完、之后自动更新，多数团队连"我们允许哪些扩展"的清单都拿不出来。
企业侧现在就能加三条检测信号：非苹果进程写 com.apple.* 的 LaunchAgent；LaunchAgent 用 /bin/sh 执行家目录里的隐藏脚本；IDE 扩展宿主进程直接改 ~/.ssh/authorized_keys。最后一条在正常业务里几乎不会发生，误报率极低。知乎
还有一件事两份公告都没说清：那个已被信任的发布身份，是怎么落到攻击者手里的。Cursor 只用了"恶意行为者"这个措辞。这条不查清，下一次只是时间问题。
至于跑完命令满屏皆空的人——就当免费体检了一次。
