OpenCode 遭駭客入侵:AI 程式設計代理用戶 API 金鑰被盜刷

开源 AI 编程智能体 OpenCode 近日披露了一起安全事件。据 TechCrunch 报道，黑客入侵了 OpenCode 在线平台的一部分，窃取了部分用户的 API 密钥，随后用这些密钥调用模型服务，在受害者的 AI 账户上产生了费用。OpenCode 被不少开发者当作 Claude Code 和 Cursor 的替代品，原因是它开源，可以自由接入不同厂商的模型。报道还提到一个耐人寻味的细节：团队在排查时求助于 AI 工具，请它们检查那段恶意代码，这些工具却反复拒绝。目前公开资料没有给出受影响用户的数量、具体的入侵路径和涉及的金额，这些信息有待团队后续说明。 要理解这件事的分量，先要看 OpenCode 一类工具的工作方式。它运行在开发者本地终端，需要调用外部大模型，所以用户要把各家模型服务的 API 密钥交给它保管，或者通过它的在线平台完成账号关联与配置同步。密钥一旦泄露，攻击者不需要攻破用户的电脑，只要拿到密钥，就可以直接向模型厂商发请求。费用算在密钥主人头上，而大模型调用按量计费，单价不低，盗刷者可以在很短的时间内刷出可观的账单。与传统的云账号盗用相比，这类密钥还有一个特点：它们往往没有细致的额度上限和地域限制，也很少绑定来源地址。因此，密钥只要被带出平台，就等于一张可以随便刷的信用卡。更深一层的问题在于，开源并不等于平台安全。代码可以公开审阅，但运营着账号、同步、分享等服务的在线部分，依然是一个普通的网络服务，要面对依赖投毒、凭据泄露、权限配置错误等常见风险。

报道中最值得玩味的，是团队求助的 AI 工具拒绝检查恶意代码。这背后是大模型安全对齐的一个老矛盾。为了防止模型被用来写恶意软件，厂商训练模型对攻击代码、混淆脚本、窃密逻辑保持警惕。但应急响应人员恰恰需要把样本交给模型，请它解释这段代码做了什么、数据发往哪里。模型很难仅凭一段文本判断提问者是攻击者还是防守者，于是倾向于拒绝。这对防守方是实实在在的拖累，因为事故响应拼的是时间，而攻击者不受这类限制，可以用自己的工具链自由分析和迭代。厂商要想解决这个问题，可行的思路包括面向已验证的安全团队开放更宽松的分析权限，或者在企业版中提供专门的取证与逆向模式。在这些机制成熟之前，团队仍然需要保留传统的静态分析、沙箱和人工逆向能力，不能把应急处置全部押在通用对话模型上。 从行业格局看，这起事件对几类参与者的影响各不相同。对 OpenCode 自身而言，信任是开源工具最重要的资产，尤其是在它主打替代商业产品的时候。用户选择它，部分原因是不想被单一厂商绑定，但前提是敢把密钥交给它。事件之后，团队需要尽快公布时间线、影响范围和修复措施，并说明密钥是如何存放的，是否做过加密与隔离。对 Claude Code、Cursor 等商业产品而言，这起事件在短期内可能成为它们强调托管安全和合规认证的论据，但它们同样依赖用户密钥或账号体系，并非天然免疫。对模型厂商来说，被盗刷的账单最终需要有人买单，是由用户承担，还是由厂商减免，会影响开发者对第三方工具的信心。对普通开发者而言，最直接的教训是不要把拥有最大额度的主密钥交给任何第三方工具，而应为每个工具单独创建密钥，设置月度额度和告警，并定期轮换。整个编程智能体赛道也在被迫面对同一个问题：当工具能读代码、执行命令、调用付费接口时，它保管的凭据就是攻击者最想要的东西。

接下来有几个信号值得关注。第一，OpenCode 是否发布完整的事后复盘，包括入侵入口、被窃数据的范围，以及是否要求所有用户轮换密钥。第二，模型厂商是否推出更细的密钥管理能力，例如限定来源、限定用途、短期令牌和异常用量自动冻结，这些都能显著压低密钥被盗后的损失。第三，编程智能体社区是否形成统一做法，把密钥放进系统钥匙串或外部密钥管理服务，而不是明文配置文件，并默认关闭不必要的云端同步。第四，AI 厂商如何处理安全人员的合法分析需求，如果拒绝检查恶意代码成为普遍现象，行业很可能会推动认证式的白名单机制。对用户来说，眼下最稳妥的做法是检查各家模型账户的用量记录，撤销旧密钥，重新创建带额度上限的新密钥，并留意任何异常扣费。这起事件不会是最后一起，随着智能体拿到的权限越来越大，围绕它们的安全攻防只会更频繁。