Cursor市场现篡改版Claude Code藏SSH后门

2026年10月29日，AI代码编辑器Cursor的扩展市场里出现了一件让开发者后背发凉的事：带有Anthropic官方标识符（anthropic.claude-code）的Claude Code扩展2.1.312与2.1.313版本，被植入了持久化的SSH后门。在太平洋时间当天凌晨2点27分至下午1点35分（UTC时间09:27至20:35）的大约11个小时里，这批遭篡改的扩展包直接面向macOS和Windows用户分发，据 Cursor 称最多约 5000 名用户受影响（Help Net Security）。

这场风波的核心矛盾在于：开发者安装的既不是山寨仿冒插件，也不是从钓鱼网站下载的未知脚本，而是直接从编辑器内置市场拉取、顶着官方正版ID的常规版本更新。当开发者为了提升写代码的效率，把可接触开发凭证与本地执行环境的终端交给了具备当前用户权限的AI编程工具和自动更新机制，原本用来核对身份的“发布者名称与官方标识符”防线，为什么没能挡住后门？

顶着官方ID的恶意扩展，到底是从哪条渠道流出来的？

根据Cursor发布的安全公告以及StepSecurity的供应链事件分析报告，此次遭篡改的是Claude Code扩展的2.1.312和2.1.313版本。Anthropic与Cursor双方均在正式声明中确认，这批恶意构建版本并非由Anthropic开发或发布。Anthropic表示，攻击者是利用了对Cursor扩展市场的访问权限，将重新打包的篡改版扩展发布到了该市场上；Anthropic自身的内部系统、员工电脑以及官方分发渠道均未在此次事件中失守。

微软威胁情报团队（Microsoft Threat Intelligence）在技术通报中证实，Cursor扩展市场中出现的这批恶意软件包，从未通过微软官方的Visual Studio Marketplace或npm官方包（@anthropic-ai/claude-code）发布或分发，后两条渠道未受波及。

为什么同样是用VS Code架构的编辑器，微软官方商城没事，Cursor的市场却出了问题？这与开源编辑器的生态底座直接相关。安全报道与研究人员的分析显示，微软默认的Visual Studio Marketplace在服务条款中限制仅允许微软自家的产品接入；因此，基于开源VS Code代码库构建的第三方AI编辑器（如Cursor和Windsurf），无法直接调用微软官方商城，必须依赖由Eclipse基金会运营的开源扩展市场Open VSX，或是维护自身的扩展市场分发体系。

关于Open VSX本身是否在此次事件中被污染，安全界存在不同说法：macOS安全厂商Phorion的研究人员称在Open VSX上发现了恶意的2.1.313版本，但安全机构Manifold Security的研究主管Ax Sharma则对“Open VSX版本同样遭入侵”的说法提出异议，指出此次事件是Cursor自身市场中的官方Claude Code扩展条目被投毒。StepSecurity其后援引Anthropic的说明称，2.1.313从未发布到Open VSX，Open VSX上的2.1.312经其下载核验是干净版本。不过，第三方扩展市场底层的凭证安全早已亮过红灯——云安全机构Wiz此前的研究报告曾披露，研究人员在VS Code Marketplace或Open VSX的扩展包内部发现了超过30个泄露的Open VSX访问令牌（Access Tokens），其中部分个人访问令牌（PAT）在被发现时依然有效。

事发后，Cursor下架了恶意版本，预防性关闭了其VS Code扩展市场，并在完成访问审计、确认没有其他扩展被篡改后，轮换了密钥并重建恢复了市场运行。Cursor同时声明，该事件未影响其市场上的其他扩展，也未波及Grok Bot、Grok或旗下的其他SpaceXSI产品。

不点开对话框就会中招：这7KB的恶意代码在后台干了什么？

很多开发者的第一反应是：“我那天虽然更新了插件，但并没有打开Claude对话框写代码，是不是就安全了？”答案是否定的。

根据StepSecurity披露的沙箱遥测与文件比对数据，这版恶意构建除了核心的extension.js文件被塞入了一段小型自包含加载器外，其余部分与官方正版一模一样，包含了正常的Claude Code与VS Code字符串、标准的激活（activate）与停用（deactivate）导出函数以及界面代码。以2.1.313版本为例，被篡改的extension.js文件大小为3,692,922字节（SHA-256哈希值为ecb58cb29078d9646ad1dcdbe51526f2d9cfea06be5fb2ab183e8ecc3ab6bf15），仅比前一个干净版本大了大约7KB。

