一句话：你装的是正牌扩展，它却带着别人的钥匙。2026 年 10 月 29 日，Cursor 插件市场里一个挂着官方 ID 的 Claude Code 扩展被塞进了 SSH 后门，在架约 11 小时。下面按「发生了什么、怎么进来的、为什么挑开发者、怎么自查、我信不信这个说法」五步拆。
一句话：发生了什么
先把事实摆齐。被投毒的是扩展 anthropic.claude-code，版本 2.1.312 和 2.1.313，不是拼错名字的仿冒品。据 Cursor 公告，这两个版本在市场上停留约 11 小时，窗口大约从太平洋时间 02:27 到 13:35，最多约 5000 名用户下载。
划重点：Cursor 声明这两个版本并非 Anthropic 开发。Anthropic 员工 Felix Rieseberg 的说法是，Anthropic 的系统和员工电脑都没被攻破，是有人借 Cursor 市场的发布权限，把一份被篡改的副本放了上去——而发布权限这一环，恰恰是最少被审计的一环。
受影响范围也说清楚了：官方渠道没被牵连，Open VSX 和微软 VS Code 市场都正常，中招的只有从 Cursor 市场装扩展的 Cursor 用户。说白了是一次「借壳」——攻击者没黑进 Anthropic，黑的是下游的发布环节。官方 ID 的信用，被下游平台的权限借走了。
细节较真：两个版本号只差一位，像同一批货分两次推的；窗口又卡在凌晨到午后。趁用户睡觉时上架，等市场反应过来才收手——这是我的读法，时间选得并不随意。11 小时也不算短，够一个上班族开机、打开编辑器、把扩展装上，而这期间没有任何提示告诉他版本不对。
后门是怎么装进去的
据 Cursor 公告，恶意代码被插在 extension.js 开头，扩展一加载就执行，不需要你点任何按钮。它先收集主机信息：主机名、用户名、系统、架构、工作目录、Git 邮箱、公网 IP，外加最多 40 个敏感环境变量名。这一步发生在扩展被激活的时候，仍然不需要用户交互。
然后是钥匙和隧道：往 authorized_keys 里追加攻击者的 SSH 公钥，标签 svc-telemetry；再试着开 SSH 服务，朝 134.209.82.225 建反向隧道，每 60 秒重试一次。反向隧道的意思是，连接由被感染的机器主动往外发起，防火墙一般不会拦。
持久化另铺一套：macOS 装 LaunchAgent com.apple.sysmond；Windows 建 SysMon 计划任务，再塞一个 sysmon.cmd 启动项。这几个名字后面自查都要用，记一下。持久化的作用不用多解释：删了扩展它还在，重启电脑它还在。
划重点：整条链路不需要用户做任何操作，装完打开编辑器就触发。对数字较真一下：40 是上限不是定值，回传的是变量名；60 秒是重试节奏，一分钟一次，慢到不惊动告警，勤到只要机器在线就有机会。写代码的人不赶时间，这套代码也不是捞一把就走的路数。
为什么专挑开发者的电脑
答案就写在那份收集清单里：Git 邮箱、工作目录、公网 IP、几十个环境变量名。开发机上这些位置常年躺着云厂商密钥、数据库连接串、CI 的 Token，这台机器等于一串金库钥匙的挂架。单看都不值钱，凑一起就是一张进生产环境的通行证。
划重点：攻击者要的不是你的照片，是「能碰到生产系统的那台电脑」。开发机通常对 GitHub、云控制台和 CI 有免密或缓存凭证，而控制台的临时凭证，往往能直接改生产环境的配置。说白了，它半只脚已经踩在服务器里。
更能说明问题的是身份：扩展 ID 是官方的，平台 11 小时后才下架。据 Cursor 公告，市场随后整体暂停做审计、轮换全部密钥才重开。审核没拦住「官方 ID + 改过的代码」这个组合，这件事本身比 5000 这个数字更值得记。
说白了，开发者是离代码和密钥最近的一群人，也是供应链上最容易被顺手牵羊的一环。挑这个人群下手，不是巧合，是算过的。下次有人问「插件市场的扩展要不要装」，我会先反问一句：你信得过那个市场的发布权限吗？
中招了该做什么，三步
先给结论：卸载扩展、升级到干净版本，都清不掉后门。据 Cursor 公告，已经写进 authorized_keys 的钥匙、已经装好的持久化项，不会随卸载消失。你删掉的是入口，不是进屋的人。
第一步，查。看 ~/.ssh/authorized_keys 里有没有标签 svc-telemetry 的公钥，再看有没有连着 134.209.82.225 的 SSH 隧道进程。别只看有没有活动连接，那份文件末尾多出来的行，同样要盯。
同一个「查」字下还有第二处：macOS 翻 LaunchAgents 找 com.apple.sysmond，Windows 查 SysMon 计划任务和 sysmon.cmd 启动项。这三个名字就是这次事件的指纹，对上了基本就不用再往下猜。
第二步，清。删钥匙、删持久化项、杀隧道进程，把 SSH 配置改回原样。第三步，轮换。这台机器能碰到的凭据全部作废重发：云密钥、GitHub Token、数据库密码，一个都别留。顺序是查、清、轮换，别颠倒——先换密码再清后门，等于把新钥匙递给还蹲在屋里的人。
我的判断：这次运气有多好
判断一：这次破坏本来可以大得多。据安全公司 Phorion 分析，恶意代码本身有实现瑕疵，多数 macOS 和 Windows 主机上 SSH 根本没开成，反向隧道没建起来，木马是半瘫的。Phorion 的 CEO 说得更直白：大家运气好。换句话说，刹车是对方自己踩的。
判断二：这个数字值得再打个问号。「最多 5000」是 Cursor 早期的口径，修订后的公告不再给具体人数。我的读法是，撤回一个已经放出去的上限，说明平台方自己也没把握——11 小时里到底装出去多少，目前只有他们内部清楚。这不像刻意缩水，更像他们也没算清。
判断三：「查三样东西」别当万能解。这次能自查，是因为后门落在磁盘上、有名字可查；要是下一版把钥匙藏进内存，或者干脆伪装成正常依赖去跑，你连该查什么都不知道。换句话说，能被自查的后门，已经算比较客气的那一种。
但这里有个前提：这次「运气好」，靠的是攻击者代码写漏了，不是靠平台拦住了。要是下一版把开 SSH 那步写对，或者换成不需要落地的打法，同样 11 小时、同样一个官方 ID，代价就不是今天的量级。到那时候，你打算拿什么自查？
