卸载扩展清不掉,Cursor 市场上 Claude Code 恶意包的工程账本

封面用双色工程隐喻，深钴蓝是看似平静的扩展市场分发链，信号红是那枚悄悄写进系统的 svc-telemetry 钥匙与持久化驻留。

11 个小时与两个冒牌版本

做系统工程的人，翻安全报告第一件事不是看事故有多严重，而是先把时间线和版本钉死。

按 Cursor 官方博客安全通报公开披露的细节，事情发生在太平洋时间 2026 年 10 月 29 日。

从凌晨 02:27 恶意包上架，到当天中午 13:35 官方彻底完成下架与市场隔离。

换算成北京时间，正好是 10 月 29 日傍晚 17:27 到次日凌晨 04:35。

整整 11 个小时又 8 分钟。

在这段窗口期内，任何在 Cursor 编辑器内搜索并安装了 Claude Code 的开发者，拉下来的包都有极大概率是带毒的。

问题包锁定了两个具体的版本号，Anthropic.claude-code 2.1.312 与 2.1.313。

两个版本覆盖了 Windows 和 macOS 两大主流开发系统。

这里必须先把事实边界切得极度干净。

这不是 Anthropic 官方开发，更不是 Claude 模型本体或后端 API 出了什么篓子。

甚至也不是 Anthropic 官方在自己的软件分发渠道里被人篡改。

这是一起典型的 IDE 第三方扩展分发链冒名顶替投毒事件。

攻击者瞄准了 Cursor 自建的 VS Code 兼容扩展市场，打着 Anthropic.claude-code 的招牌，把并非 Anthropic 开发的恶意包送上了架。

受影响的用户规模有多少？

官方通报口径在四千到五千量级。最初的安全通告与早期披露口径记录为约 4100 人，随后各方追踪与媒体转述演进到约 5000 人。

这说明统计口径在事件处置中有过微调，我们没有必要去假装掌握了独立统计数字。

Cursor 官方在补充通报里明确排除了波及面扩散的可能，确认 cursor.com/marketplace 上的其它正常扩展没有受到篡改，Grok Bot 以及 SpaceXSI 旗下的其它产品线也均未受牵连。

但对那几千台真正中招的开发机来说，这 11 个小时，已经足够发生很多不可逆的事。

翻开三层工程账本，别拿「没登进来」自我安慰

通报出来之后，很多技术社群里的讨论走向了一个很危险的倾向。

大家看到通报里写着「由于大多数宿主机权限限制，远程 SSH 隧道未能成功登入」，就纷纷拍胸口说虚惊一场。

千万别这么哄自己。

只要把恶意包里的 extension.js 载荷翻开，对照着它的调用逻辑一行行看，任何一个合格的工程师都会把这笔账清清楚楚拆成三层。

第一层，是已经完整发生的敏感信息窃取。

恶意扩展在编辑器启动被加载的一瞬间，根本不需要向用户弹窗索取任何高级权限。

它直接在当前普通用户权限下，调取操作系统的环境接口，一口气收集了大量关键指纹。

这里面包括主机名 hostname、当前用户名 username、操作系统类型与 CPU 架构、用户家目录路径。

更要命的是，它抓取了当前环境所有的环境变量名称列表，以及当前正在打开的项目工程工作目录。

顺手还读取了开发者的 Git 提交邮箱，以及宿主机的公网出口 IP。

这些信息随后被打包，通过 HTTP POST 径直发往攻击者的 C2 收集端。

只要你的编辑器当时连着网，你的主机名、你的用户名、你在做什么项目、你机器上配了哪些敏感环境变量的名字，就已经全部落在了攻击者的数据库里。

这一层，叫做既成事实。

第二层，是已经生根发芽的系统级持久化。

很多人以为插件关了就没了，但载荷在执行的第一分钟，就为自己安排好了后路。

在 macOS 上，它悄悄在用户的配置目录写入隐藏脚本，路径落在 ~/.config/.smt 与 .smtk。

紧接着，它向 macOS 系统的 LaunchAgents 注册了一份自启动服务配置，标签命名为 com.apple.sysmond，伪装成苹果系统的系统监控进程。

在 Windows 上，它尝试调用系统命令，直接注册名为 SysMon 的计划任务，并尝试挂载 SYSTEM 权限。如果因为权限不足受阻，立刻自动回退到当前用户的启动目录，生成一个名为 sysmon.cmd 的自启动批处理文件。

这套后台常驻机制不仅会在每次开机登录时被拉起，甚至还在内存里挂了定时器，每隔大约 60 秒就会在后台苏醒一次，尝试重新打通反向穿透。

这一层，叫做落地生根。

第三层，才是攻击链条最终断裂的地方，远程交互式登录。

攻击者的胃口非常大。它不满足于只偷点指纹，它想要的是这台开发机的完整控制权。

它做的事情很激进，强行把自己的公钥塞进用户的 ~/.ssh/authorized_keys，然后试图在本地强行启动 SSH Daemon 服务。

