2026年10月16日晚，开源AI编程工具OpenCode的多名用户发现，自己账上的API额度在一夜之间被“洗劫”一空。
紧随其后，官方确认：攻击者未经授权访问了该公司一个正处于停用流程中的旧系统，可能泄露了约1.4%的OpenCode Console用户存储的第三方AI服务商API密钥，涉及OpenAI、Anthropic、谷歌等主流模型服务；有开发者被直接刷走超过1700美元。
更值得警惕的是，黑客窃取密钥的目的并非倒卖账号或窃取个人数据，而是“借”开发者的账单，大规模调用GPT、Claude、Gemini等顶级模型，为训练自己的模型“白嫖”高质量语料。围绕AI模型能力的“工业级蒸馏”攻防战，第一次以如此直接的方式烧到了普通开发者身上。
一、一夜之间：开发者账户被“洗劫”
事发非常突然。当地时间10月16日晚，Reddit、X等平台陆续有开发者晒出异常账单：后台的Token调用量像“坐了火箭”一样垂直拉升，余额直接被干到零，甚至触发了自动充值。
有用户反映，自己的Anthropic账户在毫不知情的情况下被狂刷400美元；还有人Google Cloud的API账单直接爆表，背上了1000多美元的扣款。据科技媒体The Hacker News援引Dealroom的报道，开发者Preston Zeller自述总损失达1700美元；另一位开发者Colin Parsons称，其OpenAI密钥被用于281美元的未授权调用、Anthropic密钥被用于168美元的调用。科技博主Max Weinbach也在X上证实：“我的OpenAI和Anthropic余额被耗尽，谷歌账户被限制并消耗了一部分余额。”
眼看火越烧越大，OpenCode官方于10月17日在X上发文实锤：“昨晚我们遭遇了一起与大规模蒸馏攻击相关的安全漏洞，影响了1.4%的OpenCode Console用户。我们已于今天上午通过邮件通知了所有受影响用户。如果您未收到邮件，则说明您未受此事件影响；受影响的仅为关联了外部服务提供商的部分用户。”
据The Hacker News报道，官方邮件主题为“Action Required: Potential provider key breach”（需处理：潜在的服务商密钥泄露）。OpenCode同时在邮件中确认，攻击发生在当地时间10月16日晚间，涉及的是一个“正处于停用流程中的旧系统”。
最讽刺的是，在这场波及全网的黑客袭击中，连OpenCode创始人都没能幸免。官方声明发布后不久，OpenCode联创Dax Raad在X上发帖：“现在连我自己的个人账号也在遭受攻击。这波AI自动化黑客攻击，真是打开了一个全新的世界。”
二、漏洞根源：一个“准备下线”的旧系统
OpenCode在发给用户的邮件中交了底：这次捅出大篓子的，是一个“正准备下线的旧版老系统”，这套还没来得及关停的系统被攻击者直接“偷了家”，存储在用户工作区里的第三方服务商API密钥——包括OpenAI、Anthropic等——可能已经暴露。
要理解这次泄露的影响范围，需要先厘清OpenCode Console的架构。据The Hacker News报道，Console是OpenCode的可选托管服务：团队在工作区中保存自己的OpenAI、Anthropic或谷歌密钥，Console使用这些密钥调用模型服务商，团队成员可以在不看到真实密钥的情况下使用模型。正是这种“集中托管”的设计，使得一次内部系统被攻破，就可能波及大量用户的外部服务商账户。
值得注意的是，本次泄露与OpenCode本体并无直接关系。Dax Raad在X上回复网友时澄清，涉及的是“OpenCode Console，而非OpenCode本身”，命令行和桌面应用保存在本机SQLite数据库中的密钥“从未到过我们这里”。安全社区也提醒，应将“OpenCode Console”与日常使用的OpenCode编码Agent视作两个不同产品，本次受影响的是前者。
更深层的问题在于API密钥的“凭证”属性。服务商密钥是一种bearer凭证——谁持有副本，谁就能以账户持有人的名义发起计费请求，直到服务商撤销为止。The Hacker News特别指出：从Console中删除密钥并不会使其失效，因为Console无法代替用户去服务商处撤销签发；Console自身的预算限额也管不住那些不经过其网关的直连调用。换言之，密钥一旦流出，删配置、改密码都拦不住盗刷，唯一有效的动作是在签发密钥的服务商控制台将其作废。
这也不是OpenCode第一次暴露安全短板。据OfficeChai报道，2026年初，OpenCode曾被披露并修复一个编号为CVE-2026-22812的远程代码执行漏洞。多次安全事件叠加，使外界对其密钥托管体系的安全水平提出了更多疑问。
三、黑客意图：偷密钥“白嫖”顶级模型，训练自有AI
这次事件最“戏剧性”的部分，是黑客拿到密钥后的用途。按照OpenCode官方和多方转述的说法，攻击者既不是为了转卖密钥，也不是为了盗取个人聊天记录，而是拿着这些密钥去“训练自己的模型”。
蒸馏攻击的逻辑并不复杂：想要把小模型“喂”聪明，最核心的燃料是海量、高水准的思维链（CoT）和代码生成数据。如果直接购买OpenAI、Anthropic的API来生成这些训练数据，动辄需要耗费数百万甚至上千万美元；而且各大AI巨头早就在服务条款中禁止使用自家模型输出去训练竞品模型，并部署了严密的风控系统。
于是，黑客选择了“借刀杀人”——分布式白嫖开发者。通过攻破OpenCode这类第三方AI工具聚合平台，攻击者一次性拿到了成百上千个真实开发者的API密钥，在短短几个小时的窗口期内，把这些密钥里的每一分钱额度都转化为顶级大模型的高质量输出。整个过程，每一次Token消耗都记在受害开发者的账上。
AI行业观察平台TestingCatalog一针见血地指出，这开创了一个极其危险的先例——意味着使用中小型第三方服务商变得前所未有地危险：一次泄露不再是“一个平台出事”，而是“多家AI服务商账户同时被波及”。
四、“蒸馏攻击”定性之争
尽管OpenCode官方将本次事件定性为“与大规模蒸馏攻击相关的安全漏洞”，但这一说法在技术社区引发了争议。
AI研究者Nathan Lambert公开质疑：“如果一次窃取API密钥的网络攻击也被归入‘蒸馏’这个说法，那这个词的用法就有点奇怪了。”在他看来，从事件后果看——密钥被窃取并用于消耗第三方账户余额——这更接近典型的凭证窃取类网络攻击，而非严格意义上的模型蒸馏行为。TEN Brief在经多来源交叉核验后也指出，截至报道发布，OpenCode并未公布支撑“蒸馏”定性的技术证据。
需要客观呈现的是，OpenCode目前尚未披露的关键信息还有很多：攻击者究竟通过什么途径进入旧系统、在系统内驻留了多久、有多少密钥实际被窃取、1.4%对应的绝对用户数是多少、“蒸馏攻击”与密钥泄露之间的技术联系如何建立。OpenCode方面表示，因事件处置仍在推进，“现阶段暂不便披露更多事件细节”。在官方技术复盘出炉之前，“蒸馏”更接近于一个官方定性标签，而非已经证实的攻击全貌。
五、产业背景：蒸馏攻击已成“工业级”威胁
OpenCode事件之所以引发震动，与蒸馏攻击在行业内的“工业化”趋势密不可分。就在几周前，Anthropic于2026年9月10日发布了第四份威胁情报报告《Detecting and countering misuse of AI》（154页，覆盖2025年12月至2026年8月），指控7家中国AI实验室——包括阿里巴巴、月之暗面、DeepSeek、智谱、小米、MiniMax和商汤——实施了未经授权的“工业级”模型蒸馏，涉及总计约1.9亿次API交互。
据NeoTeo、Better Stack等转引报告内容：阿里巴巴被指在2026年5月至7月通过超过3500个欺诈账户发起逾1.51亿次Claude交互，峰值接近每日300万次，用于支持Qwen模型训练；月之暗面被指在10天内将近30万条客户请求转发至Claude，使用约5380个欺诈账户，累计交互超2300万次；DeepSeek被指在7月的14天内产生超过1210万次交互，并根据请求头中“claude-code”“opencode”等特征串，定向转发高价值的智能体编程请求。
在美方，NSA、CISA与FBI于2026年9月8日联合发布公告，点名6家中国公司，称其从事“工业级”蒸馏活动。中国商务部则于9月9日回应，驳斥相关指控“毫无事实与法律依据”，并警告若美方以模型蒸馏为由打压中国AI企业，中方将采取相应反制措施。
必须强调的是，上述指控均来自Anthropic单方发布的报告，未经第三方独立验证，报告发布时涉事企业尚未作出公开回应；本稿仅作事实呈现，不代表任何立场。与此同时，Anthropic在2026年10月12日发布官方博客，宣称其新的防御体系已将蒸馏者可提取的数据量降低约90%至99%，并表示为此“拒绝了来自蒸馏者的有意义收入与数万亿Token的付费流量”。OpenCode事件恰在此时爆发，也把“蒸馏攻防”从实验室报告拉回了普通开发者的现实账单。
六、开发者自救：别只改密码
收到OpenCode安全邮件的用户，眼下最重要的动作已经写在通知里：去对应模型服务商的官方控制台，撤销并更换可能泄露的API密钥。
需要特别强调的是：修改登录密码，不能代替撤销API密钥；只在OpenCode里删除配置，或把本机程序关掉，也无法让已经流出的凭据自动失效。唯一有效的方式，是到签发密钥的平台让旧密钥作废。
结合OpenCode官方通知与The Hacker News的建议，受影响开发者应依次完成以下动作：
（一）在OpenAI、Anthropic或谷歌的官方控制台中撤销疑似泄露的密钥，并签发新密钥；
（二）更新所有使用旧密钥的应用程序、脚本、CI流水线和服务端配置；
（三）审查自10月16日以来的用量与账单，重点关注非本人操作的调用记录，保留异常调用明细、消费时间及相关通知，向服务商申请调查与费用处理；
（四）在服务商侧设置消费上限（spending cap）与用量提醒，并为每个工具配置独立的密钥，使单把密钥泄露的损失可控、行为更易追踪。
对尚未收到邮件的用户，OpenCode表示其未受本次事件影响；但若曾在Console中保存过外部服务商密钥，仍建议主动排查近期账单，以防万一。
七、行业启示：API密钥是开发者的“第二身份证”
OpenCode本次泄露的只是约1.4%用户的密钥，“比例不大，但教训很大”。
对平台而言，密钥托管本质上是“单点信任”——把多家服务商的密钥集中在一处，等于把一次泄露放大成“一次入侵、多家受损”；而“准备下线”的旧系统同样是攻击面，退役流程执行不彻底，就会成为安全链条上的缺口。对开发者而言，最小权限、独立密钥、额度上限、定期轮换与密钥审计，应成为使用任何第三方AI工具的默认动作。
事件背后还有一个更宏观的信号。Dax Raad在10月18日透露，攻击者“过去48小时一直在不停尝试攻击我们的系统”，防御方“基本上需要7×24小时的AI Agent值守，因为攻击者就是这样做的”。他甚至自述在调查过程中被前沿模型的安全护栏误伤拦截，直到获得OpenAI Daybreak Blue授权访问后才得以继续——防守方用AI对抗AI的新常态，正在被这场攻防战推向台前。
在AI时代，API密钥就是开发者的第二张身份证。别把它随便交给任何一个“方便”的控制台，也别指望一次密码修改就能挽回损失。毕竟，黑客从来不会替你心疼账单。
