OpenCode密钥泄露事件：API安全教训

事件概述

近期，GitHub 星标超过 21 万的开源 AI 编程工具 OpenCode 遭遇了一起严重的云端安全事件。攻击者入侵了一套正在停用流程中的遗留系统，窃取了存储在其中的第三方模型 API 密钥，波及约 1.4% 的 OpenCode Console 用户。Anthropic、OpenAI、Google 三大模型厂商被卷入善后，部分密钥遭紧急撤销。

损失有多严重

与传统数据泄露不同，API 密钥的失窃意味着攻击者可以直接调用付费模型服务，产生的费用由原账户承担。受害者的损失包括：

• 一位开发者在数小时内被刷走 400 美元 Anthropic 账单
• 另一位用户单日 OpenAI 调用费用超过 700 美元
• 有用户因 Google Cloud 费用突增逾 1000 美元，触发风控导致整个生产账号停摆
• 最严重的受害者单日损失超过 1700 美元

所有受害者的共同点：都没有将密钥提交到公开仓库，也没有运行恶意脚本，唯一交集是将密钥托管到了 OpenCode Console 中。

根因：被遗忘的旧系统

OpenCode 在安全通知中承认，攻击者入侵的切入点并非零日漏洞，而是一套 正在执行停用流程的遗留系统。这套本应隔离下线的废弃服务，在缺乏运维监管的状态下继续暴露在公网上，且内部仍保留着对生产环境 Secrets 数据库的高权限读取通道。

这意味着：黑客不需要攻破现代防护层，只需找到一扇团队忘记上锁的旧侧门，就能端走数千名开发者的付费凭证。

"蒸馏攻击"说法为何被质疑

OpenCode 将事件定性为"大规模模型蒸馏攻击"，试图将其包装为前沿技术对抗。但这一说法迅速遭到技术社区反驳：

1. 调用特征不符：工业级蒸馏需要稳定、持续、结构化的大规模数据吞吐，而泄露的个人开发者密钥额度碎片化，随时可能因余额不足或用户手动掐断而失效
2. 转移视线嫌疑：无论攻击者后续用途是蒸馏、生成垃圾邮件还是转卖凭证，底层性质都是凭证失窃
3. 安全漏洞管理问题：将下游用途命名为攻击类型，有对冲自身安全责任的公关嫌疑

48 小时攻防：AI 对抗 AI 的尴尬

OpenCode 联合创始人 Dax Raad 透露，攻击者在过去 48 小时内从未停止攻击。团队在防御过程中遭遇了一个尴尬问题：用于分析攻击的前沿 AI 模型，在处理日志和代码时，因上下文中包含大量漏洞特征与攻击载荷，触发了内置安全护栏，拒绝继续处理后续请求。直到获得 OpenAI Daybreak Blue 的访问权限后情况才改善。

对开发者的实用建议

基于此次事件，以下是 API 密钥管理的核心要点：

• 避免将密钥集中托管到第三方平台，尤其是需要跨设备同步或团队共享的场景
• 设置调用额度和消费预警，在服务商端配置硬性上限
• 定期轮换密钥，对不再使用的服务立即撤销凭证
• 关注供应商的安全生命周期管理，选择有完善废弃系统下线流程的平台
• 优先使用本地密钥管理方案，如操作系统密钥链或 Vault 等工具

总结

此次事件的核心教训是：API 密钥就是钱。在 LLM 工作流中，密钥失窃等于将绑着信用卡的无底限扣费权限拱手送人。无论平台如何包装攻击性质，开发者都应从自身做起，建立最小权限、最小暴露面的密钥管理策略。