假冒 Claude Code 扩展暴露供应链风险

一个挂着 Claude Code 名字的扩展，为什么会变成开发机上的 SSH 后门？原文借 Cursor 扩展市场的一次事件，提醒团队：AI 编程工具的供应链已经进入编辑器，安装来源、更新内容和运行权限都需要有人负责。

这篇文章值得读，但要带着两层视角：前半段的安全检查可以直接参考，后半段则是 Kilo 借事件推广自家产品。事件细节、模型供应变化和优惠条件，以下均按原文转述，不代表已经独立核实。

一次扩展更新，怎么留下了持续运行的后门

据原文描述，10 月 29 日，一份被篡改的 Claude Code 扩展出现在 Cursor 的 VS Code 扩展市场，版本号为 2.1.313。它并非 Anthropic 构建，在线时间约为太平洋时间凌晨 2:27 至下午 1:35，约 11 小时，最多可能有 5,000 名用户安装。

攻击链并不复杂。扩展先收集主机名、用户名、操作系统、主目录、环境变量名称、Git 邮箱和公网 IP，再把攻击者控制的 SSH 公钥写入 authorized_keys，标记为 svc-telemetry。这里收集的是环境变量名称，原文没有说它读取了全部环境变量的值。

接下来，它尝试启用本地 SSH 服务并建立反向隧道，也就是让开发机主动连接外部服务器，为远程访问铺路。按照文中转述的 Cursor 通报，这一步在多数机器上因缺少管理员权限而失败。

但攻击并没有到此结束。它还通过 macOS 的 LaunchAgent 或 Windows 的计划任务建立持久化，每 60 秒重试隧道，并通过 HTTP 向攻击者回报。持久化的意思是：扩展安装结束后，留下的脚本仍可能继续运行。

卸载扩展，并不等于清除了它已经写进系统的东西。

原文建议，受影响用户检查 svc-telemetry 公钥，运行 Cursor 的修复脚本，并从干净机器轮换凭据。输入材料没有提供脚本内容和完整失陷指标，因此不能据此拼出一份完整处置流程。

Cursor 随后下架扩展、关闭市场、轮换密钥，并与托管方合作下线攻击服务器。作者肯定了这次响应，但更关心攻击为何得手：一个熟悉的名字、一个新版本号，再加一次安装或自动更新，就足够把代码送进开发机。

管 AI 工具，先把四个问题答清楚

作者提出的办法，是把扩展、MCP server、skill 和 plugin 都纳入工具链管理。它们可能读取仓库、执行 shell 命令、访问环境配置，风险已经超出编辑器界面本身。

每个组件都应该回答四个问题：

• 谁发布了它，发布者是否真是你以为的那家公司或开发者？
• 相比上一个可信版本，这次具体改了什么？
• 它实际做了什么，行为是否符合宣称的用途？
• 它能接触哪些文件、命令、网络和秘密信息？

这四问分别对应来源、变更、行为和权限。只核对名称或安装量，覆盖不了后面三个问题。

落地措施也很直接：对拥有 shell 或文件访问能力的工具，使用发布者白名单并固定版本，更新经过检查后再放行；编辑器不以管理员身份运行；像审查项目依赖一样审查 MCP server，确认来源和暴露的工具；检查 ~/.ssh/authorized_keys、LaunchAgents、计划任务和启动文件夹等持久化位置。

其中，不授予管理员权限有这次事件中的具体依据：它阻止了多数机器上的关键攻击步骤。其余措施属于作者给出的治理建议，原文没有提供实施前后的效果对照。

固定版本也需要配套维护。它能减少未经检查的更新进入团队，却不能替代后续升级，否则安全补丁也会被一起挡住。团队需要明确由谁检查、何时放行，而不是把所有判断留给每个开发者。

Kilo 的方案有哪些能力，哪些还只是承诺

文章接着介绍 Kilo，这部分需要按产品介绍来读。

作者称，Kilo 的代码在 GitHub 开源，便于查看行为和版本变化；Kilo Enterprise 支持按组织及子组织限制模型和供应商，并提供 SSO、SCIM、基于角色的访问控制及审计日志。供应商策略还可按训练政策、提示词保留规则和位置筛选。

另一项能力来自 Enkrypt AI 的 guardrails。按作者描述，它会依据安全团队的策略检查每次 prompt、工具调用，包括 shell 命令，以及工具返回结果，并记录拦截日志。作者举了粘贴 API key、README 中隐藏指令的例子，但没有提供漏报率、误报率或实际测试结果。

管理员统一启用 guardrails，以及运行前检查 MCP server 和 skill 的 MCP Scan、Skill Scan，被列在「即将推出」中，不能当成已经交付的能力。

文章还把模型供应变化作为迁移动机：它声称，Cursor 被 SpaceX 收购后，OpenAI 表示不再供应未来模型，现有 OpenAI 模型访问计划于 2026 年 11 月 12 日结束；新的 X Subscription 套餐也取消了内含的第三方模型额度。这些属于需要另行核实的商业信息。

随后出现的 Cursor Exodus 优惠，则是明确的销售动作：Kilo Enterprise 免费覆盖 Cursor 合同剩余期限，最长 12 个月，席位按 1:1 匹配；通过 Kilo Gateway 提供 500+ 模型，包括 GPT，token 价格零加价。还支持自带密钥、本地模型或符合条件的 ChatGPT Plus、Pro 订阅，申请截止日期为 2026 年 11 月 30 日。

但免费的是企业服务期限。AI 用量另计，不含 credits；申请需要签署声明并提交脱敏合同证明，由提供方酌情批准，也不会取消或报销原有 Cursor 合同。

我的判断

我赞同把 AI 编程组件按软件依赖管理，尤其是同时检查来源、更新和权限。开发者通常会审查进入项目的依赖，却容易默认编辑器里的扩展可信；当扩展具备命令执行能力时，这个缺口就很实际。

但原文也把几种不同的防线放在了一起。恶意扩展在安装或启动时执行代码，和 agent 被 README 中的隐藏指令诱导执行命令，发生在不同环节。检查 prompt 和工具调用的 guardrails，不能仅凭功能描述就推导出能拦住这次扩展攻击。

开源和策略控制有助于审计，不能单独证明安装包可信。

代码公开之后，仍需确认实际分发的构建与代码是否对应；策略存在之后，也要确认覆盖范围和执行边界。作者没有给出这些对照证据。

相较于直接更换编辑器，先建立工具清单、更新审核和权限边界，更贴近这篇事件分析能够支持的结论。Kilo 自身也是扩展，作者也承认没有编辑器天然免疫。至于迁移后的质量、成本和安全收益，原文没有可比较的数据，应当视为产品主张，再用真实仓库验证。

能拿来做什么

• 给团队正在使用的 AI 扩展、MCP server、skill 和 plugin 建一份清单，记录发布者、版本、用途及可访问的文件、命令和网络，优先补齐拥有 shell 权限的组件。
• 将高权限扩展的自动更新改为经过检查后放行，并安排维护负责人；日常启动编辑器时使用普通用户权限，把更新管理和权限限制一起落实。
• 如果安装或更新过涉事版本，应按原文建议核查 svc-telemetry 和相关持久化位置，依据正式安全通报完成处置，不要把卸载扩展当作处理结束。
• 如果准备迁移 AI 编程工具，就让候选工具在同一真实仓库中并行试用，比较任务质量、实际用量费用及组织策略是否生效，再决定是否推广到整个团队。