5000 名开发者真的被黑了吗？Cursor 插件投毒事件目前到底产生了什么影响？

作者注：本文拆解 Cursor 插件投毒事件里“最多 5000 人受影响”的真实含义，梳理攻击链、已核实案例、API Key 风险边界和自查步骤，帮你分清哪些说法有证据，哪些属于夸大。

2026 年 10 月 29 日，Cursor 扩展市场出现了被篡改的 Claude Code 扩展。随后几天，“5000 名开发者被黑”“Claude API Key 大规模泄露”之类的标题开始流传。实际情况是：5000 是 Cursor 官方给出的潜在受影响用户上限，并不是 5000 起已确认的成功入侵。

这不是在替谁淡化风险。Cursor 官方公告、微软安全研究团队、Phorion、Expel 等多家机构都已确认事件真实发生，也已经在客户设备上观察到恶意活动。本文按“分发、执行、写入、可利用、实际入侵、数据损失”六个层级，逐层说明哪些事实已经核实，哪些数字目前没有公开。

核心价值：读完本文，你能判断 Cursor 插件投毒对自己和团队的实际影响，并照着官方建议的步骤完成自查与凭证轮换。

Cursor 插件投毒事件核心信息速览

先看几项已经核实的基础事实。理解这起事件的关键在于边界：它是开发工具的软件供应链攻击，不是 Claude 模型被攻破，也不是 Anthropic 内部系统失守。

Anthropic 表示这些恶意构建不是它开发或发布的，事件也不涉及其内部系统或员工电脑。攻击者是怎么拿到向 Cursor 市场发布构建的权限的，截至 11 月 2 日仍没有公开的调查结论。

Cursor 插件投毒关键时间线

这起事件里有两个时间概念容易混在一起。一个是市场可下载恶意包的时间窗口，另一个是已安装设备上恶意代码实际运行的时间。后者可以比前者晚很多，插件下架并不代表本地已经安全。

最初也有报道称是 Open VSX 被攻击。OpenSourceMalware 后来更正了这一说法，Socket 检查 Open VSX 注册表记录后也没有找到对应恶意版本。目前能确认的被攻击渠道只有 Cursor Marketplace。

Cursor 插件投毒如何工作：从 66 行加载器到反向 SSH 隧道

据 Phorion 和 OpenSourceMalware 分析，攻击者在正常扩展的 extension.js 开头插入了约 66 行恶意 JavaScript 加载器，位置在正常业务代码之前。扩展模块一加载就会触发，用户不用给 Claude 发消息，也不用授权任何编程任务。Claude Code 的界面和功能照常可用，部分错误还被静默处理，用户很难察觉。

整条攻击链可以归纳为以下六步：

1. 收集主机信息：主机名、用户名、操作系统与 CPU 架构、主目录、工作目录、Git 全局邮箱、公网 IP 等。
2. 植入 SSH 授权密钥：向用户的 authorized_keys 写入攻击者控制的公钥，标记为 svc-telemetry。
3. 尝试启用 SSH 服务：设备开放 SSH 登录的话，攻击者就可能用植入的密钥登录。
4. 建立反向 SSH 隧道：由受害设备主动连接攻击者服务器（TCP 22），再把连接转发回本机 SSH 服务，以此绕过部分入站限制。
5. 部署持久化：在 macOS、Windows 上设置登录后自动重连，Linux 上通过 crontab @reboot，这样后门不依赖扩展本身也能运行。连接失败时大约每 60 秒重试一次。
6. 回报执行状态：通过 TCP 8099 端口的 HTTP Beacon 向服务器上报主机信息和各步骤执行结果。

为什么 Cursor 插件投毒不是提示词注入

很多人看到“Claude Code 出事”，第一反应是模型被恶意 Prompt 操纵了。这次不是。它是典型的扩展代码执行攻击，恶意逻辑跟模型输出完全无关，换成任何一个被篡改的 IDE 插件，原理都一样。所以讨论 Claude 模型本身的安全性，对这起事件没有意义。真正暴露出来的问题是：开发工具的插件分发渠道一旦被冒用，信任链就会断掉。

