Cursor 扩展市场遭投毒：Claude Code 2.1.312 / 2.1.313 被植入持久化 SSH 后门

要点

• Cursor 官方确认：太平洋时间 2026-10-29 约 2:27 至 13:35，其 VS Code 扩展市场上架了被恶意篡改的 Anthropic.claude-code 版本 2.1.312 与 2.1.313（Windows 与 macOS）。官方原文明确 "These malicious versions of the extension were not developed by Anthropic"。
• 暴露窗口约 11 小时。受影响的是「在这段时间里从 Cursor 扩展市场安装或自动更新了该扩展」的 macOS / Windows 用户。
• 载荷做了四件事：① 收集并上报 host / 用户信息（主机名、用户名、OS、架构、主目录路径、环境变量名、工作目录、已配置的 Git 邮箱、公网 IP）；② 往 authorized_keys 写入攻击者控制的 SSH key、尝试开启本地 SSH 服务并建立反向 SSH 隧道；③ 用 **LaunchAgent（macOS）/ 计划任务（Windows，尝试以 SYSTEM 运行、回退到启动目录脚本）**做持久化，后台脚本约每 60 秒重试一次隧道；④ 向攻击者端点 POST 主机信息。
• 一个关键的减损事实：官方称由于恶意代码自身存在错误，除 Cursor 以管理员权限启动这类极不常见的情况外，「开启 SSH 服务」这一步会失败；且官方已与托管商协作把攻击者服务器下线，反向 shell 与主机详情上报均已失效。但官方仍强调——即使如此，扩展也已经写入了 SSH key、装好了持久化、并把主机信息发了出去，无论结果如何都要按流程处置。
• 🔧 自查一行命令（macOS）：grep -qs svc-telemetry ~/.ssh/authorized_keys && echo "svc-telemetry key found" || echo "No key found; machine not impacted"。Windows 用 PowerShell 查 $HOME\.ssh\authorized_keys 与 C:\ProgramData\ssh\administrators_authorized_keys。
• 卸载扩展不等于清理干净：官方原文 "Uninstalling the extension may not be sufficient — the payload drops standalone persistence scripts that keep running." 官方提供了 macOS / Windows 两个修复脚本，并建议在可信系统上轮换凭据与会话。
• 官方处置：下架并阻断分发 → 出于慎重整个市场停摆 → 审计确认其它扩展未被篡改 → 轮换密钥、重建市场、恢复上线。

背景与分析

这次不是「模型被诱导」，是「分发通道被替换」

本站此前的 Agent 安全内容（提示注入、Agent 沙箱）讲的都是同一类威胁：模型读到不可信内容，被诱导去调用工具。这次的路径完全不同——模型一个字都没读错，AI 也没做任何判断。

攻击链是：拿到 Cursor 扩展市场的分发权限 → 在合法扩展 ID（anthropic.claude-code）下发布被改写的包 → 用户侧自动更新把它拉下来 → VS Code 加载扩展即执行。整条链上没有任何一个环节需要 AI 出错，也不需要用户点任何东西。

对开发者的直接含义是：你为「AI 会不会乱来」做的所有防护，都不覆盖这一类。权限白名单、沙箱、只读模式、人工确认——全都假设「跑起来的代码是官方那份」。这次被换掉的恰恰是这份代码本身。

版本号不能当真伪依据：2.1.312 是真实版本，2.1.313 不是

这是本站这次能补上的一个交叉验证点，值得单独写出来：

也就是说：2.1.312 在官方渠道是干净的、在市场里是脏的；2.1.313 在官方渠道根本不存在。 两条信息合起来给了一个可操作的判据——「我装的这个版本号官方有没有发过」是可以查的，而且比「看起来是不是最新版」可靠得多。本站一直坚持的「判版本是否存在用 /releases/tags/<tag> 的 404」，在这里从「写作纪律」变成了「安全自查手段」。

需要说明边界：这条判据只能发现「凭空多出来的版本号」，发现不了「真实版本号下的内容被替换」（2.1.312 就是这种情况）。要覆盖后者，得靠官方公告里给的 VSIX SHA-256 / 载荷 SHA-256。

时间线：从下架到「干净版本」只隔一天

两处需要分开读：① v2.1.314 是官方 GitHub Releases 的正常版本，本站核对过 tag 时间戳与 prerelease 字段；② Cursor 官方公告本身没有写「请升级到 2.1.314」这句话，「升级到 2.1.314」是第三方报道的转述。本站按「能查到的就写、查不到的标待核实」处理——升级到最新 stable 是合理动作，但「官方要求升到 2.1.314」这个说法本站未取得一手原文，列为待核实。

为什么「卸载重装」是错的处置

这条值得所有人记住：卸载扩展不会移除已经落盘的持久化脚本。载荷会往系统里放独立的东西——macOS 的 ~/Library/LaunchAgents/com.apple.sysmond.plist、Linux 的 cron @reboot、Windows 的计划任务 SysMon（并回退到启动目录的 sysmon.cmd）。这些不依赖扩展存在，关掉 IDE 也照样跑。

所以正确顺序是：先查 IoC → 能确认的隔离 → 按官方脚本清 key / 持久化 / 隧道进程 → 评估主机是否需要重建 → 在可信系统上轮换凭据。官方还特别点出一句：环境变量名的收集范围有限，并不排除后续通过后门拿到凭据——所以轮换这步不能省。

入侵指标（IoC，来自官方公告）

包哈希