随后，它让本地进程去连攻击者位于 134.209.82.225 的服务器，试图搭起一条反向 SSH 隧道，把外网端口直接映射回本地的 SSH 服务端口。

按照攻击者的剧本，只要这一步走通，他们就能随时随地从外网敲进你的本地终端，拿到一个完整的交互式 shell。

然而，剧本在现实面前卡壳了。

在现代桌面操作系统上，开启并拉起一个系统级的 SSH 服务，必须要管理员权限或者超级用户提权。

普通开发者打开 Cursor 写代码，绝大多数人不会用 sudo 或者 Administrator 权限常驻跑 IDE。

由于没有管理员权限，那句试图开启本地 SSH 服务的指令直接被操作系统拒绝，报错退出了。

没有本地 SSH 服务在指定端口监听，攻击者哪怕在远端建好了网络通道，敲门也敲不进房间。

这就是官方通报里「多数机器因无管理员权限未被远程登录」的真正技术原委。

但看懂了这三层账本，你还会觉得这叫没出事吗？

窃密已经交卷，持久化已经扎根，唯一卡住的只是攻击者胃口太大的最后一跳。

把对手在最后一步的失手，当成自己的防守成功，这是做安全工程最忌讳的幻觉。

卸载扩展，为什么只是自欺欺人

面对这种情况，很多人的肌肉记忆是点开 Cursor 的扩展面板，找到那个冒牌包，点一下卸载，然后重启编辑器。

他们以为这样就能把系统擦干净。

说真的，这种做法不仅没用，反而会给人一种虚假的安全感。

问题出在现代 IDE 扩展的运行模型上。

现代编辑器的插件虽然看起来像是一个界面小组件，但它的底层执行实体，是拥有当前操作系统用户完整权限的 Node.js 进程。

它想在文件系统里写什么文件，想在操作系统里注册什么服务，不需要经过任何沙箱的二次审批。

恶意载荷在第一次执行的时候，就已经完成了关键的脱壳动作。

它把自己从 Cursor 的扩展进程空间，复制到了操作系统的守护进程空间。

那个 LaunchAgent 注册项在系统的用户库里，那个自启动脚本在隐藏的配置目录里。

这些东西与 Cursor 编辑器本身已经没有任何父子进程的绑定关系。

当你点击卸载扩展的时候，Cursor 能做的事情，仅仅是把扩展安装目录下的几个 js 文件从磁盘上抹掉。

它管不到系统级的 LaunchAgents。

它更管不到正在后台每 60 秒轮询一次的独立脚本进程。

甚至，即便托管服务商已经迅速出手，把攻击者的 C2 服务器 134.209.82.225 彻底断网下线，你的系统依然是不干净的。

因为那段被植入的自启动脚本，每天开机依然会被系统忠实地唤醒，依然会在你的后台默默消耗资源发起网络探测。

更危险的是，那把带有恶意公钥的钥匙，依然躺在你的 ~/.ssh/authorized_keys 里面。

设想一个非常现实的工程场景，未来某一天，你为了在局域网内协同调试，或者为了给远程开发搭测试环境，顺手在本地启用了系统的 Remote Login 或者 OpenSSH 服务。

在那一瞬间，这扇原本因为没有服务监听而虚掩着的门，就会立刻对那把早早埋下的公钥彻底敞开。

在计算机世界里，被污染的状态不会因为你假装看不见就自动复原。

清理必须是对账式的，每一笔账都得亲手销掉。

怎么核，svc-telemetry 标签与检测命令

排查的第一步，是确认自己的设备到底有没有被这枚恶意载荷写入钥匙。

整起事件最显著、也是最容易锁定的一个静态特征，是攻击者在公钥末尾留下的伪装标识。

他们使用了一个极具迷惑性的注释标签，svc-telemetry。

表面上看起来像是一个收集系统遥测数据的后台服务公钥，其实就是攻击者的身份凭证。

该公钥对应的 SHA256 指纹为 SHA256:0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk。

Cursor 官方在安全通报中给出了权威的单行核对命令。

如果你使用的是 macOS 系统，打开终端，完整执行下面这行检测指令。

grep -qs svc-telemetry ~/.ssh/authorized_keys && echo "svc-telemetry key found" || echo "No key found; machine not impacted" 

这行命令逻辑非常纯粹，静默检索你的授权密钥列表。如果命中了标签，终端会明确提示发现密钥，反之则说明公钥未被写入。

如果你使用的是 Windows 系统，在 PowerShell 中执行官方给出的排查命令。

$files = "$HOME\.ssh\authorized_keys", "C:\ProgramData\ssh\administrators_authorized_keys" | Where-Object { Test-Path $_ } if ($files -and (Select-String svc-telemetry $files)) { "svc-telemetry key found" } else { "No key found; machine not impacted" } 

除了看公钥，还有几个关键的持久化驻留点必须人工核实。

