10 月 29 日，Cursor 插件市场发生了一起值得开发者警惕的安全事件。

攻击者通过被篡改的 Anthropic Claude Code 扩展，将恶意代码植入插件，并借助正常的插件分发渠道传播。

根据目前提供的事件信息，受影响的扩展版本包括：

• 2.1.312
• 2.1.313

攻击程序试图收集主机信息、添加攻击者的 SSH 公钥，并建立能够长期维持的远程访问通道。

Cursor 表示，最多可能有 5,000 名用户受到影响。

这意味着，问题可能不只是安装了一个恶意插件，而是攻击者有机会进一步控制开发者的机器。

如果你在 10 月 29 日前后使用 Cursor 安装或更新过 Claude Code 扩展，建议花几分钟检查自己的 Mac。

注意：并不是所有 Cursor 用户都受到影响。只有在官方公告指定的时间窗口内，通过 Cursor 插件市场安装或更新到受影响版本的用户，才属于此次事件描述的风险范围。

一、这次攻击究竟发生了什么？

很多开发者可能会有一个疑问：

我安装的是 Anthropic 的 Claude Code 扩展，为什么会出现安全问题？

这里需要理解一个概念：

软件供应链攻击（Software Supply Chain Attack）。

简单来说，攻击者不一定直接攻击软件开发商，也不一定需要攻破用户电脑。

他们可以选择攻击软件的分发渠道，在用户正常下载、安装软件的过程中，将恶意代码一起交付给用户。

这次事件的关键就在于此。

整个过程可以简单理解为：

1. 攻击者篡改插件。
2. 恶意版本进入插件分发渠道。
3. 用户通过正常的插件市场安装或更新。
4. 恶意代码在用户机器上执行。
5. 攻击程序尝试收集信息、植入 SSH 公钥并建立持久化访问。

最值得警惕的是第三步。

用户可能完全没有异常操作，只是像往常一样点击了安装或更新。

这也是供应链攻击难以防范的原因之一：我们通常会信任软件的官方分发渠道，却很少怀疑渠道中的软件本身已经被替换。

二、攻击者植入了什么？

这次事件中，恶意程序涉及三个值得关注的行为。

1. 收集主机信息

恶意程序尝试获取目标机器的相关信息。

对于开发者来说，这些信息可能包括：

• 操作系统及主机环境信息
• 用户及系统配置
• SSH 相关信息
• 本地开发环境信息

这些信息可能帮助攻击者判断目标机器的价值，以及后续可以利用的入口。

2. 添加攻击者的 SSH 公钥

这是整个事件中最值得警惕的行为之一。

先简单解释一下 SSH 公钥认证。

我们平时通过 SSH 登录 Linux 服务器，通常会使用一对密钥：

• 私钥：保存在自己的电脑上，不能随意泄露。
• 公钥：放在目标机器的 authorized_keys 文件中。

例如：

~/.ssh/authorized_keys

如果攻击者能够将自己的公钥写入目标机器的授权列表，那么在满足 SSH 服务及访问条件的情况下，就可能获得远程登录能力。

这也是为什么攻击者添加 SSH 公钥的行为非常危险。

即使你之后卸载了恶意插件，已经添加的 SSH 公钥也不会自动消失。

3. 建立持久化远程访问通道

恶意程序还可能尝试建立持久化机制。

什么叫持久化？

简单理解就是：

即使用户关闭插件、重启电脑，甚至卸载原来的软件，攻击者仍然可能通过其他机制继续访问目标机器。

在 macOS 中，常见的持久化位置包括：

• ~/Library/LaunchAgents
• /Library/LaunchAgents
• /Library/LaunchDaemons
• 定时任务及其他启动机制

因此，这次事件不能简单地通过卸载 Cursor 扩展来解决。

如果恶意程序已经执行，必须进一步检查机器上是否留下了其他持久化痕迹。

三、Mac 用户如何自查？

如果你使用 Mac 和 Cursor，建议按照下面的步骤进行检查。

这里特别强调：

并不是所有 Cursor 用户都受到影响。

如果你没有安装过该扩展，或者使用的是 Anthropic 官方发行渠道，也不能直接认定自己受到影响。

第一步：检查 SSH 授权公钥

打开 macOS 终端，执行：

cat ~/.ssh/authorized_keys

如果文件不存在，说明当前用户没有这个 SSH 授权文件。

如果存在，检查里面的公钥。

重点关注：

• 是否出现自己不认识的公钥？
• 是否存在近期突然增加的公钥？
• 是否有无法确认来源的 SSH 注释信息？

也可以查看文件的修改时间：

ls -laT ~/.ssh/authorized_keys

注意：文件修改时间只能作为线索，不能单独证明文件是否被攻击者修改。

如果发现陌生公钥，不要直接删除所有内容。

先保留证据，确认每一条公钥的归属，再进行清理。

第二步：检查 SSH 目录

执行：

ls -laT ~/.ssh/

重点检查是否存在：

• 不认识的 SSH 公钥文件
• 异常新增的配置文件
• 不熟悉的授权文件
• 修改时间异常的文件

特别注意：

不要将 known_hosts 中陌生的服务器记录直接当成攻击者公钥。它们的作用并不相同。

第三步：检查 macOS 持久化启动项

执行：

ls -la ~/Library/LaunchAgents/

再检查系统级启动项：

ls -la /Library/LaunchAgents/
ls -la /Library/LaunchDaemons/

这些目录中可能存在合法软件的启动配置。

需要重点关注：

• 不认识的 plist 文件
• 最近突然出现的启动项
• 指向 /tmp、隐藏目录或异常脚本路径的配置
• 与自己安装的软件完全无关的启动程序

不要看到陌生文件就直接删除。

先查看对应 plist 的内容，确认它实际执行了什么程序。

第四步：检查当前 SSH 服务状态

执行：

sudo systemsetup -getremotelogin

这个命令可以查看 macOS 的远程登录设置。

如果显示：

Remote Login: On

说明系统开启了远程登录功能。

但这本身并不意味着机器已经被入侵。

它只是帮助你判断 SSH 远程访问是否具备相应条件。

四、如果发现异常，应该怎么办？

如果你确认存在不认识的 SSH 公钥，或者发现可疑的持久化启动项，不要仅仅卸载插件。

建议按照以下顺序处理。

1. 先隔离设备

暂时断开网络，避免可疑程序继续与外部通信。

如果这台 Mac 还保存着其他服务器的 SSH 私钥，尤其需要谨慎。

2. 保留证据

记录可疑文件的位置、内容、修改时间及相关进程信息。

不要急着清理所有文件，以免破坏后续分析所需的证据。

3. 清理持久化程序

按照 Cursor 官方针对该事件发布的安全处置指南，检查并清理恶意启动项、脚本及其他持久化机制。

仅删除 SSH 公钥并不能保证机器已经恢复安全。

4. 轮换可能暴露的凭据

从可信设备上重新生成或轮换可能受到影响的凭据，包括：

• SSH 密钥
• GitHub 访问令牌
• 云服务访问凭据
• 开发环境中的 API Key
• 其他保存在本机的敏感凭据

如果私钥可能已经暴露，应在可信设备上生成新的密钥，并从服务器撤销旧公钥。

5. 必要时重新安装系统

如果已经确认存在恶意持久化程序，但无法确定感染范围，最稳妥的方式是使用可信安装介质重新安装系统，并恢复经过检查的数据。