公司电脑上装 AI 编程插件，先看一眼版本号：有人装到了被改过的那一版

下午四点，扩展面板里 Anthropic.claude-code 这一行写着 2.1.313。这个版本号不该出现在任何一台公司电脑上。

10 月 29 日，Cursor 在自己博客上挂了一份安全公告。同日，它的 VS Code 扩展市场里上架过一个被人改过的同名扩展，版本号正是 2.1.312 和 2.1.313。按公告的写法，这两个版本不是 Anthropic 开发的，受影响的是 Windows 和 macOS 两个平台的版本。

时间窗不长。太平洋时间 10 月 29 日凌晨 2 点 27 分到下午 1 点 35 分，按夏令时换算成北京时间，是当天 17 点 27 分到第二天 4 点 35 分。

这段描述里最容易漏掉的一句，是扩展会自动更新。Cognition 在 11 月 3 日的安全随笔里点到了这一层，用户可能什么都没做，更新就自己到了机器上。

它到底在机器上做了什么

公告列了三项行为。

- 收集主机和用户信息。主机名和用户名，操作系统与架构，主目录路径，环境变量名称，工作目录，配置好的 Git 邮箱，还有公网 IP。

- 尝试把攻击者控制的 SSH 公钥写进 authorized_keys，打开本机的 SSH 服务，再建立一条反向隧道。

- 用 macOS 的 LaunchAgent 或者 Windows 的计划任务，让这条隧道长期生效，后台脚本大约每 60 秒重试一次。

公告后面的入侵指标还写了另一件事，扩展目录里的 extension.js 带着攻击者服务器的地址，会持续向那台机器的 8099 端口发信标。

第二项在多数机器上会失败。开 SSH 服务需要管理员权限，扩展通常没有；公告还提到，恶意代码本身存在错误，除非 Cursor 是以管理员权限启动的，这一步就过不去。

另外两项已经发生了。公钥被写进去了，持久化机制装上了，主机信息也发出去了。公告给的处理意见很直白，无论如何都请按修复步骤走一遍，因为仅卸载扩展可能不够。

官方当时做了什么

发现之后，公告列了四步处置。下架恶意版本并阻止继续分发。出于审慎，随后把整个扩展市场关掉。审计访问记录，确认没有其他扩展被篡改。轮换密钥，重建市场，再上线。

攻击者的服务器也已经停了。公告说，他们与托管该服务器的云服务提供商合作把它下线，并向该服务器阻断了连接，反向 shell 和主机信息上报都已失效。

这份公告还在 10 月 30 日上午更新过一次，补了入侵指标，也把受影响版本写清楚了。第一版口径和后来那版不完全一样，读这类公告要读到最末的更新时间。

规模这件事要分开说。公告正文没有给数量。Cognition 那篇写的是，Cursor 的对外口径是不到 5000 名用户安装了这个恶意版本。这是个总量，没有国别，也没有行业分布。能说的是千级，不能推成你们行业有多少家。

还有一层更值得留意。Cognition 提到，这次上架的扩展版本与 Open VSX 上发布的那一版不同，据此推测攻击者打穿了 Open VSX 下游的发布环节。也就是说，名义上正规的分发链路本身出了问题。

先查自己这台

第一条查有没有被塞进陌生的钥匙。macOS 上打开终端，跑这一行，有输出就说明那把键还在。

grep -s svc-telemetry ~/.ssh/authorized_keys

Windows 上打开 PowerShell，查两个位置，一个是用户目录下的 authorized_keys，一个是系统目录里的 administrators_authorized_keys，看里面有没有同样标记的那把键。

第二条查版本号。打开扩展面板，找到 Anthropic.claude-code，看它现在是哪个版本。面板里通常只看得到当前版本，看不到安装时间；要看时间，去扩展目录看文件修改时间，时间对得上就提高怀疑等级，但不能只凭时间戳断定是哪天装上的。

查到那把键，说明这台机器已经受影响。公告给了 macOS 和 Windows 两套修复脚本。它会删掉恶意扩展和持久化机制，停掉正在运行的隧道进程，再清掉攻击者那把公钥。有残留时脚本会以非零状态退出。公告同时建议隔离有后门迹象的主机，并在可信系统上轮换这台机器能碰到的凭据和会话。

手查也行。公钥要删，macOS 上还要看 ~/Library/LaunchAgents 里有没有一个叫 com.apple.sysmond 的条目，Windows 上要看计划任务里有没有 SysMon，以及启动目录里有没有 sysmon.cmd。

修复完之后还有三件事

卸掉扩展只是第一步。公告自己写了一句，仅卸载可能不够，因为这份载荷会在卸载之后继续跑一段时间。做过修复的机器，还得补三件事。

轮换这台机器能碰到的凭据。哪些算能碰到，看它上面存过什么。代码仓库的登录令牌，云平台的密钥，公司内部的几个后台账号，还有这台机器自己的 SSH 私钥。凭据换过，之前泄露的那份就作废了。

查这台机器最近有没有异常动作。有没有人从外部登录过这台机器，有没有陌生进程在跑那条隧道，本机的 SSH 服务是不是被打开过。这几项看日志比看扩展面板有用。

通知用到这台机器的人。开发机常常是共用的，有人拿它跑构建，有人拿它连测试库。凭据换了、服务关了，得让这些人知道，否则他会拿着旧密码一直试。

没查到，也不代表这件事和你无关

这条公告真正值得记住的地方，是它把一条老路径摊开了。装一个插件，等于让一份别人写的代码在你的账号权限下运行。而这份代码是不是官方，光看渠道已经不够，这次的恶意包就上架在官方市场里。

Cognition 那篇随笔说的是同一个意思。压垮系统的往往还是没打补丁的服务器和被偷走的凭据，那些老办法一直有效。AI 让攻击变快也变便宜，但它没办法替你关掉一条你自己留着的门。

所以这一轮能落到公司里的动作，是几张能填的格子。

- 谁有权在办公电脑上装插件。市场里搜到就装，还是走一次申请。

- 装之前核什么。发布者账号是不是官方，版本号对不对，插件要哪些权限。

- 装完核什么。上面那两条命令，谁跑，跑完结果记在哪儿。

- 谁能上管理员权限。这一步决定了后门能不能真的立起来。

- 出事找谁。公告页在哪儿，内部安全联系人是谁，能不能一键断网。

这类事为什么总落在开发机上。开发机权限高，装的东西杂，很多公司把它当成一台可以随便折腾的机器。恰恰是这台机器上放着能进仓库、能进云平台的钥匙。

这份清单看起来像在管一件小事。它管的其实是权限，而权限是这次唯一真正起作用的那一环。

本文素材来自官方安全公告和公开的安全技术文章，观点与整理是学窝自己的。