OpenCode 被黑：「密钥托管」模式的安全账单，一夜到期

10 月 17 日，开源编码工具 OpenCode 披露安全事件：一场持续整夜的大规模「蒸馏攻击」（distillation attack）影响了 1.4% 的 OpenCode Console 用户——具体说，是那些把自己的 Anthropic、OpenAI、Google 等外部 API 密钥链接到 Console 托管的用户。HN 首页 740 分，事件处置仍在进行中。

发生了什么

攻击者高频率调用模型服务收割响应（官方称之为「蒸馏攻击」——用别人的算力练自己的模型），导致受影响用户出现突然的巨额账单；部分用户的 API 密钥遭到泄露。OpenCode 官方的提醒借用了加密圈那句名言：「Not your keys, not your tokens（不是你的密钥，就不是你的 token）」——把密钥交给第三方托管，密钥的风险边界就不再由你控制。官方建议受影响用户立即轮换/撤销相关密钥，并核查各 provider 的账单流水。

值得注意的是 OpenCode 并非没有前科：今年 1 月有 markdown 渲染器 XSS（CVE-2026-22813），9 月更是爆出无需认证的 RCE（CVE-2026-22812）——攻击者可获得用户本地环境的完全控制。三天前我们刚报道过 OpenCode 2.0 的服务化改版（架构层面相当漂亮），这次事件恰好补上了另一半教训：架构好坏与运营安全是两回事。

对企业的三条立即行动

1. 1排查自家开发终端：团队里有人用 OpenCode Console 并链接了自有 API 密钥的，今天就轮换密钥、查账单——这是本次事件的标准处置；
2. 2「密钥托管」一律重新评估：凡是要求你把 API 密钥存到第三方平台的服务（不只 OpenCode），问清加密方式、泄露责任与赔付条款；能走企业级代理网关（密钥不出内网）就不要明文托管；
3. 3给 AI 工具链上账单告警：本次攻击最早暴露的信号是「突然的巨额消耗」——各 provider 的支出告警阈值设好，异常消耗比异常行为更容易被先发现。

agent 工具的信任链如今和它们能写的代码一样长。这个案例值得加进贵司的供应商安全评估清单。