小岛AIAI 航行日志

小岛 / 岛刊社 / 文章

装过 Claude Code 扩展？Cursor 说：别只卸载

小岛AI

Cursor 更新了 10 月扩展市场事件的调查。若你当时在 Cursor 中安装或更新过 Claude Code 扩展，先按版本、安装渠道、残留与密钥四步排查；只卸载并不等于收尾。

Claude CodeAI 编程AI 安全

如果你在 Cursor 里装过 Claude Code 扩展，现在最值得花的不是半小时读复盘，而是十分钟确认一件事：你有没有在 10 月 29 日那个窗口，通过 Cursor 的扩展市场装到 2.1.312 或 2.1.313。

Cursor 昨天补了一份调查更新。10 月 29 日的恶意构建在市场缓存里存在约 11 小时，官方估计最多 5,000 人可能请求到了那两个版本。它不是 Anthropic 官方发布的副本，也不是 Open VSX 里的包；Cursor 说，攻击者把篡改版本放进了它自己的市场分发缓存。调查更新在这里。

很多人看到这种消息，第一反应是“我把扩展删掉了”。这一步当然要做，但 Cursor 在公告里特意提醒：只卸载，可能还不够。 对开发机来说，真正的收尾通常分成四件事：判定自己是不是范围内、检查残留、轮换可能接触过的凭证、把团队里同样的机器找出来。

Cursor 事件不是一条新闻，而是一条从扩展更新到凭证收尾的检查路径

图：本篇只讨论 Cursor 官方确认的受影响版本、渠道和收尾步骤；不要把它泛化成“所有 Claude Code 都有问题”。

先把范围缩小，别在所有机器上制造恐慌

这次的边界其实很具体。Cursor 的原始安全公告写的是：受影响的是 Cursor VS Code 扩展市场中 Anthropic.claude-code 的 2.1.312 和 2.1.313，当时覆盖 macOS 与 Windows。微软的独立分析也确认，Microsoft Visual Studio Marketplace 和 npm 上的 @anthropic-ai/claude-code 不在这次分发链路里。Cursor 的中文公告 和 微软的分析 都能交叉核对。

所以排查的第一问不是“我用不用 Claude Code”，而是下面这三句：

  • 10 月 29 日那天，我是否在 Cursor 中安装或更新过这个扩展？
  • 它是不是来自 Cursor 的扩展市场，而不是 VS Code 官方市场、npm 或 CLI？
  • 安装记录或扩展目录里，是否出现过 2.1.312 / 2.1.313？

在 macOS 或 Linux 的个人电脑上，先做一个只读目录盘点就够了。它不改文件，也不需要把任何 token 发出去：

find "$HOME/.cursor/extensions" "$HOME/.vscode/extensions" \
  -maxdepth 1 -type d -iname 'anthropic.claude-code-*' 2>/dev/null

看见其他版本，不等于命中；看不见目录，也不等于历史上从没装过。它只是把“现在这台机器上有什么”从猜测变成一个可记录的结果。公司设备还要补资产管理、终端防护或备份里的安装记录，别拿个人电脑的一次检查替代全员排查。

如果确认装过那两个版本，或者根本无法确认安装来源，直接走 Cursor 公告里的官方修复脚本和入侵指标。不要从论坛随手下载一个“一键清理工具”。安全事件里最容易出现的二次伤害，就是为了清理恶意扩展，又跑了另一个来历不明的脚本。

卸载之后，为什么还要管密钥

这里是最容易被忽略的一步。

Cursor 这次更新披露的攻击路径很长：一个暴露给第三方供应商的访问密钥，通向了一部分历史 coding agent traces；少量未脱敏凭证又被用来触及了部分 SaaS 工具。后面才出现了扩展市场中的恶意副本。官方说，可能暴露的 Cursor 凭证已按风险轮换，受影响客户也被直接联系。

读到这里，不需要把所有账号都当成已经失守。更实用的做法是：把“曾在那台开发机上可直接使用”的凭证，按破坏半径排序。

先看能改代码、能发包、能部署、能花钱的那几类：GitHub/GitLab 访问令牌、云服务访问密钥、CI/CD token、npm 或 PyPI 发布令牌、支付和模型 API key。能从干净设备上重新签发的，优先重新签发；旧值在对应平台撤销。只改本地 .env 的文件名、只换编辑器登录态，都不是轮换。

按影响面安排凭证收尾：先能部署或发布的，再到日常开发和个人服务

图：不是让你一次性清空所有账号，而是先处理一旦被滥用就难以回滚的权限。

有一个细节值得保留：Cursor 的更新称，未开启 Privacy Mode 的历史 trace 中，不到 0.05% 的用户涉及这批暴露数据；其中 API 凭证暴露的客户不到 0.01%。这是厂商披露的调查结论，不是给任何一台具体机器开的“没事证明”。你是否需要轮换，仍要回到版本、渠道、安装时间和官方通知来判断。

给团队的版本：把“谁装过”变成一个清单

个人电脑还可以靠回忆，团队不行。把这次事放到团队里看，最有用的产物不是一封“大家注意安全”的群公告，而是一张很短的清单：设备、安装渠道、版本、是否命中窗口、是否执行官方修复、凭证轮换的负责人和完成时间。

这样做还有个额外好处。下一次某个 Agent 插件、MCP 服务或 IDE 更新出问题时，不必从聊天记录里捞“谁可能装过”。扩展来源、自动更新策略和高权限 token 的存放位置，本来就该和依赖清单一样能被查到。

Cursor 说它已重建市场存储、验证其他扩展、增加密钥扫描，并把推理流量迁离原供应商。这些是厂商一侧的补救。开发者这一侧只需要完成自己的那一半：确认范围、使用官方步骤收尾、让旧密钥失效、留下可复查的记录。

你们团队的 AI 编程扩展，现在能不能说清“装在哪些机器、从哪个市场来、谁有自动更新”？如果说不清，今天先把这张清单补上，往往比再装一个新 Agent 更值。

— 小岛AI