Hacker News 中文摘要

RSS订阅

OpenCode 遭入侵，用户凭证泄露 -- OpenCode Hacked: User credentials leaked

原文链接 | HN讨论 | 2026-10-18 04:29:56

开放代码（OpenCode）昨晚发生了一起安全漏洞，与大规模蒸馏攻击有关，影响了 1.4% 的开放代码控制台（OpenCode Console）用户。我们今早已通过电子邮件通知所有受影响用户。目前事件仍在持续，暂时无法分享更多细节，但正在与 Anthropic（Anthropic）、开放人工智能（OpenAI）和谷歌（Google）协作进行修复。

正文

  • OpenCode（@opencode）在 2026 年 10 月 17 日下午 5 点 56 分于 X 发帖称：昨晚，我们遭遇了一起安全漏洞，与一次大规模蒸馏攻击有关，影响了 1.4% 的 OpenCode Console 用户。我们已于今天上午通过电子邮件通知了所有受影响的用户。事件仍在处理中，目前无法分享更多细节，但我们正在与 Anthropic、OpenAI 和 Google 合作进行补救。

  • Stoven（@lol_gogy94668）回复说：“138 美元没了。我们会得到赔偿吗？”

Image 3: Avatar

Image 4: Anomaly

  • Tom Zarebczan（@TomZarebczan）回复说：“一次泄露了密钥的蒸馏攻击？嗯……”

Image 5: @lol_gogy94668

Image 6: @TomZarebczan

  • Vineeth（@vineeth_agi）回复说：“wtf 😭 🙏🙏”，并附上了一张图片。

Image 7: @vineeth_agi

Vineeth 回复中的图片

Image 10

评论

整体讨论以强烈质疑和批评为主，多数人指责 OpenCode 将用户的第三方 API 密钥存于云端后端、缺乏隐私条款与透明度，且早有预警却被忽视或压帖。分歧主轴集中在究竟只有云端 BYOK 用户受影响还是本地用户也不安全，以及所谓“蒸馏攻击”如何导致密钥泄露仍无人说清；此外还有对团队公关作派的幸灾乐祸和投票争议。

认为 OpenCode 早有安全隐患预警，却被团队或粉丝压下

  • 多位用户翻出数十天前的警告，称 OpenCode 会把数据泄露给自己和可疑第三方，作者在 GitHub 议题中装作不知情且从未修复，VirusTotal 也早就标记过它；这次事故被视为“我早说过”的印证。（认可度：高赞） > 我早就说过：OpenCode 会把你所有数据泄露给他们自己和来路不明的第三方，作者一直装傻且从未修复。（@bewareofscams）
  • 少数人质疑为何早期预警评论被踩或标记，怀疑有人出于对项目的喜爱在操控投票；通报作者也表示 OpenCode 团队或粉丝不满该帖上首页，已遭大量标记，因此公开求赞。（认可度：少数人）

批评云端代存第三方 API 密钥的做法疯狂且不透明

  • 用户指出 OpenCode Zen 等云端服务让用户在登录后添加 OpenAI、Anthropic 等提供商的 API 密钥，却完全没有服务条款、隐私政策或密钥存储说明，也没有任何警告。（认可度：较多人） > 在控制台里添加 API 密钥，却找不到任何服务条款、隐私政策或存储说明，这就像把密码或加密货币私钥交给别人保管。（@latchkey）
  • 还有用户困惑既然 OpenCode 是开源项目为何需要上传凭证，担心本地运行时的密钥也被发送到后端服务器，官方对此始终没有说明。（认可度：少数人）

质疑事件影响范围与技术细节，要求官方澄清并复盘

  • 官方称事故缘起一个正在退役的旧系统遭未授权访问，工作区里保存的第三方密钥可能泄露；但不少人搞不懂通报里“安全漏洞”与“大规模蒸馏攻击”的关系，也不确定是否只影响把 BYOK 密钥存到 OpenCode Zen 等云端托管服务的用户，本地自带凭证运行是否安全。有人怀疑是供应链攻击感染了程序本身，大家都在等详细复盘。（认可度：较多人） > 所谓安全漏洞和大规模蒸馏攻击到底怎么联系起来的？难道是说一堆凭证被偷去拿来做蒸馏了？（@searealist）
  • 部分用户担心自己的账户额度已被盗刷，醒来会发现 Anthropic、OpenAI 等账号被刷爆；但在官方分享更多信息前，谁也说不清受影响的人到底有多少。（认可度：较多人）

对 OpenCode 团队作风不满，出现幸灾乐祸情绪

  • 少数人开玩笑称，如果这次泄露导致用户 OpenAI 等额度被异常刷光，反而有些好笑；因为该团队员工在网上的发言作派让人很难同情。（认可度：少数人） > 如果这次泄露导致大家的 OpenAI 额度被刷爆，那还挺好笑；以他们员工在网上那副作派，我实在同情不起来。（@monster_truck）

有价值的补充

  • 反直觉的技术点：花大力气做虚拟化沙盒隔离并不能防御此类密钥泄露，真正有效的是把 API 密钥代理并隐藏、不让智能体直接接触；换句话说，深度防御应针对密钥访问路径，而不是执行环境沙盒。半年前就卸载该工具、直接使用 Codex 和 Claude Code 的人反而躲过一劫。 > 虚拟化沙盒隔离在此类事件中毫无帮助，反而是把 API 密钥代理并隐藏、不让智能体接触的方案能起到深度防御作用。（@TZubiri）
  • 有开发者建议所有 API 密钥系统都应提供集中失效端点，例如 invalidateapikey；一旦发生泄露，存储方或白帽可以一键吊销全部密钥，而不是像现在这样让用户收到邮件后各自手动撤销，陷入与时间的赛跑。 > 每个 API 密钥系统都应该有一个失效接口，比如 invalidateapikey，这样泄露时存储方或白帽能一键作废所有密钥，现在却只能靠大家各自手动处理，争分夺秒。（@Ciantic）
  • 冷知识：模型 API 令牌的价值已经大到让攻击者愿意投入大量时间和精力来窃取密钥，这也解释了为何泄露 BYOK 密钥后果严重。（@MisterMunchkin）