OpenCode遭蒸馏攻击：1.4%用户API密钥外泄，部分账单异常数百美元

2026年10月17日，AI编程平台OpenCode公开披露了一起安全事故：攻击者通过大规模蒸馏攻击入侵其遗留系统，劫持了约1.4%控制台用户存储的第三方AI提供商API密钥，涉及OpenAI、Anthropic和Google的访问凭证，部分用户在收到通知邮件之前就已发现账户出现数百美元的异常消费。OpenCode表示事件发生于10月16日夜间至17日凌晨，事发当日上午已向所有受影响用户发出告警邮件，公司正与Anthropic、OpenAI、Google三方协同处置。

一把钥匙，一扇从未被盯住的后门

理解这次事故，需要先厘清两个概念的叠加：蒸馏攻击与凭证劫持。

蒸馏攻击（distillation attack）本质是一种“知识窃取”——攻击者不直接复制某个AI模型的权重，而是通过大量向目标模型发送请求、收集输出，再用这些输出训练自己的模型，从而将前沿模型的能力“转移”到低成本副本上。这一手法在技术上并不新鲜，但工业规模化之后的危害已被Anthropic等公司公开预警过：单次请求无害，千万次请求就是系统性能力盗窃。

然而，要在不被追溯的情况下实现千万次查询，攻击者需要解决一个前提问题——谁来付账？这正是凭证劫持切入的地方。一旦掌握了真实用户的API密钥，攻击者就可以以受害者的身份向OpenAI或Anthropic发起请求，消耗的是受害者的额度，生成的输出归攻击者所用，账单由毫不知情的开发者承担。

OpenCode在公告中明确将这两件事关联在一起，但OpenCode并未解释被劫持的凭证是否已被实际用于蒸馏查询，其声明建立的是一种“报告中的关联”，而非经技术取证证实的完整攻击链。

遗留系统：正在关闭的房间里，门锁已经失效

攻击者的入口是一套OpenCode正准备下线的遗留系统。这套系统存储了Console用户在工作区内保存的第三方API密钥，OpenCode已在推进其退役流程，但在退役完成之前，系统仍处于运行状态。

这里暴露的不是一个代码漏洞，而是一种工程习惯的系统性缺陷：敏感凭证与待废弃基础设施的生命周期管理脱节。一套系统在进入“准下线”状态后，往往同时面临资源削减、安全补丁优先级降低和监控弱化三重压力，而它所承载的数据权限却没有随之收窄。攻击者显然熟悉这一规律——遗留系统是基础设施中防御最薄弱、响应最迟缓的环节。

OpenCode的母公司Anomaly Innovations（即开源编程代理OpenCode的开发商，前身为SST）在自身文档中已明确说明，OpenCode“不对agent进行沙箱隔离”，其权限提示“是一个用户体验功能”而非安全边界，并建议需要真正隔离的用户使用Docker或虚拟机环境。这段表述的含义是：平台从一开始就将凭证安全的最终责任转移给了用户。然而，一旦存储凭证的后台系统本身被攻破，用户在自己操作层面多么谨慎都无济于事——密钥从一扇用户永远不知道还在运行的门走了出去。

谁在承担损失，谁在调整策略

对受影响的开发者而言，损失是立竿见影的：先有异常账单，后有通知邮件。部分用户在OpenCode发出第一封告警邮件之前已经发现账户出现数百美元的异常消费。密钥轮换本身不复杂，但代价不止于此——每一个依赖被泄露密钥的应用程序都需要更新，线上服务存在中断窗口，排查异常请求记录需要时间与精力。

对OpenAI、Anthropic、Google三家AI提供商而言，这是一个棘手的信号。被盗用的密钥在提供商的日志里呈现为正常请求，区分合法用户与持有被盗凭证的攻击者需要异常行为检测能力：请求来源IP是否异常集中？单一密钥的调用频率是否远超历史基线？时段分布是否与开发者正常工作节律背离。OpenCode表示三家提供商正在协同处置，但具体处置机制尚未公开。被盗凭证的计费如何处理——是由提供商核销，还是由开发者自行承担——这将成为未来此类事故处理预期的参照。

对整个第三方AI工具生态而言，这次事故戳破了一个长期存在的默认假设：把API密钥存在工具平台里是安全的。大量面向开发者的AI工具——IDE插件、智能体框架、代码审查工具——都提供“一次配置、后台托管”的密钥管理功能，用户体验上无缝，安全模型上却建立在对工具供应商的完全信任之上。OpenCode事件让这一信任模型的脆弱性变得可见：用户无法审计供应商的后台基础设施，也无法感知对方遗留系统的实际安全状况。

安全社区的反应集中在一个词上：供应链盲区。API密钥的安全性不仅取决于密钥本身如何生成和传输，还取决于每一个持有或经手密钥的第三方系统的安全状态。与软件供应链中对依赖包的关注相比，开发者对AI工具链中凭证托管环节的审查意识明显滞后。

历史坐标：这不是API密钥第一次成为攻击目标

此前，安全研究人员已多次记录API密钥通过其他途径外泄的案例——例如开发者将包含密钥的配置文件提交至公开代码仓库，或在公开Web数据中留下未脱敏的访问凭证。那些案例确立了一个基本事实：只要密钥以明文形式存在于任何联网系统中，它就是一个攻击面。OpenCode事件的新意在于攻击向量的位移：这次不是开发者自身的操作失误，而是开发者信任的工具平台的后台基础设施成为突破口。责任归属从“用户疏忽”移向了“供应商安全失职”，这对整个行业的凭证管理责任边界有实质性的重新定义意义。

同时，这是蒸馏攻击与凭证劫持在同一事件中被关联的早期公开记录之一。如果这种组合被证实——即攻击者系统性地通过入侵AI工具平台获取批量凭证、以此驱动大规模蒸馏——那么它代表的是一种成本极低的前沿模型能力窃取路径：不需要自建算力，不需要暴力破解模型，只需要找到一个存储了足够多开发者密钥的第三方平台，一次入侵即可批量获取通往多家顶级模型的访问权限。

接下来最可能发生什么

短期内，OpenCode遗留系统被彻底下线几乎是确定性动作，三家AI提供商大概率会针对异常批量调用模式推出更严格的实时告警机制。开发者社区的密钥轮换建议会从“最佳实践”变为更具紧迫性的操作规范，主流AI工具平台的密钥托管逻辑将承受更大的审计压力。

中期最值得观察的信号有两个：其一，OpenCode承诺的详细技术报告能否还原完整攻击链，特别是被盗凭证是否确实被用于蒸馏查询——这将决定这次事件在安全史上的定性；其二，Anthropic、OpenAI、Google对异常消费的赔付或核销政策如何落地，这将直接影响开发者对AI工具供应商的风险定价方式。

更长远看，AI工具链的凭证安全很可能走向两个方向之一：要么是平台层的零知识凭证架构——即工具平台永远不持有明文密钥，只代理签名请求；要么是提供商层的短时令牌机制——即API密钥本身具有更细粒度的有效期和权限范围，单次泄露的爆炸半径被物理约束。无论哪个方向，OpenCode事件提供的证据足够清晰：当前以长期有效密钥加后台托管为主流的凭证管理模式，在面对专门针对工具平台的攻击时，没有足够的纵深防御。