在 macOS 上，重点排查两个文件路径与一个系统标签。

第一个是系统服务配置，检查 ~/Library/LaunchAgents/com.apple.sysmond.plist 是否存在。

第二个是隐藏执行体，检查用户家目录下的 ~/.config/.smt 以及 ~/.config/.smtk。

一旦发现上述任何一个文件，就意味着持久化守护项已经在这台机器上被成功激活。

在 Windows 上，重点排查计划任务与启动目录。

打开任务计划程序，检索是否存在名为 SysMon 的异常任务。

同时打开文件资源管理器，检查 %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\ 路径下，是否存在名为 sysmon.cmd 的批处理脚本。

在网络侧与终端防护系统（EDR）中，如果有条件查阅历史日志，可以检索所有涉及目标 IP 134.209.82.225 的出站连接。

攻击者的心跳上报走的是该 IP 的 8099 端口，路径为 /beacon，反向 SSH 隧道连接走的是该 IP 的标准 22 端口，使用的登录用户名为 tunnel。

把这些指标一条条拿去对，不要凭侥幸心理下结论。

怎么清，处置优先级与供应链分发的冷思考

如果前面的检测命中了任何一项，说明系统已经被污染。

这时候不能慌，也不能乱点，必须严格按照工程优先级来做闭环处置。

第一优先级，物理断网或切断 Wi-Fi。

切断网络连接的目的是掐死任何潜在的二次外联，防止系统在排障过程中被突发指令干扰。

第二优先级，清理持久化驻留项与被污染的配置。

Cursor 官方针对受害主机发布了专门的修复脚本，但这里有一个极度关键的工程细节需要特别注意。

在 macOS 上运行官方的 remediate-macos.sh 时，必须以当前受影响的普通用户身份直接执行，绝对不要使用 sudo，绝对不要切到 root 账户去跑。

很多运维朋友习惯了一出事就提权跑脚本，但这次的恶意载荷是写在普通用户的家目录、用户的配置目录和用户级 LaunchAgents 下的。

如果你用 root 身份跑，清理脚本找的是 /var/root/ 下的文件，不仅根本删不到普通用户路径下的恶意持久化文件，反而可能会改动系统的全局配置。

在 Windows 上，则正好相反，因为涉及到系统计划任务的停用与删除，需要以管理员身份启动 PowerShell，再运行官方的 remediate-windows.ps1 脚本。

脚本执行完毕后，人工打开 ~/.ssh/authorized_keys，确认里面所有包含 svc-telemetry 的公钥行已经被彻底剔除。

第三优先级，可信环境下的全量凭证轮换。

这是很多人最容易漏掉、却往往代价最大的一环。

前面我们强调过，恶意载荷第一步就把环境变量名字、工作目录、Git email 等信息给偷走了。

如果你的开发机在 ~/.zshrc、~/.bashrc 或者系统的环境变量中配了云厂商的 AccessKey，配了 GitHub 的 Personal Access Token，或者本地拉取过包含数据库密码的私有项目配置。

那么这些凭证在安全模型里，就已经不能再被视为机密。

必须找一台完全没有受过污染的干净机器，登录管理后台，把所有在这台机器上出现过的 API Key、私钥、Token 通通吊销并重新生成。

如果这台机器是属于核心基础架构工程师、掌管着生产发布集群的特权开发机，最严谨、也是最负责任的工程选择，永远是备份代码数据之后，全盘抹掉重新安装操作系统。

回顾 Cursor 官方团队在发现问题后的应急处置，动作是标准且迅速的。

下架恶意版本，整站关停 marketplace，对市场内的所有历史扩展展开全局静态审计，确认没有其它包被挂马，随后全面轮换生产服务密钥，重建市场平台后重新上线，并配合云提供商在网络层面彻底端掉了攻击者的 C2 机器。

如果后续在业务开发中依然需要使用官方提供的 Claude Code 插件，Cursor 官方给出的安全升级口径是升级到 Claude Code for VS Code 2.1.314 版本。

事件本身告一段落，但留给整个开发生态的警示非常刺耳。

长期以来，软件工程界对供应链安全的防范重心，几乎全押在 npm、PyPI、Maven 这些代码依赖仓库上。

开发者敲下 npm install 或者 pip install 的时候，往往会多看一眼依赖包的来源和名字。

但在 IDE 扩展市场上，大家的防备心理却脆弱得像一张白纸。

面对一个名字叫 Anthropic、图标高仿、功能描述专业的扩展，哪怕它的发布者是个没有任何背书的冒牌号，许多人还是会不假思索地点下安装。

现代 AI 编辑器正在把代码生成、自动化终端交互、系统级工具调用的权限无限放权给前端插件。

如果分发层对发布者没有严格的强身份认证，如果运行层对插件进程依然缺乏细粒度的系统沙箱隔离。

那么今天发生在一个第三方市场里的 11 个小时，在未来就依然会在某个意想不到的角落，重新上演。