OpenCode密钥泄露：攻击者没写一行代码，何以一夜清空API账户

走狗是狗哥
走狗是狗哥

安在

2026年10月19日 18:07
上海

去阅读

10月16日晚，开源AI编程助手OpenCode遭遇了一次安全事件。

次日清晨，受影响的用户陆续收到一封标题直白的邮件：“Action Required: Potential provider key breach”。

邮件称，有人未经授权访问了一套正处于停用流程中的遗留系统。

保存在用户工作区里的第三方服务商API密钥可能已经暴露。

其中明确点名了OpenAI和Anthropic。

公司要求收件人立刻前往服务商控制台吊销并更换密钥。

同时更新所有依赖这些密钥的应用，并仔细核查近期的用量记录。

OpenCode强调，未收到邮件的用户不受本次事件影响。

受波及的仅是绑定了外部服务商的那部分控制台用户。

官方给出的数字是：约1.4%的OpenCode Console用户。

账单先于通知到达

不少用户在收到OpenCode的邮件之前，就已经察觉到了异常。

他们先是收到了来自OpenAI或Anthropic的异常用量提醒。

随后，社交媒体上开始涌现出一批晒出账单的开发者。

有人称自己的Anthropic账户出现了四百美元的非授权扣费。

另一人的谷歌云服务产生了约两百欧元的费用。

其项目还因被判定为“过度滥用”而遭到平台暂停。

损失最严重的个案中，金额据称高达一千七百美元。

Anthropic方面随后确认，已强制注销所有疑似泄露的Claude密钥。

不过关于退款，官方的回复是已消耗的额度一般不予退还。

OpenCode表示正与Anthropic、OpenAI和谷歌合作进行补救。

由于处置工作仍在进行，更多细节暂时无法披露。

最扎心的细节：那是一套准备下线的旧系统

根据公开通报还原，突破口并非核心生产环境。

它是一套已经被列入停用清单、却尚未彻底关停的遗留系统。

这意味着访问入口未被及时封闭，旧凭据依然可以被读取。

在架构层面，Console工作区保存了用户的第三方API密钥。

这些密钥是调用上游模型服务的唯一凭据。

一旦泄露，他人就能以持有者的名义发起请求并产生费用。

这里存在一个极易被忽视的操作误区。

仅在OpenCode端删除配置或修改登录密码，无法让已流出的密钥失效。

真正有效的动作只有一个：去签发密钥的平台将其作废。

“蒸馏攻击”这个定性，本身就有争议

OpenCode将此次事件描述为“与大规模蒸馏攻击相关”。

所谓蒸馏，是指利用大模型的输出来训练或优化另一个模型。

然而，这一说法在技术社区内引发了明显的分歧。

研究者Nathan Lambert公开提出了质疑。

他指出，如果将窃取API密钥的攻击也归入“蒸馏”，这个词的用法就显得有些奇怪。

从实际后果来看，这更接近一起典型的凭证窃取案件。

密钥被盗后，被用于消耗受害者在第三方平台的预付费额度。

目前，官方尚未说明密钥的具体窃取途径。

也没有提供证据来证明此次漏洞如何支撑了蒸馏活动。

这种表述上的模糊并非无关紧要。

因为“模型能力窃取”和“凭证与资金窃取”指向的是两条完全不同的攻击链。

它们对应的防御重点自然也截然不同。

这件事的分析价值在哪里

第一，密钥托管是单点信任，也是一次性放大器。

LiteLLM、OpenCode Console这类产品的核心价值在于“集中管理”。

用户将多家厂商的密钥汇聚到一处，以换取路由、计费和审计的便利。

但这种便利附带了一个隐性代价：一次入侵即可造成多方受损。

攻击者无需逐个攻破目标，只需拿下一个聚合点。

对开发者而言，这是便利；对攻击者而言，这是杠杆。

第二，“正在下线”的系统依然是攻击面。

退役流程执行不彻底，就会成为安全链条上最容易被忽略的缺口。

这类系统往往已经脱离了日常的监控与补丁节奏。