恶意代码的两个实现缺陷

这次攻击的危险性因为代码写错而打了折扣。macOS 上，恶意代码查询 Remote Login 状态时没有用管理员权限，系统返回的是权限错误，不是“已关闭”。而程序只在明确识别到“已关闭”时才会去开启 SSH，所以在很多原本没开 SSH 的 Mac 上，这一步会失败。Windows 上，它安装 OpenSSH Server 时错误地调用了 Unix 风格的 /bin/sh，标准 Windows 环境里没有这个路径。

不过，缺陷不等于失效。恶意代码仍然能写入公钥、生成持久化脚本、发起网络连接、上报主机信息。原本就开着 SSH 的设备风险会高很多。Phorion 联合创始人 Calum Hall 接受 WIRED 采访时也说，如果实现正确，这本可能成为非常危险的攻击入口。

5000 名开发者被黑了吗：Cursor 插件投毒影响的 6 个层级

“5000”的原文出自 Cursor 10 月 29 日的初版公告：“At most 5,000 users were affected”，意思是最多 5000 名用户受到影响。这是官方自报的上限，不是安全机构独立确认的入侵数。初版公告只提到 2.1.313，更新后补充了 2.1.312，但官方没有公开两个版本各自对应多少用户，也没有给出修订后的完整人数拆分。

把影响拆成六层看，哪些已经证实、哪些只是推测，就比较清楚了：

图中左右两边的差距，就是新闻标题和证据之间的差距。越往漏斗下层，公开证据越少。“5000 台电脑被完全控制”“5000 人的 API Key 被盗”这两种说法，目前都找不到证据支持。

Expel 4 起实案说明了什么

Expel 在 10 月 29 日至 30 日处理了 4 起相关客户事件，涉及 4 家客户，每起各 1 台 Mac。其中 3 台用的是 CrowdStrike Falcon，1 台用的是 Microsoft Defender for Endpoint。4 起事件都有连向攻击者服务器 IP 的网络连接。这说明事件已经不只停留在实验室代码分析阶段。

最值得注意的是那起延迟执行的案例。用户在北京时间 10 月 30 日 12:44 登录 Mac 并启动 Cursor，一分钟后出现恶意活动，到 22:29 仍有连向攻击者 IP 的连接，前后将近 10 小时。这时市场早已下架恶意包，比较合理的解释是安装包在暴露期内已经下载好，等用户重新打开 Cursor 才被触发。

这组数据有明确的边界：4 起不代表全球只有 4 台设备中招，不能用 4 除以 5000 去算感染率，检测到 SSH 隧道也不等于攻击者已经登录成功。Phorion 也在客户 Mac 上发现过样本，但它和 Expel 的案例是否有重合并不清楚，不能简单相加。Expel 还发现一台机器上有恶意隧道进程，却没有 svc-telemetry 公钥标记，可见只搜一个标记很容易漏报。

Cursor 插件投毒中的 API Key 风险边界

恶意代码最多会筛选 40 个名称里含 KEY、TOKEN、SECRET、PASS、AWS、GCP 的环境变量。比如机器上设置了 OPENAI_API_KEY，攻击者就能知道这台机器在用相应的服务。但研究人员确认，初始上报的只是变量名称，不是变量的值。

所以准确的说法是：攻击代码能识别敏感配置的类别。如果后门真的被利用，攻击者有可能进一步读取本地凭证和源代码。至于实际有多少 API Key 被窃取，目前没有任何公开数据。“已窃取所有用户 API Key”属于把能力等同于结果。不过风险边界不清楚，恰恰说明应该把凭证轮换当成预防措施来做。

Cursor 插件投毒影响分析

对开发者的影响

• 卸载插件不够：官方明确提醒，只卸载或升级到 2.1.314，不一定能清除已经写入的 SSH 公钥、启动项和后台脚本。
• 下架后仍可能触发：Expel 的延迟案例说明，“下架后才打开 Cursor”的用户同样需要自查。
• SSH 常开的机器风险更高：开发机为了远程调试常开 Remote Login，正好避开了恶意代码的实现缺陷。
• 凭证暴露面被摸底：哪怕后门没有成功利用，攻击者也可能已经知道你用了哪些云服务和 API。

对团队与行业的影响

• 插件分发成为新的攻击面：同一扩展在不同市场的版本可能来源不同，判断时要结合安装来源和文件哈希，不能只看版本号。
• AI 编程工具获得的终端权限需要重新评估：IDE 插件一般以用户权限运行，能读写主目录、发起网络连接，企业应该把它们纳入终端管控。
• 事件响应需要覆盖凭证生命周期：受影响设备能访问的仓库、API Key、云凭证、会话令牌都应该评估。项目用到的 Key 越分散，轮换成本越高。

Cursor 插件投毒自查与凭证轮换实操

首先建议使用 Cursor 官方公告里提供的 macOS 与 Windows 检查和修复脚本。下面的指标和命令用于辅助理解与排查，不能替代官方脚本和日志调查。

第一步：本机快速排查（macOS 示例）

# 1. 检查授权公钥中是否有攻击者标记（注意：没找到不代表安全，可能漏报）
grep -n "svc-telemetry" ~/.ssh/authorized_keys

# 2. 检查持久化文件与启动项
ls -la ~/.config/.smt ~/.config/.smtk ~/Library/LaunchAgents/com.apple.sysmond.plist 2>/dev/null

# 3. 检查是否存在与恶意服务器的连接
lsof -nP -i | grep "134.209.82.225"

# 4. 确认 Remote Login 状态（需要管理员权限）
sudo systemsetup -getremotelogin

Windows 用户可以用 schtasks /query /tn SysMon 检查计划任务，再到启动目录里找 sysmon.cmd。只要任何一项命中，就应该保留证据、隔离设备，然后按官方脚本清理。设备可信状态无法恢复的话，要考虑重装系统，并在另一台可信设备上轮换凭证。

第二步：盘点暴露的凭证变量名

下面的脚本用和恶意代码相同的关键词筛选环境变量，只打印名称、不打印值，可以帮你列出需要轮换的清单。轮换完成后，再用一次最简单的 API 调用确认新 Key 能用：

import os, re, openai

# 与恶意代码相同的关键词，列出可能被“摸底”的变量名
pattern = re.compile(r"KEY|TOKEN|SECRET|PASS|AWS|GCP")
print([k for k in os.environ if pattern.search(k.upper())])

# 在可信设备上轮换后，用新 Key 验证调用
client = openai.OpenAI(
    api_key=os.environ["NEW_API_KEY"],
    base_url="https://api.apiyi.com/v1"  # API易 OpenAI 兼容接口
)
r = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": "ping"}]
)
print(r.choices[0].message.content)

import os
import re
import openai
from typing import List

KEYWORDS = re.compile(r"KEY|TOKEN|SECRET|PASS|AWS|GCP")

def list_sensitive_env_names(limit: int = 40) -> List[str]:
    """只返回疑似凭证的环境变量名称，绝不输出值。
    limit 与恶意代码的筛选上限保持一致，用于还原攻击者可能看到的视图。"""
    names = [k for k in os.environ if KEYWORDS.search(k.upper())]
    return sorted(names)[:limit]

def verify_new_key(model: str = "gpt-4o-mini") -> bool:
    """轮换后验证新 Key 是否可正常调用"""
    client = openai.OpenAI(
        api_key=os.environ.get("NEW_API_KEY", ""),
        base_url="https://api.apiyi.com/v1"
    )
    try:
        resp = client.chat.completions.create(
            model=model,
            messages=[{"role": "user", "content": "ping"}],
            max_tokens=10
        )
        return bool(resp.choices[0].message.content)
    except Exception as e:
        print(f"验证失败: {e}")
        return False

if __name__ == "__main__":
    print("可能暴露给攻击者的变量名：")
    for name in list_sensitive_env_names():
        print("  -", name)
    print("新 Key 验证结果：", verify_new_key())

第三步：按优先级轮换凭证

