1.4%用户被通知换密钥，OpenCode承认遭大规模蒸馏攻击

你收到那封标题写着"Action Required: Potential provider key breach"的邮件了吗？10月17日，部分 OpenCode Console 用户打开邮箱，看到的第一句话是：我们发现一个正在退役的遗留系统遭到未授权访问。

真正要命的是下一句：保存在你工作区里的第三方服务商密钥（例如 OpenAI、Anthropic）可能已经泄露。安全研究员 Matt Johansen 在 15:30 UTC 把邮件截图发到 X，配文只有一句"Confirmed. OpenCode hacked. Keys stolen."

18:08 UTC，OpenCode 在 X 上确认："我们昨晚发生了一起与大规模蒸馏攻击相关的安全事件。"官方给出的影响范围是 1.4% 的 OpenCode Console 用户。

官方目前说了什么

把 X 帖子和客户邮件里的信息拼起来，能确认的只有这几条：

• 出问题的是 OpenCode 本来就在下线的"遗留系统"。
• 保存在 Console 工作区的第三方服务商密钥"可能已暴露"，邮件点名 OpenAI 和 Anthropic 作为例子。
• 约 1.4% 的 Console 用户受影响。OpenCode 称已逐一发邮件通知，没收到邮件的人不受影响，受影响群体是那些关联了外部服务商的用户。
• OpenCode 表示正与 Anthropic、OpenAI、Google 合作处置。
• "事件仍在进行中，现阶段无法分享更多细节。"

邮件要求受影响用户"通过对应服务商的控制台吊销并替换这些密钥，更新所有使用它们的应用，并检查近期用量是否有异常活动"。

没说的部分同样值得记下来：1.4% 对应多少个账号、攻击者怎么进来的、访问持续了多久、密钥是否真的被拿走，OpenCode 都没有公布。Runtime Wire 指出，1.4% 这个数字"本身既不能衡量暴露面，也不能衡量损失"。Crypto Briefing 报道称，部分受影响用户看到了数百美元的账单，这些费用如何处理尚无说法——这是用户自述，不是 OpenCode 的官方数字。

18:41 UTC，OpenCode 联合创始人 Dax Raad 发帖称，他"个人账号现在也在被攻击"。

"蒸馏攻击"这个标签怎么理解

标签是 OpenCode 自己选的。Anthropic 在 2 月 23 日的一篇文章里把蒸馏定义为：用更强模型的输出，去训练一个能力较弱的模型。10 月 12 日，Anthropic 又写道，做蒸馏的人使用过"控制数十万个欺诈账号的代理网络"。

一个被偷走的服务商密钥，对持有者来说就是免费的前沿模型输出。大量拉取前沿模型答案来训练自家模型的人，有充分理由想要一张记在别人账上的密钥。这能同时解释"蒸馏"这个标签和用户报告的账单。但 OpenCode 并未确认这一推断，在官方后续通报出来前，只能当作假设看。

把密钥存进网关的代价

OpenCode Console 的服务商文档写着，工作区可以连接"你已经在付费的"服务商账号，例如 Anthropic、OpenAI 或 AWS Bedrock，Console 保存凭据，成员"无需看到服务商密钥"就能使用模型。

团队网关就是这么工作的，好处是不必把原始密钥发给每个同事。代价是网关手里握着一把能刷你卡的活密钥，所有碰过它的系统都进入你的攻击面——包括那个正在退役的系统。

注意范围。邮件说的是"保存在你工作区里"的密钥。按文档，OpenCode CLI 用 /connect 添加的密钥存在本机 ~/.local/share/opencode/auth.json，本次事件中 OpenCode 没有就本地密钥说过任何话。

收到邮件之后：吊销、验证、复查

第一步，吊销并替换工作区里保存的每个密钥。Anthropic 的支持文章要求对可能已泄露的密钥"立即"吊销；OpenAI 的密钥在 API keys 页面管理；Gemini 方面，Google 的文档建议先在 AI Studio 创建新密钥，再停用泄露的那把。

第二步，更新所有用过旧密钥的应用和 CI secret，包括 Console 工作区本身。

第三步，确认旧密钥真的死了。Anthropic 对已吊销密钥返回 401，OpenAI 对错误密钥返回 401，用一条 curl 打印状态码就能验证：

• 请求 api.anthropic.com/v1/models，带上 x-api-key 和 anthropic-version 头，返回 401 说明密钥已失效。
• 请求 api.openai.com/v1/models，带上 Authorization: Bearer 头，同样看 401。

第四步，回查用量里不认识的流量，至少回溯到 10 月 16 日，服务商日志允许的话再往前翻。OpenCode 没说访问持续了多久。Anthropic 指向用量与日志页面，Google 的文档要求泄露后检查账单和用量日志。

没收到邮件的人，按 OpenCode 的说法不受影响。但如果你确实在工作区存过密钥，趁调查还没结束花几分钟轮换，成本很低。

下次往控制台里粘密钥之前

要求你保存服务商密钥的工具不会只有这一个。三个习惯能限制单次泄露的破坏半径：

• 每个第三方服务一把独立密钥。密钥只在一个网关里待过，你就确切知道该吊销什么、用量飙升该算谁的。
• 给这把密钥设消费上限。Anthropic 支持按工作区设置自定义支出和速率限制（默认工作区不行），给网关的密钥单独开一个工作区，把限额压低。
• 用服务商提供的最窄权限范围。Google 文档建议"Restrict to Gemini API only"，这样泄露的密钥调不动其他 Google API。

团队最容易跳过的是按密钥盯用量。邮件让用户"检查近期用量是否有异常活动"，可这招只有在你知道正常长什么样时才管用。