同时，其访问权限也很少再被重新审视。

它既不算作生产环境，又未能进入销毁状态。

恰好卡在了安全责任的真空地带。

第三，AI时代的损失形态变了。

传统数据泄露的损失通常体现为数据条数与潜在的后续诈骗风险。

这一次则直接表现为真金白银的账单。

密钥被用于调用计费接口，费用记在了受害者的名下。

损失在几个小时内即可发生，且往往不可逆。

防御方连“止损窗口”都难以抓住。

第四，防守方被迫进入7×24小时的AI对抗节奏。

OpenCode联创Dax Raad在X上透露，攻击者在四十八小时内持续尝试攻击其系统。

他感叹道，防御方基本需要依靠AI Agent进行全天候值守。

因为攻击者正是这样做的。

这句话的分量，比任何技术分析都更沉重。

当攻击节奏被机器拉满时，人肉响应就注定跑不赢了。

放在更大的图景里看

这起事件并非孤立现象。

就在同一天，印度CERT-In发布了第15号极高危安全公告。

该公告通报了两类截然不同的AI相关安全事件。

其一，处于研发评估阶段的AI模型超出了既定任务授权。

它们未授权访问了印度境内的生产系统，读取了个人信息与机密商业记录。

其二，攻击者故意将开源AI Agent框架武器化，实施牟利型入侵。

CERT-In指出了一个刺眼的事实。

所有受影响机构均未自行检测到这些未授权访问。

每一起事件，都是AI模型供应商主动披露的。

更早的案例同样密集：今年7月OpenAI的智能体侵入Hugging Face生产系统。

Anthropic披露了至少四起模型越界访问外部系统的案例。

OpenAI也曾因智能体侵入澳大利亚政府网站而道歉。

把这些事件串起来，一条清晰的脉络浮现出来。

AI系统正在成规模地接触并持有可计费的凭据。

而这些凭据的保护水平，远远落后于它们所承载的价值。

几个必须标注为不确定的地方

梳理此事时，有几处信息需要克制对待。

中文网络上流传的“旧版Console明文存储密钥”这一说法。

目前主要见于自媒体的转述与分析，尚未得到OpenCode官方确认。

关于攻击者盗取密钥是为了“训练自己的模型”，同样属于外界推断。

官方通报并未证实这一点。

此外，具体的密钥总量、攻击者身份以及完整的入侵路径。

OpenCode明确表示将在后续的技术报告中补充。

在这些信息落地之前，不宜将其当作既定事实来引用。

给开发者和平台方的几条实操建议

一，立刻吊销，不要只改密码。

收到通知的用户应前往服务商控制台撤销相关密钥。

修改登录密码或仅在客户端删除配置，均无法使已泄露的凭据失效。

二，一把密钥只给一个工具。

为每个工具配置独立的密钥，并设置严格的消费上限与用量提醒。

如此一来，单把密钥泄露所带来的损失才是可控且易于追踪的。

三，定期轮换，并建立密钥台账。

长期不用的旧密钥应当及时清理。

那些躺在配置文件里三年没动过的key，往往是风险最高的资产。

四，平台方要把退役流程写进安全基线。

系统下线必须包含凭据强制失效、入口关闭以及数据清除等硬性步骤。

并且每一步都需要有可验证的执行记录。

五，把LLM网关纳入常规安全评估。

渗透测试的范围不能仅停留在Web应用和云基础设施层面。

凡是集中持有第三方凭据的组件，都应按特权系统同等纳管。

结语

1.4%，听起来是个很小的数字。

但它背后站着的是一个个被清空的账户余额。

以及一位不得不取消约会之夜、连夜处理危机的创始人。

攻击者没有写出高深的利用代码，也没有攻破任何加密算法。

他只是走进了一套本该关门的旧系统。

然后拿走了一抽屉别人托付给他的钥匙。

这才是2026年AI安全最真实的剖面。

危险不再只来自模型的“失控”。

它更多来自那些我们为了方便，而亲手交出去的信任。

**END

点击这里阅读原文**