看到 OpenCode 那条公告的时候，我正在改一个脚本。第一反应不是转发，是打开几个后台，把过去 24 小时的用量翻了一遍。
原因很简单：我也在用第三方工具托管密钥。这类事故离我并不远。
发生了什么
OpenCode 官方在 X 上承认，前一晚发生了一起安全泄露，与一次大规模蒸馏攻击有关，影响了 1.4% 的 OpenCode Console 用户。他们已经通过邮件通知了受影响的人，没收到邮件说明不在名单里。受影响的是「关联了外部提供商」的那部分用户子集。
公告说事件仍在处理中，暂时不能披露更多细节，正在和 Anthropic、OpenAI、Google 一起修复。
发给用户的邮件写得更直接：未经授权访问发生在一个「正在下线过程中的旧系统」上，用户保存在 workspace 里的第三方密钥，例如 OpenAI、Anthropic 的，可能已经暴露。
1.4% 听起来很小。但 OpenCode 的用户基数不小，1.4% 落在具体的人身上，就是账户余额被清空。
受害者的账单
最先被看到的是用量图。Rolling usage 还正常，Weekly 已经 86%，Monthly 直接 100%，红色的条拉到底。
Colin Parsons 的账单更具体：OpenAI 侧 281 美元，Anthropic 侧 168 美元，加起来 400 出头。他特别说明，这两个 key 只在 OpenCode 里用过，其他 OpenAI / Anthropic 的 key 没有受影响。
同一条推下面，Preston Zeller 回了一句「是的，一样的情况，1700 美元」。
另一位开发者晒出的图更直观：某一天的开销从几十美元直接跳到 700 多美元，来源标注是已经删除的 opencode key。
Anthropic 那边反应很快。Lydia Hallie 公开表示，已经在和 OpenCode 合作处理，并撤销了所有被认为受影响的 Claude API key。她还补了一句：如果你在 OpenCode 里存过 key，想更稳妥，就新建一个。
最有意思的是 OpenCode 联创 Dax Raad 的反应。官方声明发出后不久，他在 X 上说，自己的个人账号现在也在被攻击，AI 驱动的自动化攻击打开了一个全新的世界。
连创始人都没躲过，说明这不是「谁不小心」的问题，是架构问题。
黑客要的不是钱，是 token
这一点值得单独说。
一般人会以为偷 key 是为了转卖，或者翻聊天记录。这次不是。攻击者拿到 key 之后，做的是大规模调用顶级模型，把额度转化成高质量的 CoT 和代码数据，用来蒸馏自己的小模型。
这笔账很好算。直接买 OpenAI、Claude 的 API 去生成训练数据，成本是百万到千万美元级别。而且各家服务条款都明确禁止用模型输出训练模型，后台有风控。攻破一个第三方聚合平台，一次拿到成百上千个真实开发者的 key，每一次 token 消耗都记在受害者账上——成本转移得干干净净。
所以这类攻击不会停。只要有平台把大量密钥集中托管在一处，它就是高价值目标。1.4% 这个数字，下次可能更大。
为什么是「旧系统」
官方说漏的是一个正在下线的 legacy system。这句话信息量很大。
系统下线是一个过程，不是一个开关。业务已经迁走，但旧代码还在跑，旧数据库还连着，旧接口还有权限。它往往不在新架构的监控里，不在新的告警规则里，也不在最近一次安全评审的范围里。攻击者最喜欢这种地方——没人看，但门还开着。
我做过类似的迁移，深有体会。新系统上线那天大家都在盯，旧系统关停那天往往没人盯。真正要做的不是「记得关」，而是把「旧入口必须在新入口上线后 30 天内关闭」写进流程，并且有清单可以核对。
我当晚做的六件事
不是建议清单，是我实际执行的顺序。
第一，先查用量，不改配置。打开 OpenAI、Anthropic、Google 三家的 usage 页面，看过去 24 小时和过去 7 天的曲线。有异常尖峰再往下查，没有异常也不要立刻放心——有些攻击是慢速的。
第二，吊销，不是改密码。这是最多人搞错的一步。改登录密码不会让已经流出的 API key 失效。在 OpenCode 里删掉配置、把本机程序关掉，也不会。必须到签发 key 的那家控制台，把那个 key revoke 掉。
第三，按用途拆 key。我现在一个项目一个 key，一个环境一个 key。生产、测试、临时脚本分开。这样泄露的时候，损失边界是清楚的，吊销也不会把正常业务一起打断。
第四，给每个 key 设硬预算。三家控制台都支持用量上限和告警。把月度硬上限设成你真实能承受的数字，而不是「先开着再说」。这次那些被刷到 1700 美元的账户，如果有一个 200 美元的硬上限，损失会小一个数量级。
第五，把 key 从云端 workspace 挪走。能在本机环境变量里的，就不要存在第三方网页的工作区里。要用云端，也优先用支持短期凭据或者代理转发的方案，而不是把长期 key 明文贴进去。
第六，留证据。异常调用记录、消费时间、收到的通知邮件，全部截图存档。真要向服务商申请调查或费用处理，这些是唯一能拿出来的东西。
一个容易被忽略的细节
这次泄露的是「存在 workspace 里的第三方密钥」。也就是说，风险不在 OpenCode 自己的账号体系，而在它替你保管了别家的长期凭据。
这让我重新看了一遍自己在用的所有工具。凡是要求我粘贴长期 API key 的第三方平台，本质上都是在替我承担一个我无法审计的风险。它可能很正规，也可能明天就出一个 legacy system 的公告。
能自己控的，尽量自己控。中转、聚合、代理这类服务确实方便，但便利的代价是把凭据交出去。这个 trade-off 值不值，取决于那个 key 背后挂着多少额度。
最后
API key 在今天的位置，大概相当于十年前的生产数据库密码。它不该被随手贴在任何一个「方便」的控制台里，也不该只有一个、用一整年。
这次 1.4% 的人替所有人交了一次学费。没被波及的人，最好也把这六件事做一遍——不是因为一定会再发生，而是因为它一定会再发生。
文章评论