10月29日在Cursor里装过Claude Code扩展的人，不等于都中了后门。Cursor在事发当天发布的安全公告里写明，10月29日太平洋时间凌晨2:27到下午1:35之间，一个被恶意篡改的Claude Code扩展曾在Cursor VS Code扩展市场里提供，受影响的就是Anthropic.claude-code的2.1.312和2.1.313两个版本（Windows和macOS）。安天实验室按北京时间换算了这个窗口：当天17:27到次日凌晨4:35，约11小时，在这期间请求到该缓存版本的用户可能拿到恶意构建。11月13日发布的完整调查复盘给出了规模上限：最多5,000名用户可能拿到恶意构建，这个版本在架约11小时后被撤下。Cursor安全公告安天实验室Cursor安全复盘
Anthropic也把责任边界划清了：这份恶意包不是Anthropic发布的，Claude Code本身没有漏洞，市场源头Open VSX从头到尾没有这个恶意包。公告同时写明，没有证据表明这个扩展的其他版本或官方分发渠道受影响，从npm或官网安装脚本装的Claude Code命令行不在这次范围内。但"我早把它卸了"不能自证清白，光卸扩展不够，后门脚本会自己留着跑。Cursor官网Cursor安全公告知乎
这个恶意包做的事不复杂：收集主机名、用户名、系统、Git邮箱、公网IP和环境变量名，再往authorized_keys里追加一把注释为svc-telemetry的攻击者公钥，留下大约每60秒重连一次的反向SSH隧道。读环境变量时只拿变量名、不抓取变量本身的密钥值，安天实验室将其定性为前置侦察而非密钥已失窃。开启本机SSH服务需要管理员权限，官方公告说明：除非用管理员权限启动Cursor这种极少见情况，由于恶意代码里的错误，这一步会失败，攻击者借隧道登录不进来；但写公钥、放持久化和上报主机信息不依赖这一环。攻击者的服务器已被Cursor配合托管商下线，11月1日之后再没有观察到攻击活动，事故被认为已受控。可如果你那台机器的后门文件当时落了盘，它们到今天还在原地——所以这三步全只读的检查，现在仍然值得做。安天实验室Cursor安全公告Cursor安全复盘
第一步：先确认你是不是那5,000人之一
三个条件要同时命中才有嫌疑：10月29日在Cursor的扩展市场里安装或自动更新过Claude Code扩展；版本是2.1.312或2.1.313；来源是Cursor扩展市场而不是官方渠道。版本号没记住有两个办法：公告给了恶意包两个平台的SHA-256——2.1.312的win32-x64包以3de17229开头、darwin-arm64以fcbb327e开头，2.1.313分别以6786ec90和80402fca开头——本地还留着包可以算哈希比对。去Cursor扩展目录看一眼也能缩小范围，但这只回答"现在装没装"，回答不了"跑没跑过"：有人在Windows 10上实测后总结，扩展目录只能回答装没装，持久化文件和计划任务才能回答跑没跑过，两问都要查，装过这两个版本又卸掉的人必须继续往下走。三个条件有一条不成立，这件事就与你无关，可以停在这里。Cursor安全公告知乎
第二步：查authorized_keys里有没有多出一把钥匙
Cursor官方给了现成的检查命令：macOS上跑`grep -qs svc-telemetry ~/.ssh/authorized_keys && echo “svc-telemetry key found” || echo “No key found; machine not impacted”`，Windows在PowerShell里检查`$HOME.sshauthorized_keys`和`C:ProgramDatasshadministrators_authorized_keys`两个路径，找的就是恶意扩展追加的那把标着svc-telemetry的攻击者公钥。读结果时有两个坑。一是实测账号发现的：官方那条Windows检查命令会把"密钥文件根本不存在"说成"机器未受影响"，这两句话不是一回事——先确认authorized_keys文件本身在不在，这句"No key found"才有意义。二是追加公钥时不保证换行，钥匙可能和原有公钥粘在同一行，检索没搜到注释也不代表公钥条目不存在，所以应当优先核对指纹而不是只搜svc-telemetry这个注释词，这把恶意公钥的指纹是SHA256:0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk。Cursor安全公告知乎安天实验室
第三步：查持久化文件和进程——"跑没跑过"看这步
持久化脚本独立于扩展存在，命中任何一项都说明当时真的执行过：macOS看`~/Library/LaunchAgents`里有没有`com.apple.sysmond.plist`、`~/.config`下有没有`.smt`和`.smtk`、`$TMPDIR`下有没有`.stk_`开头带10位十六进制的文件；Windows看`schtasks /query /tn SysMon`计划任务（报"找不到任务"才是未执行过）、`%USERPROFILE%.config`下的smt.cmd和smtk、`%TEMP%`下的.stk_文件，以及启动文件夹里的sysmon.cmd。进程侧可以留意`ssh -N -R ‘*:0:localhost:22’`和`autossh -M 0`这类反向隧道命令，它们指向的134.209.82.225早已下线。Cursor安全公告安天实验室
有命中就先隔离这台机器，然后按公告的顺序处理而不是自己乱删：官方提供了remediate-macos.sh（以受影响的普通用户身份运行，不要用root）和remediate-windows.ps1（管理员PowerShell运行）两个清除脚本，清完仍要在另一台可信机器上轮换这台机器能访问的所有凭据和会话，敏感环境按公告建议评估直接重做系统。Cursor安全公告
没收到Cursor通知，不代表机器不用查
11月13日的复盘披露了事件的另一条线：一名攻击者获得了Cursor发给Fireworks的访问密钥，这把密钥被Fireworks泄露，攻击者用它从一个只读存储桶里拷走了用于共享的非Privacy Mode编程智能体记录，再顺这些未脱敏的凭据进入Cursor的部分SaaS工具，最后用偷来的凭证把篡改过的扩展直接塞进了服务扩展市场的缓存。Cursor安全复盘
这条线上，不足0.01%的客户有API凭据暴露，不足0.05%的非Privacy Mode用户的记录被外流，这些人都被直接通知过；Cursor也写明，没收到通知就意味着你的数据不在这些记录里。但那份名单只覆盖数据泄露这条线；扩展后门在你机器上落了没有，只有自己的三步结果能回答——代码记录有没有外流，和你的开发机有没有被塞进一把SSH钥匙，是两件事，这也是这波转述里最常被混淆的一点。Cursor官网
