Cursor 市场 Claude Code 扩展被植入木马
Cursor 市场中被篡改的 Claude Code 扩展向约 5000 名开发者推送了 SSH 后门。Anthropic 表示其自身系统未被触及。

Anthropic 被入侵了吗?这是今天早上每个安全团队的聊天群里都在讨论的问题,而就目前所能证实的情况来看,答案是否定的。真正发生的事情,对我们其他人来说某种程度上更糟:有人通过 Cursor 自家的市场,以 Anthropic 真实的发布者身份,推送了 Anthropic 官方 Claude Code 扩展的木马化更新,最多约 5000 名开发者安装了它。这并不需要攻破 Anthropic。信任模型白白替攻击者完成了工作。
恶意版本 2.1.313 携带了一个持久化的 SSH 后门,同时针对 Windows、macOS 和 Linux。据 The Hacker News 报道,它在 10 月 29 日于 Cursor 市场中潜伏了约 11 小时,即太平洋时间凌晨 2:27 至下午 1:35,之后 Cursor 关闭了整个市场以将其下架。Anthropic 随后已将干净的 2.1.314 发布到 Open VSX 和微软的 VS Code 市场,而这两个平台目前均未知受到影响。
这并不是 Anthropic 被入侵。但这远不如听起来那样令人安心。
Anthropic 迅速划清了界线。技术团队成员 Felix Rieseberg 表示,公司正在与 Cursor 合作,但“这并非对 Anthropic 系统或员工笔记本的入侵”,并补充称,一名恶意行为者利用了 Cursor 市场的访问权限,发布了 Anthropic 并未构建的篡改副本,The Register 报道称。Cursor 方面则表示,恶意版本“并非由 Anthropic 开发”,受影响用户最多约 5000 人。
好吧。但真正应该让你比归因问题更担心的是:攻击者根本不需要一个假扩展。他们以 2.1.313 版本的形式发布恶意软件,并使用了合法的扩展 ID anthropic.claude-code。Jenn Gile(OpenSourceMalware 联合创始人)告诉 The Hacker News,该软件包的主 JavaScript 包中,在合法代码之前插入了一段 66 行的恶意加载器。开发者可能采取的每一项检查,例如核对发布者、核对名称、确认是官方版本,都会通过。这不是 Cursor 的问题,也不是 Anthropic 的问题,而是市场模式在告诉你它的真实价值。
攻击者如何获得发布权限目前仍不清楚,Cursor 和 Anthropic 都没有给出解释。Cursor 表示,它在发现后移除了该软件包,出于“审慎考虑”关闭了市场,检查了其他扩展,轮换了自身密钥,并与一家云服务提供商合作封锁了攻击者的服务器。这些举措都很稳妥,但没有一项能回答:门首先是怎么打开的。
植入程序的实际行为,以及它的不足之处
这个载荷是一个完整的后门,而不是抓了就跑的窃密程序。在激活时,也就是 VS Code 启动后以及扩展的 webview 打开时,它会向受害者的 ~/.ssh/authorized_keys 中添加一个攻击者控制的密钥,并刻意命名为 svc-telemetry,让它看起来无关紧要。随后,它尝试在全部三个桌面平台上启用 SSH 访问,通过反向隧道连接到 134.209.82[.]225,并根据操作系统分别以计划任务、crontab 条目或 LaunchAgent 的形式建立持久化驻留,同时以未加密的 HTTP 方式,将主机侦察信息发送至 134.209.82[.]225:8099/beacon。
接下来这部分,其重要性远不如标题所暗示的那样。启用 SSH 服务需要管理员权限,而该扩展在大多数 macOS 和 Windows 主机上并不具备这一权限,Cursor 自己的分析也承认,隧道步骤在这些系统上失败了。因此,攻击者长驱直入五千台开发机器这一电影式的结局,大体上并未发生。但“大体上”承担了很大的分量。该植入程序仍然植入了密钥、建立了持久化驻留,并在运行的每台机器上回传了信息,而那些已经启用 SSH 的 Linux 桌面则是另一回事。Cursor 的建议很直接:无论如何都要按照修复步骤操作。还要注意一点:安装修复后的 2.1.314 并不会移除持久化驻留。如果你在问题窗口期内启用了自动更新,那你需要做的是清理,而不只是更新。
侦察清单显示了攻击者的目标所在:
- 公网 IP 地址(通过 api.ipify[.]org)、主机名和本地用户名
- 操作系统和 CPU 架构、主目录、工作目录
- 来自
git config --global user.email的全局 Git 邮箱 - 包含 KEY、TOKEN、SECRET、PASS、AWS 或 GCP 的最多 40 个环境变量名称
安全研究员 Paul McCarty 指出,初始信标中并未发送变量的值,但仅凭变量名称,就足以勾勒出受害者使用了哪些云服务商和 CI 系统,而一旦成功通过 SSH 访问,攻击者便可直接读取这些值。开发者机器就是凭证的“肥肉”。业内人士都心知肚明,攻击者也早已将其纳入预算。

五千名开发者,十一小时,一项自动更新设置
让我们来算一笔机会成本账,因为这正是你的董事会迟早会问的问题。十一小时的暴露时间,根据 Cursor 的说法,最多五千次安装。Gile 的观察最为致命:任何开启了扩展自动更新的人,都可能在恶意软件发布的那一刻就将其拉入。自动更新之所以成为大多数开发环境的默认配置,是因为我们集体认定,摩擦的代价高于风险。昨天,这笔账终于到期了。
而这笔账并非孤例。大约一周前,一名未知攻击者借助一名 OVH 正式贡献者被劫持的 GitHub 账户(该账户于三月被纳入 GlassWorm 行动),将 OVHcloud 官方 CLI 的五个已发布版本的发布二进制文件替换为窃取机密的恶意软件。我们也从另一个方向报道过同样的模式:LiteLLM 1.107.0 因被盗的 GitHub 令牌而遭植入后门,以及AI 编程代理仅凭“下载”文件夹中的一个文件就可能被操控。AI 工具供应链成为目标,并不是因为它很时髦,而是因为开发者以宽泛的凭证运行它,运行在能够触达一切的机器上,并且在更新时从不多看一眼。
修复成本低于事件本身
我的判断是:这次事件是可以挺过去的,但这类事件本身并不可以。攻击者在权限提升上出了纰漏,Cursor 迅速下架了软件包,影响范围被控制在数千人以内。但下一次,恶意加载器可能会检查是否已有正在运行的 SSH 服务,或者窗口期可能会持续整个周末。这些你都无法控制。你能控制的是:开发者的工具是否从一个你并不运营的注册中心自动更新,以及是否有人借助正确的访问权限,就能冒充其身份。
对于受影响的用户,修复路径已经明确:隔离主机,清除未经授权的 SSH 密钥和持久化机制,轮换凭证和会话。对于其他人而言,更划算的控制手段正是你一直在拖延的那一项:锁定扩展版本,在推送更新前进行审核,并将开发者工作站视为其本质所在的资产,即持有凭证、且与生产环境紧密相邻的资产。你下一次董事会会议上要回答的问题,不是 Anthropic 是否被入侵,而是为什么一个你并未签名的二进制文件,仍然能够落到一台持有你云端密钥的机器上。在别人先回答之前,请先回答这个问题。
来源
本文参考了以下报道与公告:


