OpenCode遭黑客围攻48小时，大量API账户被刷爆引发信任危机

开源AI编程工具OpenCode近日经历了一场持续约48小时的安全危机。大量用户发现，自己绑定的API账户在毫不知情的情况下被疯狂调用，额度被刷爆、账单暴涨，有人甚至在深夜收到云服务商的欠费警报。随着事件发酵，官方“蒸馏攻击”的解释在开发者社区引发强烈质疑，一场关于开源项目安全责任归属的大讨论随之展开。

48小时围攻：账户被刷爆的真实经过

据受害者反馈，异常调用几乎是不间断进行的。黑客利用漏洞或泄露的凭证，以极高频率向大模型API发起请求，将用户账户的额度迅速消耗殆尽。从第一起异常报告出现到攻击基本被遏制，整个过程持续了大约48小时，期间受影响账户数量不断增加，涉及多家模型服务商的计费体系。

对于按量付费的开发者而言，这不仅是额度问题，更是真金白银的损失。部分用户表示，自己在几小时内就消耗了原本计划用数周的token额度，而OpenCode客户端在后台的调用行为并未给予充分提示，导致很多人发现时账单已经失控。

“蒸馏攻击”说法遭社区质疑

面对汹涌的舆情，OpenCode官方在回应中使用了“蒸馏攻击”这一说法，暗示攻击者的目的可能是利用高频调用获取模型输出，用于蒸馏训练自己的模型。然而这一解释并未平息怒火，反而引来更多质疑。

社区开发者普遍认为，“蒸馏攻击”更像是在转移焦点。真正的问题是：为什么用户的API凭证会暴露在风险之中？为什么异常调用的检测和熔断机制没有及时生效？为什么官方未能第一时间发布明确的风险通告？有资深工程师指出，无论攻击动机是什么，凭证管理和速率限制的缺失才是损失扩大的根本原因。

把账单失控归咎于攻击者，回避自身在密钥管理和风控上的失职，这不是社区想要看到的答案。

开源工具的信任困境

OpenCode是近年来颇受开发者欢迎的开源AI编程工具，与商业化的编码助手不同，它允许用户自带API密钥，自由接入不同的模型服务。这种灵活性是其吸引力所在，但也将安全责任更多地压在了工具方身上——工具如何存储、传输、使用这些凭证，直接决定了用户资产的安全边界。

此次事件暴露的正是这条边界上的裂缝。当客户端、配置文件与云端服务之间的凭证流转缺乏透明审计时，任何一环的疏漏都可能被攻击者放大为全量用户的灾难。事实上，AI编程工具爆出凭证泄露问题并非首次，此前已有多款流行工具被安全研究者发现以明文或弱加密方式保存密钥，OpenCode事件只是把这一行业性隐患推到了聚光灯下。

官方补救与用户自保指南

在舆论压力下，OpenCode团队多次公开发声并道歉，承诺彻查漏洞来源、加固凭证管理流程，并对受影响用户给出处理方案。官方同时建议用户立即轮换API密钥、在服务商控制台设置消费上限与异常告警、检查历史账单中的可疑调用记录。

安全专家也给出了一些建议：为AI工具使用独立的子账户和专用密钥，避免与生产环境共用凭证；开启服务商提供的用量硬限制；定期审计密钥权限，做到最小化授权。这些建议虽然基础，却是普通开发者目前最有效的防火墙。

事件余波与行业影响

这次48小时危机对OpenCode的社区口碑造成了明显冲击。部分用户宣布暂停使用并迁移到替代工具，也有用户选择观望，希望看到官方拿出透明的调查报告和长期的安全改进计划。

更大的影响在于行业层面：随着AI编程工具全面普及，API凭证事实上已成为开发者的“数字钱包”，其安全等级却普遍停留在工具附属性的地位。此次事件可能推动工具厂商建立更严格的密钥托管与审计标准，也促使云服务商完善异常调用的实时熔断机制。

对OpenCode而言，能否把危机转化为改进契机，取决于后续动作的诚意与透明度。对整个行业而言，这场围攻是一记警钟：在AI应用的狂欢之下，安全基建的欠账已经开始利息滚动，任何一款把用户资产押在自身信誉上的工具，都没有资格把安全当作事后补救的选项。