Cursor插件被篡改,先核对这3件事

Cursor插件被篡改，先核对这3件事

对靠 AI 做网页、搭小系统的人来说，这条新闻有点扎心：你可能连一行代码都没手写过，却已经要面对开发工具的安全问题。

我更担心的是另一种情况：看到熟悉的名字，就默认装进去的一定是熟悉的东西。

这次需要核对的，恰恰是这个默认。

同一个插件名，下载来源也得对上

Cursor 在 10 月 29 日发布安全通报，后来补充了受影响版本：其扩展市场出现了被恶意修改的 Claude Code 扩展，版本为 2.1.312 和 2.1.313，涉及 macOS 和 Windows。[1]

微软 10 月 30 日的分析确认，这些恶意包没有经由微软的 Visual Studio Marketplace 和官方 npm 分发渠道发布；Anthropic 告知微软，其系统未被攻破，也没有开发这些恶意包。[2]

所以，只看到“Claude Code 出事了”这几个字，信息还不够用。把产品名直接等同于安装包，会把不同来源混成一件事。

通报窗口是美国太平洋时间 10 月 29 日 02:27—13:35，换成北京时间是 10 月 29 日 17:27 至 10 月 30 日 04:35。这一步很容易看错日期。[1]

不符合这些条件，不能凭这则新闻断定自己受了影响；符合条件，也还要结合安装记录和运行痕迹继续确认。

插件删掉了，留下的东西还要查

这次事件最值得普通使用者理解的，是“插件”和“它运行过的动作”之间的区别。

微软分析发现，恶意代码会尝试建立 SSH 远程访问、配置启动时继续运行的机制，并报告主机信息。有些文件写在扩展目录之外，因此删除或升级扩展，不能替代后续排查。[2]

可以把它理解成：你请走了一个人，还要核对他有没有留下门禁权限。人走了，是一个动作；权限收回了，是另一项检查。这个比喻解释的是处理顺序，并不代表每台安装过插件的电脑都已被远程控制。

也别把“出现了某个后台进程”直接理解成“黑客已经拿走所有东西”。微软特别区分了代码尝试执行的步骤和实际成功的结果。它还指出，样本收集到的相关环境变量是名称，不能据此断言其中保存的密钥值已被窃取。[2]

处理要认真，结论要有证据。

不会看日志，也可以先整理好问题

假设你是一个三人小团队的负责人，工具是自己装的，项目是让 AI 一步步搭起来的。你现在不需要临时把自己训练成安全工程师。

先写一张能交接的记录，比着急搜一条“万能清理命令”更有用。

这张记录可以很简单：电脑系统是什么，插件从哪里装，记得哪天更新过，能否找到安装记录，机器上当时在做什么项目。拿不准的地方直接写“不确定”，别凭记忆补成确定答案。

上面是为了说明沟通方式的假设对话。它想解决一个常见的交接问题：你说“帮我看看有没有中招”，对方还得重新问一遍背景；你把来源、版本和时间先整理好，对方才能更快判断下一步查哪里。

如果你已经找到可疑执行痕迹，按官方通报的流程处理：隔离受影响设备、保留证据、清理确认的恶意项目，并从可信设备处理相关凭证和会话。[1]

不要因为一个文件名字看着眼熟，就把同类文件全删掉。微软的处理建议强调核对具体动作、保留合法 SSH 配置；缺少某一个标记，也不能替代其他证据检查。[2]

以后装工具，多留一份能追溯的记录

我的建议是，给小团队加一个很轻的习惯：安装重要插件时，顺手记下来源链接、版本号和安装日期。

它不需要变成一份繁琐的表格。项目文件夹里放一页工具记录就够了，谁装的谁补一句，换版本时再加一行。发生问题时，你能回答“当时用了什么”，这份记录就有价值。

对于刚尝试的新工具，我更倾向于先拿练习项目验证用途，再决定是否放进正式工作。演示做得漂亮，和适合接触自己的业务资料，是两次不同的判断。

这些习惯不能保证挡住所有恶意包，也不意味着正规市场永远不会出问题。这次事件本身就提醒了我们，熟悉的入口同样需要事后核验。

继续用AI，把确认这一步补上

Cursor 通报称，恶意版本已移除，攻击服务器已被下线；它也提醒，即便多数设备上的 SSH 接入尝试因权限等原因失败，仍应按通报完成相应检查。[1]

我不会据此建议所有人停用 AI 编程工具。对普通使用者，更实际的改变是：把“它能帮我做什么”和“我从哪里装了什么”一起放进工作习惯。

如果你正在用 Cursor，先核对来源、版本和时间。暂时查不清，也别给自己出具一张“肯定没事”的证明。

你给团队留下过插件安装记录吗？可以从今天装的下一个工具开始。