$ 橙序员

Cursor插件被投毒：不显式调用，恶意代码照样跑

10 月 29 日，Cursor 扩展商店里的 Claude Code 插件 2.1.313 版本被整包替换成恶意安装包，上架约 11 小时后才被下架。Cursor 称最多约 5000 名用户受影响。

据安全研究者披露，黑客只改了插件里的一个文件——在正常代码前面插了 66 行恶意程序，插件界面和功能看起来完全正常。

这件事真正值得警惕的地方，倒不是“第三方插件不可信”这句老话。是大多数开发者对 IDE 插件有一个根深蒂固的错觉：我没调用它，它就不会运行。

这次事件把这个错觉打穿了。

# “装上不用”不构成防线

按披露的说法，只要 Cursor 加载了这个插件，那 66 行恶意代码就会执行，不需要用户主动打开或使用 Claude Code。

从机制上看，这意味着扩展宿主在加载阶段就执行了插件入口，模块顶层代码随文件加载而求值。“按需激活”约束的是功能调用，不是入口代码执行。

换句话说，安装插件这个动作本身，就等于把一段可执行代码交给了宿主。你装完不用、甚至忘了它存在，代码该跑还是跑。

这不是某个插件的问题，而是权限模型的问题：安装即赋权，加载即执行。 而用户在这一步看不到任何权限提示。

# 11 小时窗口暴露了什么

版本号没变，包被整体替换，从上架到下架约 11 小时。至于 Cursor 商店的审核、签名校验、差分比对和恶意包扫描策略，公开材料没有披露细节，不能替平台下结论。

但有一条可以确认：一条整包替换路径在这 11 小时里没有被拦住。

至少两个机制环节值得追问：

第一，发布者与包内容是否绑定校验？ 如果签名跟发布者绑定、内容一改就失效，整包替换应该在上架环节就暴露。这次没有。

第二，插件加载阶段能做什么？ 披露的行为显示，恶意代码可以访问文件系统、写入 SSH 授权文件、安装开机自启脚本。宿主没有把它限制在插件声明的功能范围内。

这里得把边界说清楚：公开材料只支持“约 11 小时内未被拦下”这个事实，不能写成“商店没有签名校验”或“没有恶意包扫描”——那是没有证据的断言。但机制缺口确实存在，方向值得追问。

# 平台能做的，止于云端

Cursor 的处置动作是下架恶意版本、一度关闭整个扩展商店、轮换密钥、重建服务。商店已恢复，攻击者服务器已关停。

Cursor 同时声明：该恶意版本不是 Anthropic 开发的，未发现其他插件被篡改，也没有证据表明 Anthropic 官方分发的版本受到影响。

这些动作全部发生在分发侧——把坏包拿走，换掉自己的密钥。它们触及不到已经写进用户机器的东西：SSH 授权文件里多出来的那行公钥、开机自启的后台脚本、已经发出去的设备信息。

# 清理成本，落到了开发者头上

Cursor 说得很明确：受影响用户不能只卸载插件，恶意脚本可能继续留在电脑里运行。官方提供了清理工具，并建议检查 SSH 授权文件中是否出现 svc-telemetry。

受影响的人要做的也不止卸载：跑清理工具、检查 SSH 授权文件、排查开机自启项和异常外联、轮换可能暴露的凭证。恶意程序还安装了每约 60 秒重连攻击者服务器的后台脚本，这些本地痕迹不会随卸载消失。

如果这台机器属于公司，还得回答：影响范围有多大？谁来负责取证？谁来证明没泄露？——这些没有既定规则。

有一个前提得说清楚：多数 Mac 和 Windows 开启 SSH 远程登录需要管理员权限，这一步通常会失败。 远程控制是条件性风险，不是既成事实。

但失败不等于无事。密钥可能已经写入，自启脚本可能已经安装，电脑名称、Git 邮箱、公网 IP 可能已经被收集。不能把“远程登录没成功”读成“没什么损失”。

# 版本回滚救不了本地副作用

回滚能把插件恢复到已知安全的版本，阻止下次加载继续执行恶意代码。

但已经写进 authorized_keys 的密钥、已经安装的自启脚本、已经发出去的设备信息，不会跟着回滚。

这不是平台“不想管”，而是能力边界：平台可以换掉自己的密钥，却没法在云端替几千台电脑删掉一行授权记录。

清理成本落在用户头上，不是公关选择，是架构决定的。

# 编程选插件该看什么

判断依据只有一条：安装就是授权执行。

选型时看三件事：

• › 能否验证发布者与版本
• › 权限能否收窄到声明范围
• › 出问题能否回滚到确定版本

团队层面，插件白名单和版本锁定应该从“图方便”变成默认配置。

这次事件里，分发方止于下架与轮换自身密钥，上游以非官方开发为由划清界限，攻击者服务器关停但身份未公开。清理、取证、证明影响范围的活，最终落在装了 2.1.313 的开发者身上。

只要可验证的版本回滚、加载阶段的权限约束、签名与包内容绑定校验仍然缺位，“装上即全权执行、出事自己收拾”的结构就不会变。下一次，只是换一个插件名而已。