🎯 技术建议：如果项目同时直连 OpenAI、Claude、Gemini 等多家平台，事发后就得分别登录多个后台吊销、重建 Key。官方推荐把模型调用统一收敛到 API易 apiyi.com，一个 Key 覆盖多家主流模型，接口兼容 OpenAI，轮换时改一处配置就够了，也便于集中查看用量、发现异常消费。

常见问题 FAQ

Cursor 插件投毒核心要点 Key Takeaways

• 事件性质：Cursor 市场分发了篡改的扩展，属于供应链攻击，不是 Claude 模型漏洞
• 5000 的含义：这是官方给出的潜在影响上限，不是已确认的入侵数量
• 已证实的部分：独立机构在真实 Mac 上观察到恶意活动和外联
• 未公布的部分：成功远程登录人数、被盗 Key 数量、经济损失
• 关键风险：下架后仍可能触发，卸载插件不能保证清除后门
• 处置方式：运行官方脚本，在可信设备上轮换凭证，借助 API易 apiyi.com 收敛 Key 数量

总结

Cursor 插件投毒事件的核心要点：

1. 区分标题和证据：“最多 5000 人受影响”和“5000 人被黑”差了好几个层级，当前公开证据停在“已有真实执行案例”这一层。
2. 攻击确实存在，但打了折扣：恶意代码具备后门和持久化能力，macOS 与 Windows 上的实现缺陷降低了远程登录的成功率。
3. 自查不能只做一项：要结合安装来源、文件哈希、进程、网络连接和启动项，只搜 svc-telemetry 可能漏报。

如果你在 10 月 29 日至 30 日期间通过 Cursor 市场使用过 Claude Code 扩展，请先按官方指引自查，再按优先级轮换凭证。模型 API 这部分，可以借这次机会把分散的 Key 统一到 API易 apiyi.com，下次需要应急轮换时会省事很多。

📚 参考资料

1. Cursor 官方安全公告：事件时间、版本、恶意文件哈希与清理脚本
2. 链接：cursor.com/blog/claude-code-extension-security-notice

3. 说明：自查时首先参考这份公告，包含 macOS 与 Windows 修复脚本

4. Microsoft Security Research：恶意 Claude Code 扩展攻击链分析

5. 链接：microsoft.com/en-us/security/blog/2026/10/30/inside-malicious-claude-code-branded-cursor-extension-persistent-ssh-backdoor/

6. 说明：确认供应链边界、SSH 机制与持久化细节

7. Phorion：Official Claude Code Extension Compromise

8. 链接：phorion.io/blog/offical-claude-code-vsx-compromise/

9. 说明：66 行加载器、平台差异与代码缺陷的技术细节

10. Expel：Fake Claude Code extensions in Cursor

11. 链接：expel.com/blog/blog-fake-claude-code-extension-cursor-ssh-backdoor/

12. 说明：4 起真实客户事件与延迟执行案例

13. Socket：Cursor Removes Malicious Claude Code Extension

14. 链接：socket.dev/blog/claude-code-extension-compromise
15. 说明：Open VSX 与 npm 记录核查，纠正早期误报

作者：APIYI 技术团队
技术交流：欢迎在 API易 apiyi.com 首页联系我们，更多接入资料可访问 docs.apiyi.com 文档中心

延伸阅读

• Claude Code 扩展被投毒：2.1.313 后门，5 步自查与清除:10 月 29 日，Cursor Marketplace 上的官方 Claude Code 扩展 2.1.312、2.1.313 被换成带 SSH 后门的构建，最多 5,000 名用户暴露。本文用 5 步讲清如何自查 svc-telemetry 公钥、清除 LaunchAgent 与计划任务等持久化、升级到 2.1.314 及以上版本，并完成 GitHub、云凭据和 API易 Key 轮换，帮你把这次事件真正收尾。
• Claude Max 改名 Ultra，5 小时限制取消了吗？3 个变化先看清:Claude Max 20x 改名 Ultra、Max 5x 改名 Max，价格不变；已认证 Ultra 账户取消 5 小时限制，周限额不变。本文用对照表、3 步自查和算账帮你判断要不要换档。