十二小时和五千台机器：那个不属于 Anthropic 的 Claude Code 扩展

周四的某个时候，躺在 Cursor 应用市场里的一个 Claude Code 扩展构建，不再是自己声称的那个东西。两个版本——2.1.312 和 2.1.313——带着一个持久化的 SSH 后门。它挂了将近十二个小时。Cursor 自己给出的受影响开发者数量是“最多 5,000 人”。

细节来自一天之内相继发出的一批安全文章：Step Security、Sophos、BleepingComputer、微软安全博客，还有 Ars Technica，后者把时间线梳理得最清楚。按这些报道，被改过的扩展做了后门该做的事——它开了一条重启之后依然存在的入口，这里是通过 SSH。The Verge 对这起事件的总结提到，载荷收集了主机名、用户名和 IP 地址。

这是短版。长版讲的是应用市场到底是什么，以及为什么这事早晚会发生。

被攻破的到底是什么

不是 Anthropic 的服务器。不是 Claude 模型。是一个分发渠道。

Claude Code 以 CLI 和编辑器扩展两种形式发布。Cursor 有自己的扩展市场，跟 VS Code 一样，而被做手脚的那个条目挂着官方 Claude Code 扩展的名头。对一个在编辑器里搜“claude code”的开发者来说，那个条目看着没毛病：名字对，图标对，描述对。

安装时跑的是一个被植入木马的构建。报道里描述的机制是一个持久化 SSH 后门——一处改动，让攻击者之后能通过 SSH 登进这台机器，不需要用户再做任何事。对一台开发者笔记本来说，这几乎是可能的最坏载荷。它不是那种会在活动监视器里露头的挖矿程序。它是一扇安静的门。

为什么开发者是理想目标

一台被攻破的开发者机器不只是一台笔记本。它是一组触达范围异常宽的凭证：私有仓库的源码、CI token、云密钥、某个打算三月清理却一直没清理的 .env 里的数据库连接串、在整批机器之间互相信任的 SSH 密钥。

SSH 后门特别适合这种环境，因为开发者机器本来就跑着 SSH，本来就有 authorized_keys 文件，本来就预期别的机器连进来。那个文件里多一把钥匙，不像一条通往陌生 IP 的新出站连接那样显眼。

再加上时间点：周四，工作日，很多团队正处在发布周期中间。窗口不长，但如果条目排在搜索结果靠前的位置，十二个小时足够几千次安装。

没人愿意明说的那部分

扩展市场不是消费者理解的那种应用商店。它们更接近包仓库。有审核流程，但流程的取向是在提交时抓明显恶意行为，而不是持续核实发布者还是不是那个发布者、二进制还是不是那个二进制。

这不是 Cursor 独有的失败。这是每一个允许第三方发布以完整本地权限运行的代码的生态的结构性弱点：npm、PyPI、VS Code 扩展、浏览器扩展，以及现在围绕 AI 编码工具长出来的这些市场。攻击面不是模型。是安装器。

这个案子之所以值得注意，是因为它的品牌。一个以知名 AI 产品命名的扩展，出现在一个大多数用户正在找那个产品的市场里，是一条很难防的信任捷径。名字本身就完成了社工。

回应长什么样

条目下架了，Cursor 公布了一个用户数。安全厂商公布了指标。按报道，Anthropic 不是发出坏构建的那一方——Cursor 市场上的那个扩展，跟 Anthropic 自己的分发渠道是两回事。

这个区分对追责有用，对风险没用。从一个开发者的视角看，“我在编辑器里的市场装了 Claude Code 扩展”是一个动作，它背后的监管链是看不见的。

这一周该做什么

如果你用 Cursor，或者任何带第三方市场的编辑器，这周适合做三件无聊的事。

第一，列出已安装的扩展，检查发布者。不是名字——是发布者，最好还有安装来源。任何你不认识的，删掉。任何跟你已经从第一方拿到的东西功能重复的，删掉。

第二，检查开发机上的 ~/.ssh/authorized_keys。你要找的是不认识的钥匙。在一台只往外连的笔记本上，这个文件经常是空的或者根本不存在，所以一条意外的条目很容易看出来。

第三，轮换那台机器能够到的凭证。这一步最贵，也是最容易被跳过的。如果你没法全部轮换，就轮换最疼的那些：云厂商密钥、包仓库 token，以及任何对生产仓库有写权限的东西。

团队再加一条：固定扩展版本，从一份审过的清单安装，而不是让每个人自己装搜索排名靠前的。这条策略大多数团队对 npm 依赖已经有了，对编辑器插件几乎没有。

为什么半天没人发现

十二小时绝对值上不长，但放在一个分发渠道的生命里，非常长。在那个窗口里，这个扩展可安装，可安装意味着可执行，可执行意味着每个在工作日点了安装的开发者都可能暴露。

值得注意的是，发现来自外部。盯着可疑行为的安全厂商标记了它；市场没有。这不是在挑 Cursor 的刺——这些生态就是这么运转的。仓库为可用性优化，不为对它托管的每一个产物做持续行为监控。实时扫描每一个扩展的每一次更新的经济账非常难看，而在出事之前，做这件事的动力很弱。

恢复比发现快。条目下架，公告发布，指标共享。但顺序很重要：先暴露，后解释。对在窗口期内安装的人来说，有用的信息是在那个要紧的决定之后才到的。

不舒服的结论

AI 编码工具这个赛道两年都在比能力：上下文窗口、agent 循环、这东西能改多少个文件还不跑偏。它几乎没花时间比供应链完整性，因为在此之前，威胁模型一直是“模型会写出烂代码”，不是“扩展是恶意软件”。

按过去十年软件供应链攻击的标准，五千台机器、十二个小时，是个小事件。它同时也是一个预演。下一个会是某个 MCP server，或者一个 skill 包，或者一个热门 agent 按名字推荐的插件。模式一样：一个可信的名字，一个验证很轻的分发渠道，一个不需要大声的载荷。

教训不是“别用扩展”。教训是，市场条目上的“官方”几乎什么也不代表，而唯一能规模化的防御，是用你对待一个从没听过的包执行 npm install 时那种怀疑，去对待编辑器插件。