网络

• 攻击者端点：134[.]209[.]82[.]225
• 反向 SSH：tunnel@134[.]209[.]82[.]225，TCP 22
• 外部 beacon：hxxp://134[.]209[.]82[.]225:8099/beacon（HTTP POST）
• 本地 beacon 尝试：127[.]0[.]0[.]1:8099/beacon
• 公网 IP 查询走 ifconfig[.]me / api[.]ipify[.]org——官方注明这是正常服务，仅访问本身不构成指标

文件与持久化

• Linux / macOS：~/.ssh/authorized_keys 中的未授权 key；~/.config/.smt、~/.config/.smtk
• Linux：/tmp/.stk_<10 hex>；cron @reboot /bin/sh "<HOME>/.config/.smt"
• macOS：$TMPDIR/.stk_<10 hex>；~/Library/LaunchAgents/com.apple.sysmond.plist（label com.apple.sysmond）
• Windows：%USERPROFILE%\.ssh\authorized_keys、%USERPROFILE%\.config\smt.cmd、%USERPROFILE%\.config\smtk、%TEMP%\.stk_<10 hex>；计划任务 SysMon；回退 %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\sysmon.cmd

命令行特征

• ssh -N -R '*:0:localhost:22'、autossh -M 0
• schtasks /create /tn SysMon
• systemsetup -setremotelogin on
• Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0

行动建议

1. 先自查再干活：跑上面那行 grep -qs svc-telemetry 命令（Windows 用 PowerShell 版本）。没装过 Cursor 扩展市场版 Claude Code 的，可以跳过——官方说这不涉及其它扩展与其它分发渠道。
2. 命中就按官方脚本处置：macOS 用 remediate-macos.sh（以受影响用户身份运行，不要用 root），Windows 用 remediate-windows.ps1（管理员权限 PowerShell）。脚本在残留未清完时会以非零状态退出。
3. 在可信系统上轮换凭据：能从这个主机拿到的 token、SSH key、云凭据都算。官方明确不排除后续凭据访问。
4. 别只卸载扩展：持久化脚本独立于扩展存在。
5. 组织侧加一条分发管控：这次的传播靠的是默认开启的自动更新。团队环境里评估「扩展自动更新是否该关、是否该锁定私有市场 / 允许列表」。关掉自动更新也有代价（安全补丁延迟），本站不建议一刀切，建议按「是否允许任意市场来源」而非「是否自动更新」来划线。
6. 把「版本号是否真实存在」加进日常核对：查 /releases/tags/<tag> 是否 404，成本几乎为零。

待核实

• 受影响用户数：第三方报道称 Cursor 给出「上限约 5,000 用户」的估计，并说明真实数字可能更低。本站未在 Cursor 官方公告正文中读到该数字，故正文不采用，仅在此列出。
• 官方是否要求升级到 v2.1.314：第三方报道如此转述，Cursor 公告正文未见该句。v2.1.314 于 2026-10-30T01:06:26Z 在 GitHub 官方 Releases 转正（本站一手核对），晚于暴露窗口结束——事实是清楚的，「官方要求」这一层未取得原文。
• 载荷注入方式的技术细节：第三方分析称是在合法 extension.js 前插入了一段加载器，并给出字节级比对。本站未取得这些分析的一手原文，故不作断言；官方公告只说「修改后的 extension.js 含 134[.]209[.]82[.]225 与 svc-telemetry」。
• 是否存在 Linux 受害者：官方公告列出的受影响平台是 Windows 与 macOS，但 IoC 段里有 Linux 的 cron 与 /tmp/.stk_* 条目。两者关系官方未说明，本站不作推断。
• 攻击者的初始入口（如何拿到市场分发权限）：官方公告未说明。

相关

• Claude Code 工具卡——官方 Releases 是判断版本真伪的一手渠道
• Cursor 工具卡——受影响的分发渠道
• 提示注入——本次事件不属于这一类，两相对照更容易理解边界
• Agent 沙箱——沙箱防的是「AI 越权」，防不了「分发被换包」
• OpenCode 工具卡——另一条供应链：双版本线（1.x / 2.x）并存时的取版本判据

AI 之家 观点

这次事件最该被记住的一句话是：AI 编码工具的安全边界，已经从「模型会不会做坏事」前移到了「你装的那份二进制是不是原版」。

过去两年大家讨论 Agent 安全，注意力几乎都在提示注入、权限粒度、沙箱强度上。这次的攻击链里，AI 从头到尾没有「犯错」——它甚至没参与。被攻破的是一个更传统、更枯燥、也因此更没人看的地方：扩展市场的分发权限。这是 2018–2021 年 npm / PyPI 投毒剧本的重演，只是换到了 AI 工具的分发通道上，而 AI 工具恰好同时具备「高频自动更新」和「本机高权限」两个放大器。

给开发团队的三条实操建议：第一，把「版本号是否真实存在」做成习惯动作，查一次 404 只要几秒，却能挡掉「凭空多出来的版本」这一整类；第二，默认开启的自动更新在团队环境里要重新评估——它同时是补丁通道和投毒通道，划线的位置应该是「来源是否可信」而不是「更不更新」；第三，别把这次读成「Cursor 不安全」或「Claude Code 不安全」——官方在约 11 小时内下架、全市场停摆审计、轮换密钥重建、配合托管商打掉 C2，一整套响应是合格的。真正的问题是所有集中式分发渠道都有这个风险面，与厂商是谁无关。