OpenCode 遭攻击：约 1.4% 用户 API 密钥可能外泄，处置要点全梳理

OpenCode遭攻击：部分用户OpenAI、Anthropic等API密钥外泄 — woshipm.com · 13 小时前 · 🔒 安全

AI 编程工具 OpenCode 披露了一起安全事件：处于停用流程中的旧系统遭到未授权访问，旧系统的访问控制失效，导致约 1.4% 的 OpenCode Console 用户工作区中保存的 OpenAI、Anthropic 等外部服务 API 密钥可能暴露。事件发生于当地时间 10 月 16 日，受影响用户随后通过邮件接到通知，相关团队正与 Anthropic、OpenAI 和谷歌协作处置，但攻击路径、受影响记录规模和密钥是否已被实际使用均未完整公开，披露中提到的「大规模蒸馏攻击」也不应被业务方当作自行推断攻击手法的依据。泄露的 API 密钥带来两类风险：一是直接费用损失，攻击者可以密钥持有者身份发起模型或云服务请求，账单先记到原账户，已有用户反馈出现数百美元级别的异常费用，也有项目因过度滥用被暂停；二是服务与数据风险，若密钥同时拥有文件、日志、工具调用或管理权限，影响会扩大到信息暴露与工作流中断。文章给出的处置原则是：只要某把密钥有机会被复制，就按已泄露处理，不要等确认滥用后再行动。前 30 分钟的关键动作分三步：先到各供应商控制台撤销或禁用可疑密钥，范围覆盖外部服务密钥、Agent 与 CI 等共享凭据、旧环境遗留密钥和高权限 Token，且不能只改本地 .env 或 SaaS 配置；再生成按环境、用途、权限拆分的新密钥，配独立限额、标签与最小权限，能启用项目级密钥、IP 白名单、速率限制的尽量启用；最后核对账单、请求日志与告警时间线，重点排查短时间内 Token 与并发突增、非业务时段或陌生地域调用、从未用过的接口等信号。文章还强调停用中的旧系统是风险最集中时期，应把下线拆成停止接入、凭据处置、数据清理、基础设施销毁等可验证阶段，每个阶段有明确验收信号。

核心信息

事件的基本盘：OpenCode 处于停用流程中的旧系统访问控制失效并遭未授权访问，影响范围约为 OpenCode Console 用户的 1.4%，潜在暴露的是这些用户工作区中保存的 OpenAI、Anthropic 等外部服务 API 密钥。事件发生于当地时间 10 月 16 日，受影响用户已收到邮件通知，团队正与三家模型供应商协作，但攻击路径、涉及记录规模和密钥实际使用情况尚未完整公开，已有用户报告数百美元级异常费用和项目被暂停的个案。
应急处置的优先级是先撤销再重建：进入每个供应商控制台撤销与受影响工作区关联的密钥，覆盖外部服务密钥、Agent 与 CI 及代码审查机器人的共享凭据、旧环境遗留密钥、以及可创建新密钥或修改账单的高权限 Token；不能只修改本地 .env 或删除 SaaS 工具里的配置，因为只要供应商侧密钥仍有效，泄露副本就仍可被调用。新密钥应按环境、应用和用途拆分，各自设置独立限额、可追踪标签和最小权限，并优先启用项目级密钥、IP 白名单、速率限制等约束。
密钥轮换只能阻断后续损失，已发生的调用需要靠账单与日志审计来还原：应按密钥、项目、模型、地区、时间段和调用量核对供应商日志，重点信号包括短时间内 Token 数与并发突增、非业务时段或陌生网络的调用、从未使用过的模型与接口类型、以及额度耗尽或风控提醒的触发时间点。把异常区间与事件通知时间、内部部署记录、密钥创建时间放在同一条时间线上，是后续申诉退款和安全复盘的证据基础。
最容易被忽略的是旧系统风险：团队常以为下线中的系统不再有安全价值，实际上停用期流量已迁走、监控开始松动，但数据库、备份、环境变量、CI 变量、调试日志、容器镜像层和遗留管理员账号都还在。可靠的下线流程应拆成可验证的阶段——停止接入、凭据处置、数据清理、基础设施销毁，每一步都有验收信号，例如旧 Token 无法再认证通过、抽样扫描不再发现有效密钥等。

💡 为什么值得读: 一次真实发生且直接影响普通开发者的密钥泄露事件，给出了从撤销密钥到核对账单的可执行清单，对任何把 API 密钥交给第三方工具的团队都是一堂必修课。

✍️ 小编看法: 这起事件的样本价值比它的规模更重要。1.4% 听起来不大，但它戳破了一个行业幻觉：大家默认 AI 编程工具的风险在「生成的代码有没有漏洞」，而这次出事的是工具本身作为凭据集散地的基础设施属性。想想现在一个开发者的密钥暴露面有多大——终端工具、浏览器扩展、SaaS 工作区、CI 变量，每个环节都在复制同一批高价值凭据，而大多数团队对密钥的管理水平还停留在共享一个 .env 文件的阶段。我认为有三个被普遍低估的点。第一，「按已泄露处理」的原则值得写进每个团队的应急预案：等你查清楚密钥有没有被用，攻击者早就跑完一轮账单了，止损和取证必须并行而不是串行。第二，费用类攻击的隐蔽性被低估了——异常账单几百美元，很多人第一反应是怀疑自己忘记关掉某个定时任务，而不是怀疑密钥泄露，等意识到时账单已经滚了几周，所以账单告警的阈值设置应该和密钥管理放在同一个安全清单里。第三，下线期的系统治理是个无底洞，文中那张分阶段退役表格值得抄进内部流程，尤其是「抽样扫描无有效密钥」这种可验证的验收信号，比「我们下线了」这种口头结论可靠得多。往大了看，随着 Agent 被授予越来越多的密钥和权限，行业迟早需要一套类似密钥托管与自动轮换的标配方案，也许这起事件会成为推动供应商把细粒度权限、每日上限做成默认配置的契机。读者接下来值得盯的是 OpenCode 后续的完整事故报告，特别是「蒸馏攻击」的真正含义。

🏷️ API key, data breach, security incident, OpenCode