Phorion首席执行官Calum Hall在技术分析中解释了这段代码的触发逻辑：攻击者把一段立即调用函数表达式（IIFE）直接拼接到了压缩后的扩展代码包最前面。如果把正常的扩展程序比作一间需要刷卡按开关才会通电运作的办公室，那么攻击者的做法，就是把窃听器直接焊在了大楼的总电闸进线端——只要Node.js一加载这个文件，甚至在扩展程序正常的activate回调函数还没来得及运行、无需调用任何VS Code API、也不需要用户发起任何Claude对话的情况下，这段前置代码就已经调用Node.js的标准模块（child_process、fs、os、path、http与crypto）在后台跑起来了。

一旦执行，这段恶意载荷会干三件事：

第一，摸清家底并回传信标。它会搜集受害机器的主机名、用户名、操作系统、主目录、当前工作目录、Git邮箱地址以及公网IP地址，通过端口8099发送HTTP信标回传给攻击者服务器（IP地址为134.209.82.225）。同时，它还会在机器上扫描名称看起来像密钥、令牌、密码或AWS、GCP云凭证的环境变量，将最多40个环境变量的“名称”打包发回。虽然环境变量的具体数值留在了本地机器上，但Calum Hall指出，这份清单相当于给攻击者递上了一份“资产盘点表”，让操控者一眼就能看出哪些开发机上攥着云端大权限或核心API令牌，从而决定优先对谁下手。

第二，配好钥匙并打通隧道。微软Defender XDR威胁分析与多家安全机构的拆解均确认，恶意代码会将攻击者控制的SSH公钥（带有svc-telemetry标签）写入用户的SSH授权密钥文件（authorized_keys）中，随后向攻击者服务器的22端口发起出站SSH连接，建立一条反向隧道。即便开发者关掉了编辑器，这条隧道依然在后台运行，且恶意程序大约每隔60秒就会重试一次连接。

第三，跨平台扎根。为了保证电脑重启后隧道不断，恶意程序针对不同系统定制了持久化驻留方案：在Mac上安装一个带有苹果风格命名的启动文件；在Linux上添加一条开机自启的cron定时任务；在Windows上则尝试创建名为SysMon的计划任务，如果创建失败就退而求其次写入启动（Startup）文件夹。

为什么一个脚本写错的“乌龙”，意外帮不少Mac用户挡了一劫？

在这场精心设计的供应链投毒里，出现了一个颇具戏剧性的技术细节：植入的SSH密钥要想真正让攻击者登进来，前提是受害者电脑上的SSH服务处于开启状态；而在许多macOS电脑上，恶意脚本用来强行开启SSH服务的那一步，压根就没有执行。

Phorion的研究人员顺着代码排查，发现攻击者写下了一个低级的逻辑错误。在macOS上，恶意脚本会先向系统查询“远程登录（Remote Login）”是否处于关闭状态。然而，查询这个状态需要管理员（Administrator）权限，而扩展程序在普通用户权限下运行时没有这个权限，系统自然返回了一条报错信息。滑稽的是，恶意脚本看到报错后，直接跳过了后面尝试开启SSH服务的步骤。

Cursor也在安全通知中提到，在大多数Mac和Windows主机上，开启SSH服务需要扩展程序并不具备的管理员权限，因此在这些机器上，攻击者无法直接通过该隧道登录。随后，Cursor联合托管攻击者服务器的云服务商，将该恶意服务器下线，切断了反向隧道与数据回传通道。

但这并不意味着中招的开发者可以高枕无忧。Calum Hall警告，攻击者代码的这个Bug绝不能当成防御屏障——如果一台Mac原本就已经开启了“远程登录”，或者开发者在日后因工作需要手动打开了它，植入的密钥与驻留组件仍构成持续风险，不能因为当前SSH服务未开启或攻击者服务器已被下线就免于清理。此外，由于载荷释放的是独立运行的驻留脚本，单纯在编辑器里点击“卸载扩展”，根本无法清除已经种下的后门。

卸载插件也清不掉后门，开发者该如何自查与止损？

根据StepSecurity整理的技术排查指南，仅仅在电脑上看到安装了2.1.312或2.1.313版本，并不自动等于机器已经沦陷。是否真正受影响，取决于下载来源与时间窗口——即是否在2026年10月29日太平洋时间02:27至13:35之间，从Cursor的VS Code扩展市场下载或更新了该版本。此外，沙箱遥测中出现的ifconfig.me、api.ipify.org等合法公网IP查询服务或常规微软基础设施连接，单独来看并不构成感染指标。

对于处于风险窗口期的开发者与企业安全团队，Phorion、Cursor与StepSecurity给出了明确的排查与清理路径：

核查SSH授权密钥：检查SSH的authorized_keys文件中是否存在标签为svc-telemetry的密钥条目。macOS用户需检查~/.ssh/authorized_keys；Windows用户需检查用户目录下的.ssh/authorized_keys以及C:\ProgramData\ssh\administrators_authorized_keys。一旦发现该密钥，即确认已受影响。
排查网络与文件痕迹：在终端、网络记录及已安装的extension.js文件中检索攻击者IP地址134.209.82.225、端口22的SSH连接、端口8099的HTTP信标以及恶意文件哈希值。若想确认攻击者是否曾通过后门实际登录过机器，Phorion建议检查系统SSH日志，查看是否存在使用svc-telemetry密钥从localhost（本地回环地址，即通过反向隧道）发起的登录记录。
隔离主机并执行专用清理脚本：发现中招迹象的机器应立即断网隔离并保留日志证据。由于手动卸载扩展无效，需运行Cursor官方发布的针对性清理脚本来移除恶意扩展、攻击者SSH密钥、持久化驻留项及正在运行的隧道进程。在macOS上，必须以受影响的用户身份（而非root身份）运行清理脚本；在Windows上，则需以管理员身份打开PowerShell运行。若脚本返回非零退出状态码，说明仍有残留项需要进一步清理。之后应从官方渠道重新安装2.1.314或更高版本的干净版本。
在可信设备上全量轮换凭证：尽管恶意程序最初只回传了环境变量的“名称”，但谁也无法排除攻击者此后通过后门读取过真实凭证。受影响的开发者必须在一台确认干净的可信设备上，将该开发机能够触达的所有源码库令牌、CI/CD令牌、云服务凭证（AWS/GCP等）、SSH密钥及包管理器注册表令牌全部作废重签，必要时直接重装构建整台开发机。

游仕观察

复盘整场事件，最值得软件工程团队警惕的，不是攻击者用了多么高深莫测的零日漏洞，恰恰是攻击手段的朴素与分发通道的失守。

Manifold Security的Ax Sharma点破了这次事件最扎心的地方：现场没有任何伪造和仿冒的痕迹可循。这就是Cursor自家市场里的官方Claude Code扩展，仅仅一个被污染的条目，就在半天之内让最多5000名开发者面临SSH后门风险。

过去十年，开发安全培训反复叮嘱程序员“看清发布者名字、不要装来路不明的插件、警惕拼写相似的李鬼包（Typosquatting）”。但在AI编程时代，这套靠人眼识别身份的经验正在失效：一方面，大量衍生编辑器由于微软商城接入条款限制，不得不搭建或依赖第三方镜像与开源扩展市场，拉长了从“官方源码”到“用户终端”的信任链条，例如发布凭证一旦泄露，真李逵的躯壳里就能塞进黑客的加载器；另一方面，如今安装和更新这些工具的往往是自动更新程序甚至AI智能体（Agents），而非人类自己。

当一位开发者的本机同时存放着公司代码库权限、云平台密钥和生产环境入口，而运行在上面的AI编程助手又拥有当前用户权限、能够直接接触本地开发凭证与执行环境时，开发机本身就已经成了整个企业安全防御中最脆弱、也最肥美的单点故障源。当“看出版商名字”不再管用，企业的安全防线恐怕只能退回到最冷酷的行为监控上——不管一个插件顶着谁的官方金字招牌，只要一个写代码的扩展程序敢在后台偷偷往系统里写SSH密钥，它就应该在几秒钟内被当场拦截。