OpenCode 密钥泄露：被黑的不是 CLI，是没人分得清的 Console
OpenCode 宣布一个 legacy 系统被未授权访问，用户存在 OpenCode Console 里的 OpenAI、Anthropic 等第三方 API Key 可能泄露。本期访谈聊 HN 评论区的几场争论：Console 与 CLI 的命名灾难、被盗 Key 拿去「蒸馏」的传闻、帖子被 flag 压排名的 drama，以及泄露之后和时间赛跑的密钥吊销。
昨天深夜，HN 头条被一条安全新闻占了：AI 编程工具 OpenCode 发公告，一个正在下线的 legacy 系统遭到未授权访问，用户存在里面的 OpenAI、Anthropic 等第三方 API Key 可能已经泄露。帖子拿下 700 多赞、120 多条评论，但评论区吵得最凶的不是黑客手法，而是——被黑的到底是什么。最高赞评论干的第一件事就是纠正标题：出事的是 OpenCode Console，一个 OpenRouter 式的 hosted 模型中转服务，跟大家天天用的 OpenCode CLI 编程 agent 完全不是一回事。我请来应用安全工程师林深，聊聊 BYOK 的原罪、和时间赛跑的密钥吊销，以及为什么「Console」这三个字值一次品牌灾难。
本文由每日自动管线生成：选题与素材来自 Hacker News 公开讨论，访谈内容由 AI 基于原文整理，嘉宾为角色设定，观点不代表任何真实人物。
小听： 林深，先帮大家把影响范围钉死。OpenCode 的公告说 legacy 系统被未授权访问，存在里面的第三方 provider key 可能泄露。到底谁该紧张？
林深： 一句话：在 OpenCode Console 里粘贴过自己的 OpenAI、Anthropic、Google 这些 key 的人，该紧张。只用 OpenCode CLI 在本机跑、key 只存在自己机器上的人，不受影响。团队在邮件里写得很直白：请去各 provider 的后台 revoke 并更换 key，检查近期用量有没有异常，公告原文是用户贴到评论区里的，语气相当克制——「我们很抱歉发生了这种事」。
小听： 但 HN 最高赞评论干的第一件事，是纠正标题。redsymbol 说：泄露的是「OpenCode Console」，类似 OpenRouter 的服务，「用 CLI 的人根本不受影响」。
林深： 这是整件事里最贵的一课，叫命名灾难。Console 这个词，任谁听了都以为是 CLI 的控制台。团队的公告没有把这个区别讲清楚，Console 本身在网上几乎找不到文档——redsymbol 的原话是，团队「在沟通上做得一塌糊涂，这笔账得记在他们头上」。结果就是：几十条评论都在问「我的 CLI 是不是也被黑了」，恐慌先扩散了一轮，澄清才追上来。安全事件里，含糊其辞的公告本身就是二次伤害。
小听： 真实伤害已经有人晒出来了。评论区 jprokay13 说，一早同时收到两封邮件：OpenCode 通知他 key 可能泄露，Anthropic 通知他当月 20 美元额度被用完了。他最后补了一句：希望他们用这些 token 做了点酷的东西。
林深： 黑色幽默背后是个硬问题：OpenCode 有没有能力替用户兜底？评论区 tekacs 点得很准——泄露的是存在 OpenCode 后端的用户自带 key，一旦被刷，OpenCode 根本没有退款能力，因为钱是直接从用户的 provider 账户扣的。BYOK 模式下，平台只是个「钥匙保管员」，保管员弄丢了钥匙，丢的却是你家的东西。
你把钥匙交给别人保管，就要接受别人家的门锁标准。
小听： 说到 BYOK，评论区 latchkey 还原了 Console 的开户体验：登录网站，列出一排 provider，点一下、粘贴 key，就能用了。但 key 在后端怎么存的、存多久，完全没有文档，连 ToS 和隐私政策都找不到。
林深： 这就是 BYOK 的原罪时刻。你把相当于密码的东西交给第三方保管，正常流程应该是：告诉我你怎么存、存多久、谁能碰、出事了怎么办。OpenCode Console 这几样全没讲。有人辩护说 OpenRouter 也有同样的 BYOK 功能——这是事实，但「别人也这样」不是安全论证，是免责话术。zephiel7 那句很刻薄但值得记：打着 open and free 的旗号，却把用户的 API token 存在自家服务器上。
小听： 另一个让评论区炸锅的传闻是「蒸馏攻击」：有人猜黑客偷 key 不是为了转卖，而是拿去跑巨量调用、蒸馏训练自己的模型。
林深： 目前没有任何公开证据，OpenCode 自己也没细说——vdfs 说得实在，事件还在处理中，他们不想放细节。但这个猜想能传开，是因为它符合经济学：MisterMunchkin 那句「token 值钱到值得大费周章去偷」是全场最冷静的判断。malisper 还贴了 token 中转黑市的分析，说明被盗 key 的变现链路早就成熟了。至于 nacs 的黑色幽默——「攻击者可能直接让 AI 去黑 OpenCode 的网站，让它跑几个小时直到成功」——笑完要想一层：当攻击工具本身就是 AI，试错成本趋近于零，legacy 系统这种没人看的角落就成了首选入口。
小听： HN 自己的 drama 也值得聊：发帖人 pranshuchittora 说帖子被大量 flag，Barbing 贴出数据，raw rank 第一的帖子在首页只排到十名开外。有人讽刺，团队花在「控评」上的精力要是用在安全上就好了。
林深： 先说事实层面：flag 在 HN 算法里相当于超级 downvote，大量 flag 确实能压排名；但另一边也有人指出，这个标题本身就容易招 flag——「OpenCode 被黑」确实没写 Console。两边都有道理。我更在意 ryandrake 那句刺：被攻破之后搞 brigading 和 astroturfing，不如当初把系统加固好。不管压排名是否存在，一个安全事件的公关动作一旦显得在「捂」，信任崩塌的速度会比 key 泄露更快。pranshuchittora 那句「trust is already broken」，可能比事件本身更伤。
泄露之后，比的不是谁更无辜，是谁跑得快。
小听： 技术讨论里最有建设性的一条，是 Ciantic 的提议：每个 API key 系统都应该有个 invalidate_api_key 端点，泄露发生后，吊销应该是一键的事，而不是让每个用户自己去后台翻。
林深： 方向是对的：泄露响应是和时间的赛跑，Tiberium 分享的「偏方」很说明问题——把泄露的 key 贴到公开 gist，GitHub 的 secret scanning 合作伙伴会自动通知各家 revoke，十几秒就够。这其实是用现成的基础设施补了缺失的一键吊销。但 orf 的反驳也要听：如果吊销端点是公开可调的，它本身就成了 DoS 武器——任何人都能替你「吊销」你的 key。shepherdjerred 的回怼也很真实：真到 key 泄露那一刻，你宁愿服务断一会儿，也不愿醒来发现账单被刷爆。安全设计里没有免费选项，只有「你愿意为哪种糟糕买单」。
小听： 给普通开发者列个行动清单吧。看完这期，最该做的三件事是什么？
林深： 第一，用过 OpenCode Console 的，现在就去 OpenAI、Anthropic、Google 的后台把 key revoke 掉、换新的，再查一遍用量曲线有没有异常——别等 OpenCode 的后续公告。第二，以后用任何 BYOK 服务，先看三样：支不支持 spend limit 和用量告警、key 能不能设短期有效期、有没有出事时的吊销通道；三样全无的，默认按「会丢」来用。第三，CLI 本机用户这次没事，但顺手检查一下：别把 key 写进 agent 能直接读到的 .env 或 workspace 里——key 一旦进了 agent 的上下文，边界就模糊了。最后送一句：legacy 系统是每家公司的化粪池，OpenCode 说「正在下线中」的系统被端了，一点也不意外；意外的是，装着用户真金白银 key 的系统，居然可以「正在下线」这么久。
这次事件里，黑客只黑了一个没人看的 legacy 角落，但 OpenCode 丢的东西远不止 key——含糊的公告、找不到的文档、没有退款能力的 BYOK 架构，再加上疑似控评的公关动作，每一件都在给信任放血。而 HN 评论区真正值钱的，是那几条把教训变成机制的讨论：一键吊销、spend limit、别把 key 交给说不清存储方式的人。技术细节会过时，这几条不会。本文观点仅代表访谈角色设定，原始讨论见参考链接。