大批API账户被刷爆！OpenCode遭黑客围攻48小时，官方甩锅“蒸馏攻击”被质疑

API密钥泄露致开发者账户被疯狂盗刷

刚刚过去的周末，技术社区里除了关于DeepSeek-v4.1-Flash-1017新模型发布的狂欢，还有一群开发者被突如其来的API账单吓了一跳！在没有任何高并发任务、也没有跑任何压力测试的深夜，在后台绑定了大模型API密钥的账户，正被陌生人疯狂调用Token配额。一旦他们获得了密钥，便毫不留情地继续攻击那些高级用户。

有人在睡梦中被刷走400美元；有人在几小时内配额被抽干，导致Google Cloud生产账号直接触发反欺诈风控遭全盘停摆；更有受害者一觉醒来，面对的是单日超过1700美元的巨额账单。

这场迅速在Reddit、X和HackerNews发酵的安全事故，将矛头指向了GitHub标星超过21万的当红开源AI编程工具OpenCode。

旧系统未下线致密钥库被攻破

OpenCode随后承认，一套正在停用的旧系统遭到未授权访问，波及1.4%的云端Console用户，存放其中的第三方模型API密钥可能泄露。Anthropic、OpenAI、Google三大模型厂商被卷入善后，部分密钥遭紧急撤销。

OpenCode承认，该起事故影响了1.4%的Console用户，并将其与一场“大规模模型蒸馏攻击”联系起来。Anthropic、OpenAI和Google三家模型厂商随后被卷入善后，部分密钥遭到紧急撤销。

但比泄露更让人头疼的是，攻击还在持续。

当地时间10月18日，OpenCode联合创始人DaxRaad透露，过去48小时内，黑客一直在尝试攻击他们的系统。团队连夜调查、加固防线，却遇到另一件尴尬事：用于分析攻击的前沿AI模型，干活干到一半，竟因网络安全限制开始拒绝配合。直到获得OpenAIDaybreakBlue的访问权限，情况才有所改善。

更戏剧性的是，连Dax本人的个人账号也成了攻击目标。他在X上无奈感叹：“我的个人账号现在也开始遭受攻击了。AI驱动的黑客攻击，正在创造一个全新的世界。”

这一幕，与几个月前HuggingFace遭AIAgent入侵后的调查经历颇为相似。

“蒸馏攻击”定性引发广泛质疑

然而，比持续攻击更具争议的，是OpenCode对这场事故的解释。官方将事件与“大规模模型蒸馏攻击”联系起来，却引发了开发者和AI研究者的质疑：明明是云端系统被攻破、用户付费密钥可能泄露，为什么要用“模型蒸馏”来解释这场安全事故？

所谓“模型蒸馏”，是指攻击者通过大批量构造复杂的提示词，调用行业顶尖模型（如Claude3.5Sonnet、GPT-4o）生成海量高质量问答数据，再将这些高阶模型的输出作为训练集，去微调或蒸馏出自己低成本的开源模型。

OpenCode的公关修辞试图向外界传达一个潜台词：这是一场极具技术含量、针对AI最前沿领域的对抗性科研窃取，而平台只是不幸沦为了黑客获取训练数据的算力跳板。然而，这套精心包裹的高技术话术，在发出后短短几小时内就遭到了中英文技术社区与资深安全专家的集体反驳与质疑。

多位从事工业级LLM训练的算法工程师与安全从业者指出，“大规模模型蒸馏”的说辞在工程逻辑上漏洞百出：

1. 调用特征完全脱节：工业级的模型蒸馏是一套高度依赖持续性、稳定性和结构化数据吞吐的工程管线。要完成一次有效的蒸馏训练，通常需要稳定调用数百万甚至上千万对高质量Prompt-Completion。

   而黑客从OpenCode窃取的这批个人开发者凭证，额度碎片化极强，且绝大部分账户在被刷到几百至一千美元时就会因触发信用卡限额、账户余额不足或被用户手动掐断而失效。没有任何成熟的算法团队会冒险将核心数据管线建立在这些随时暴毙的零散凭据之上。

