AREX Feed Article
Cursor 官方发布安全事件复盘公告：攻击链始于一枚暴露的 Fireworks 密钥，带毒扩展最多波及 5,000 名用户
UTC 时间 11 月 14 日 01:13（北京时间上午 9 时 13 分）， 发帖宣布，公司已就近期安全事件发布更新，链接页面载有对事件经过的详细说明与补救步骤。帖子指向的页面 在发稿时可以访问，标题为《An update on our recent security incident》。截至北京时间 14 日 14 时许，这条帖子累计约 12.7 万次浏览，收到 1,032 个点赞、97 条回复和 79 次转发。
这是 10 月 29 日事件曝光以来，Cursor 在博客上发布的第二份说明。在这份更新里，公司还原出了整条攻击链：第一环是攻击者获得一枚 Cursor 签发给第三方训练与推理供应商 Fireworks 的访问密钥。按公司口径，少于 0.01% 的客户有 API 凭证暴露；未开启 Privacy Mode（隐私模式）的用户中，少于 0.05% 的用户编码代理（coding agent）痕迹被暴露；带毒扩展最多波及 5,000 名用户。这些影响数字目前均为 Cursor 单方口径。
从“正在调查”到完整复盘：事件两周里的两份公告
10 月 29 日当天，Cursor 在博客发布，确认其 VS Code 扩展市场出现了恶意版本的 Anthropic.claude-code 扩展（2.1.312 与 2.1.313，Windows 与 macOS 平台），并附上排查脚本与失陷指标（IOC）；公告页面显示，它在太平洋时间 10 月 30 日上午 11:30 更新过 IOC 和受影响版本说明。更新页面则写道，经过“过去两周的大量调查”，公司希望分享更多关于攻击及其相关影响的背景。
更新页面确认：“绝大多数客户未受影响”，公司已直接联系每一位受影响客户。更新结尾写道：“隐私和安全是我们极为重视的优先事项——我们能做得更好，也必须做得更好。”公司同时承诺，若出现影响客户的重要新信息，将直接联系相关用户，并留下 作为咨询渠道。
攻击链起点：签发给 Fireworks 的一枚访问密钥
按 Cursor 更新页面的调查还原，事件的第一环在供应商侧：一枚 Cursor 签发给 Fireworks 的访问密钥被 Fireworks 暴露，攻击者用它复制了一个只读存储桶中的数据。这个桶是 Cursor 用来与 Fireworks 共享训练数据的，里面是数量有限的编码代理会话痕迹，大多来自 2025 年，来自未开启 Privacy Mode 的会话，且 Cursor 获得了将其用于模型训练的许可。少数痕迹中的凭证未经脱敏。
攻击者以这些凭证为起点，触达了 Cursor 使用的部分 SaaS（软件即服务）工具，进而访问了归档的非生产源码仓库（部分含业务联系人信息）、有限的客户支持数据与邮件往来、产品使用指标与联系人信息、部分编码代理对话的摘要，以及用户发给 Cursor 支持团队的部分凭证。
Cursor 称，其监控系统随后识别出这些未授权活动：公司停用了该供应商密钥，开启事件响应流程，追查进一步的访问，每发现一处就切断一处。出于谨慎，公司一度停用了远超证据所要求的内部和产品服务，导致部分 Cursor 功能临时中断，确认安全后才逐个恢复。
11 小时带毒窗口：恶意构建的投放与下架
第二环发生在扩展市场。更新页面称，10 月 29 日，攻击者利用一枚从其内部系统泄露数据中窃得的凭证，把未经授权的 Anthropic Claude Code 扩展恶意副本直接放到了用于服务 Cursor VS Code 扩展市场的缓存上。Anthropic 并未发布这一副本，这也不是 Anthropic 产品的漏洞。在 10 月 29 日的暴露窗口内，最多 5,000 名请求特定缓存版本的用户可能收到了恶意构建；恶意版本在线约 11 小时后被移除，公司随后整体关闭了扩展市场，并与托管攻击者服务器的云服务商合作，使端点 134.209.82.225 下线。
第一份公告给出的窗口是太平洋时间上午 2 时 27 分至下午 1 时 35 分；安全公司 StepSecurity 的把这一窗口对应为 UTC 时间 09:27～20:35。StepSecurity 在沙箱中验证了载荷行为：恶意代码藏在合法扩展的 extension.js 打包文件里，体积只比上一版干净构建大出约 7 KB，加载扩展模块即触发；它会收集主机名、用户名、操作系统、环境变量名、Git 邮箱、公网 IP 等信息，把攻击者 SSH 公钥写入 authorized_keys，借助 macOS 的 LaunchAgent（启动代理）或 Windows 计划任务安装持久化机制，建立反向 SSH 隧道，并以明文 HTTP 回传主机侦察数据。
公告同时说明了一个限制：恶意扩展要开启本地 SSH 服务需要管理员权限，而在多数 macOS 与 Windows 主机上它没有这种权限，这一步会失败。但 Cursor 与 StepSecurity 都提醒，仅卸载扩展并不足够，因为载荷会留下独立运行的持久化脚本。
官方划出的边界：Privacy Mode、生产系统与客户代码仓库
更新页面专门列出“未受影响”清单。开启 Privacy Mode 用户的提示词与代码不在暴露之列；未开启者中，痕迹被暴露的用户，公司称已逐一识别并直接通知，“如果你没有收到通知，你的数据就不在这些痕迹里”。当前发往 Cursor 的数据与实时流量、承载 Cursor 的生产系统与基础设施、Cursor 应用本体及其官方更新同样未被波及——公司称客户端与云服务的发布走的是攻击者从未接触过的另一套代码托管系统，发布签名密钥未被暴露。客户代码仓库、扩展市场里的其余扩展（公司称已逐一验证为真实）以及活跃的推理请求也不在受影响范围。
通知动作方面，更新页面把时间记在 10 月 30 日：公司在博客和 X 发布安全公告，通过应用内通知和邮件告知受影响用户与团队管理员；若凭证暴露，公司向团队管理员发送需要轮换的具体密钥清单，并请签发这些凭证的第三方服务撤销它们。
补救清单：切断供应商通道、轮换全部凭证、重建扩展市场
更新页面逐项列出公司侧已完成的补救：把全部推理流量迁离 Fireworks，停用签发给它的密钥，切断其对所有共享数据集的访问；按风险从高到低轮换发现的每一个暴露凭证，并作为预防轮换内部系统在用的全部凭证；验证市场内其余扩展的真实性并重建 VS Code 扩展市场；尽可能扩展对服务提供商的网络访问限制，使失陷凭证无法在预定位置之外使用；在全部代码仓库加入敏感凭证扫描（secret scanning）防护，并把扫描扩展到其他内部数据源；作为预防重新部署全部生产基础设施与服务，恢复前逐一审查内部服务；聘请外部取证专家协助调查。
用户侧的处置步骤保留在第一份公告中：检查 SSH authorized_keys 里是否出现名为 svc-telemetry 的公钥，按平台运行公司提供的 remediate-macos.sh 或 remediate-windows.ps1 清理脚本，从可信系统轮换受影响主机可达的凭证，并评估主机是否需要重装。更新页面提醒，若在暴露窗口内从 Cursor 扩展市场安装或更新到 2.1.312 或 2.1.313 版本，应按公告步骤处理。
一个对不上的细节：恶意副本是否到过 Open VSX
更新页面写道：“市场来源 Open VSX 从未携带过恶意软件。”但 StepSecurity 此前的分析写的是：被植入木马的 2.1.313 当天在 Open-VSX 注册表上架，并经镜像同步进入 Cursor 市场，其图示也标注“2 个注册表受影响”。两种说法在恶意副本的分发路径上并不一致；StepSecurity 当时也写明，该版本如何进入注册表——是发布者凭证被盗还是其他途径——“尚无公开结论”。
更新中还写道，公司看到的最后一次攻击者活动发生在 11 月 1 日且已被拦截——“我们相信事件已得到控制”。公司将继续监控系统异常活动，并承诺若发现影响客户的更多情况，会直接联系他们。