刚刚过去的周末，技术社区里除了关于
在没有任何高并发任务、也没有跑任何压力测试的深夜，在后台绑定了大模型 API 密钥的账户，正被陌生人疯狂调用 Token 配额。一旦他们获得了密钥，便毫不留情地继续攻击那些高级用户。
有人在睡梦中被刷走 400 美元；有人在几小时内配额被抽干，导致 Google Cloud 生产账号直接触发反欺诈风控遭全盘停摆；更有受害者一觉醒来，面对的是单日超过 1700 美元的巨额账单。
图注：OpenAI 在一天内的支出超过了 700 美元
图注：一位受影响用户的 OpenCode 仪表板显示，其每月配额已被完全使用。
这场迅速在 Reddit、X 和 Hacker News 发酵的安全事故，将矛头指向了 GitHub 标星超过 21 万的当红开源 AI 编程工具 OpenCode。
OpenCode 随后承认，一套正在停用的旧系统遭到未授权访问，波及 1.4%的云端 Console 用户，存放其中的第三方模型 API 密钥可能泄露。Anthropic、OpenAI、Google 三大模型厂商被卷入善后，部分密钥遭紧急撤销。
OpenCode 承认，该起事故影响了 1.4%的 Console 用户，并将其与一场“大规模模型蒸馏攻击”联系起来。Anthropic、OpenAI 和 Google 三家模型厂商随后被卷入善后，部分密钥遭到紧急撤销。
但比泄露更让人头疼的是，攻击还在持续。
当地时间 10 月 18 日，OpenCode 联合创始人 Dax Raad 透露，过去 48 小时里，黑客一直在尝试攻击他们的系统。团队连夜调查、加固防线，却遇到另一件尴尬事：用于分析攻击的前沿 AI 模型，干活干到一半，竟因网络安全限制开始拒绝配合。直到获得 OpenAI Daybreak Blue 的访问权限，情况才有所改善。
更戏剧性的是，连 Dax 本人的个人账号也成了攻击目标。 他在 X 上无奈感叹：“我的个人账号现在也开始遭受攻击了。AI 驱动的黑客攻击，正在创造一个全新的世界。”
这一幕，与几个月前 Hugging Face 遭 AI Agent 入侵后的调查经历颇为相似。
然而，比持续攻击更具争议的，是 OpenCode 对这场事故的解释。官方将事件与“大规模模型蒸馏攻击”联系起来，却引发了开发者和 AI 研究者的质疑：明明是云端系统被攻破、用户付费密钥可能泄露，为什么要用“模型蒸馏”来解释这场安全事故？
API 账单被刷爆
与传统互联网时代只窃取账号密码或脱库用户名单的数据泄露不同，在以大型语言模型（LLM）为核心构建的工作流中，API 密钥（API Key）的失窃等于直接将绑着开发者信用卡的无底限扣费副卡拱手送人。
最早在社交网络上公开遭遇的开发者，记录下了一场惊心动魄的深夜失血。
一位开发者在社交平台晒出后台监控：在短短几小时的夜间空窗期内，其 Anthropic 账户在完全未经本人授权的情况下，产生了高达 400 美元的异常账单。调用日志显示，攻击者在短时间内以高频并发的方式持续请求最顶级的 Claude 3.5 Sonnet 模型，直至触发阶段性限制。
但这仅仅是一个开始。随着更多受害者涌入社区互相对账，被盗刷的金额上限被迅速刷新：
另一位使用 OpenAI 模型的开发者晒出账单，其账户在单日内出现超过 700 美元的非正常算力峰值，额度在极短时间内被暴力吃光；
一位在 Google Cloud 上配置了 Vertex AI 凭证的用户报告，其云服务 API 费用在数小时内突增逾 1000 美元，激增的调用不仅耗尽了全部预付配额，还直接触发了 Google 针对欺诈和滥用行为的自动化安全风控机制，导致其关联的整个 Google Cloud 生产工程账号遭系统级紧急停摆；
损失最惨重的受害者，单日未经授权的调用金额最终被定格在令人肉痛的 1700 美元以上。
所有的受害者都在寻找彼此之间的交集。他们没有将密钥提交到 GitHub 公开仓库，也没有在本地运行任何来历不明的恶意脚本。
唯一的共同点就是：他们都使用了 OpenCode，并且为了跨设备同步编程环境或与团队成员协同，将自己在 Anthropic、OpenAI、Google 以及
与直接在本地使用 OpenCode 不同，Console 允许开发者将第三方模型 API 密钥保存在云端，统一管理模型调用，并供团队成员共享使用，而不必向每个人暴露原始密钥。
便利的另一面，是付费模型的调用凭证集中到了 OpenCode 手中。
这些 API 密钥本质上就是访问付费模型服务的凭证。 如果没有有效的来源限制、调用额度或消费预警，一旦密钥泄露，攻击者就可能绕过 OpenCode，直接向 Anthropic、OpenAI 等模型服务商发送请求。
黑客不需要入侵开发者的电脑，也不需要登录受害者的 OpenCode 账户。只要在远程拿到了这串字符，且请求没有被服务商的安全机制拦截，就可能持续消耗原用户的付费额度。
“模型蒸馏攻击”？开发者不买账
恐慌蔓延至事发次日，OpenCode 官方终于打破沉默，向受影响用户发送了紧急警报邮件，并在社交平台 X 上发布了官方通报。
官方在通报中承认了安全漏洞的存在，并披露受影响的用户占其 OpenCode Console 用户总数的 1.4%。但真正引爆舆论的，是官方对这起事故性质的定调——OpenCode 声明称，这起事件与一场“针对前沿模型的大规模模型蒸馏攻击（Large-scale Distillation Attack）”相关。
所谓“模型蒸馏”，是指攻击者通过大批量构造复杂的提示词，调用行业顶尖模型（如 Claude 3.5 Sonnet、GPT-4o）生成海量高质量问答数据，再将这些高阶模型的输出作为训练集，去微调或蒸馏出自己低成本的开源模型。
OpenCode 的公关修辞试图向外界传达一个潜台词：这是一场极具技术含量、针对 AI 最前沿领域的对抗性科研窃取，而平台只是不幸沦为了黑客获取训练数据的算力跳板。然而，这套精心包裹的高技术话术，在发出后短短几小时内就遭到了中英文技术社区与资深安全专家的集体反驳与质疑。
图注：知名研究员 Nathan 也对“蒸馏攻击”的说法提出了异议
多位从事工业级 LLM 训练的算法工程师与安全从业者指出，“大规模模型蒸馏”的说辞在工程逻辑上漏洞百出：
- 调用特征完全脱节：工业级的模型蒸馏是一套高度依赖持续性、稳定性和结构化数据吞吐的工程管线。要完成一次有效的蒸馏训练，通常需要稳定调用数百万甚至上千万对高质量 Prompt-Completion。
而黑客从 OpenCode 窃取的这批个人开发者凭证，额度碎片化极强，且绝大部分账户在被刷到几百至一千美元时就会因触发信用卡限额、账户余额不足或被用户手动掐断而失效。没有任何成熟的算法团队会冒险将核心数据管线建立在这些随时暴毙的零散凭据之上。
- 凭据失窃才是本质，蒸馏只是下游变现：技术社区一针见血地指出，无论攻击者拿到 Key 之后是用于模型蒸馏、生成垃圾邮件、挂接自动化渗透，还是转手挂到暗网的 API 倒卖转接池（Proxy Pool）中套现，这起事件的底层性质只有一个——凭证失窃（Credential Theft）。
将下游可能存在的数据调用用途直接命名为攻击类型，有明显的转移视线、用前沿概念对冲自身安全责任的公关嫌疑。
更关键技术细节随后被曝光：OpenCode 在发给受影响用户的安全通知中承认，攻击者入侵的切入点并非什么高深未知的零日漏洞（0-day），而是“一套官方正在执行停用流程（in the process of decommissioning）的遗留系统”。
这暴露了极其严重的云基础设施安全生命周期管理漏洞。一套本应彻底隔离、下线的废弃服务，在缺乏运维监管的状态下继续暴露在公网上。更荒谬的是，这套本该废弃的系统内部，居然一直保留着对生产环境 Secrets 数据库，也就是存放用户明文或弱加密 API 密钥的凭证库的高权限读取通道。
黑客甚至不需要正面攻破坚固的现代防护层，他们只是找到了一扇团队忘记上锁的旧侧门，便轻而易举地端走了数以千计开发者的“钱包”。
48 小时攻防与善后
如果说最初两天的焦点还是密钥泄露，那么最新的故事，则开始转向持续不断的网络攻防。
10 月 18 日，OpenCode 联合创始人 Dax Raad 再次公开发声，透露攻击者在过去整整 48 小时里，从未停止过对 OpenCode 系统的狂轰滥炸。面对这种高频冲击，他感叹防守方如今也必须让 AI Agent 7×24 小时不间断工作，因为攻击者早就已经这么做了。
但在这场以 AI 对抗 AI 的防御战中，OpenCode 团队却遭遇了极其尴尬的一幕。开发者 Rhys Sullivan 在社交平台上向 Dax 询问：“你们在调用前沿模型排查时，是否被其网络安全防护机制拦截了？”
Dax 给出了肯定的答复。他坦言，在事故排查进行到一半时，这种情况让人极度沮丧——团队调用的前沿商业大模型在协助完成了部分日志与代码分析后，因排查上下文中包含大量漏洞特征与攻击载荷，突然触发了内置的安全护栏，坚决判定内容违规并拒绝继续处理后续请求。
这并非防守方第一次被自家的 AI 工具“缴械”。
今年 7 月，开源 AI 社区 Hugging Face 披露遭遇由 AI Agent 驱动的安全入侵。在其事后发布的技术报告中，面对超过 1.7 万条攻击记录，安全团队同样使用 AI Agent 来还原攻击路径，却屡次因触发前沿模型的安全拦截机制而受阻，最终不得不引入开源模型 GLM 5.2 辅助才完成了日志逆向。
两起事件虽有技术差异，但它们共同撕开了生成式安全的一个现实悖论：当真正的网络安全调查需要拆解攻击载荷时，大模型通用的安全护栏往往敌友不分，反倒先锁死了授权防守方的双手。
而对于遭受实际财产损失的开发者来说，最核心的问题只有一个：被盗刷的真金白银，到底能不能退？
转机最先在 OpenAI 侧出现。刚刚，OpenAI 安全团队成员 Tibo（@thsottiaux）随后公开发帖证实：OpenAI 团队已与 OpenCode 展开合作，不仅协助受影响的 OpenAI API 客户恢复业务运营，同时还将全额退还在本次攻击期间被异常扣除的所有积分与算力额度（credits refunded）！
图注：OpenAI 团队成员 Tibo 确认已介入善后，将全额退还受影响用户在攻击期间被盗刷的额度，并呼吁防御者尽早申请 Daybreak Blue 权限。
这场持续数十小时的攻防闹剧，给所有使用大模型工具的开发者敲响了一记沉重的警钟：
将 API Key 托管给第三方 AI 工具，交出去的从来不只是一项代码补全的权限，更是一张直接绑定了个人信用卡、随时可能产生实质扣费的无底限授权。在中心化工具平台尚无力提供金融级隔离防护的当下，最稳妥的安全策略依然朴素：不要将 API Key 轻易托管给任何第三方云端控制台，能放本地环境变量，就不要轻易传到云端。
本文来自微信公众号 “AI前线”（ID：ai-front），作者：青和，36氪经授权发布。