2. 凭据失窃才是本质，蒸馏只是下游变现：技术社区一针见血地指出，无论攻击者拿到Key之后是用于模型蒸馏、生成垃圾邮件、挂接自动化渗透，还是转手挂到暗网的API倒卖转接池（ProxyPool）中套现，这起事件的底层性质只有一个——凭证失窃（CredentialTheft）。

将下游可能存在的数据调用用途直接命名为攻击类型，有明显的转移视线、用前沿概念对冲自身安全责任的公关嫌疑。

更关键技术细节随后被曝光：OpenCode在发给受影响用户的安全通知中承认，攻击者入侵的切入点并非什么高深未知的零日漏洞（0-day），而是“一套官方正在执行停用流程（in the process of decommissioning）的遗留系统”。

这暴露了极其严重的云基础设施安全生命周期管理漏洞。一套本应彻底隔离、下线的废弃服务，在缺乏运维监管的状态下继续暴露在公网上。更荒谬的是，这套本该废弃的系统内部，居然一直保留着对生产环境Secrets数据库，也就是存放用户明文或弱加密API密钥的凭证库的高权限读取通道。

黑客甚至不需要正面攻破坚固的现代防护层，他们只是找到了一扇团队忘记上锁的旧侧门，便轻而易举地端走了数以千计开发者的“钱包”。

48小时AI攻防与模型安全悖论

如果说最初两天的焦点还是密钥泄露，那么最新的故事，则开始转向持续不断的网络攻防。

10月18日，OpenCode联合创始人DaxRaad再次公开发声，透露攻击者在过去整整48小时内，从未停止过对OpenCode系统的狂轰滥炸。面对这种高频冲击，他感叹防守方如今也必须让AIAgent7×24小时不间断工作，因为攻击者早就已经这么做了。

但在这场以AI对抗AI的防御战中，OpenCode团队却遭遇了极其尴尬的一幕。开发者RhysSullivan在社交平台上向Dax询问：“你们在调用前沿模型排查时，是否被其网络安全防护机制拦截了？”

Dax给出了肯定的答复。他坦言，在事故排查进行到一半时，这种情况让人极度沮丧——团队调用的前沿商业大模型在协助完成了部分日志与代码分析后，因排查上下文中包含大量漏洞特征与攻击载荷，突然触发了内置的安全护栏，坚决判定内容违规并拒绝继续处理后续请求。

这并非防守方第一次被自家的AI工具“缴械”。

今年7月，开源AI社区HuggingFace披露遭遇由AIAgent驱动的安全入侵。在其事后发布的技术报告中，面对超过1.7万条攻击记录，安全团队同样使用AIAgent来还原攻击路径，却屡次因触发前沿模型的安全拦截机制而受阻，最终不得不引入开源模型GLM5.2辅助才完成了日志逆向。

两起事件虽有技术差异，但它们共同撕开了生成式安全的一个现实悖论：当真正的网络安全调查需要拆解攻击载荷时，大模型通用的安全护栏往往敌友不分，反倒先锁死了授权防守方的双手。

而对于遭受实际财产损失的开发者来说，最核心的问题只有一个：被盗刷的真金白银，到底能不能退？

转机最先在OpenAI侧出现。刚刚，OpenAI安全团队成员Tibo（@thsottiaux）随后公开发帖证实：OpenAI团队已与OpenCode展开合作，不仅协助受影响的OpenAIAPI客户恢复业务运营，同时还全额退还在本次攻击期间被异常扣除的所有积分与算力额度（creditsrefunded）！

企业部署需重新评估第三方密钥托管风险

这场持续数十小时的攻防闹剧，给所有使用大模型工具的开发者敲响了一记沉重的警钟：将APIKey托管给第三方AI工具，交出去的从来不只是一项代码补全的权限，更是一张直接绑定了个人信用卡、随时可能产生实质扣费的无底限授权。在中心化工具平台尚无力提供金融级隔离防护的当下，最稳妥的安全策略依然朴素：不要将APIKey轻易托管给任何第三方云端控制台，能放本地环境变量，就不要轻易传到云端。