OpenCode 安全漏洞暴露 AI 提供商密钥，但本地安装面临不同风险

OpenCode 披露了一起影响 1.4% Console 用户的安全漏洞：攻击者访问了一个遗留系统，并可能获取了关联的 AI 提供商密钥。这些凭据可用于向 OpenAI、Anthropic、Google 及其他模型提供商的服务发起计费请求。

OpenCode 安全漏洞并不意味着每个本地 OpenCode 安装都已遭入侵。已报告的暴露事件集中于 OpenCode Console——这是一项可选的托管服务，可为共享工作区存储提供商凭据。根据 OpenCode 的文档及维护者说法，其本地应用采用不同的凭据路径。

这一差异缩小了已确认的影响范围，但并未消除运营层面的难题。安全团队仍需查找 OpenCode 安装实例、识别使用过 Console 的人员、追踪关联凭据，并审查提供商活动。这起事件使一款 AI 编程工具演变为一项跨开发者设备、托管工作区和外部计费账户的凭据管理调查。

OpenCode 安全漏洞实际暴露了什么

核心事件是未经授权访问了 OpenCode Console 存储的提供商密钥，而非已确认每个 OpenCode 客户端均遭入侵。

OpenCode 于 2026 年 10 月 17 日披露了该事件。该公司称，其遭遇了一起与所谓大规模蒸馏攻击有关的安全漏洞。它表示，1.4% 的 OpenCode Console 用户受到影响，并称已通过电子邮件通知这些用户。

该公司的客户通知将此次暴露归因于对一个正在退役的遗留系统的未经授权访问。通知警告收件人，保存在其工作区中的第三方提供商密钥可能已暴露。通知要求受影响客户撤销这些密钥、进行替换，并审查近期使用情况。

OpenCode Console 是与这款开源编程代理关联的托管服务。其工作区功能允许管理员连接提供商账户，并向其他成员提供经批准的模型。OpenCode 的 Console 提供商文档称，该服务会存储提供商凭据，并在通过其网关转发请求时插入该凭据。

这种架构可防止普通工作区成员看到底层密钥，但也将存储的凭据置于一项共享服务边界之后。若该边界失效，一起事件便可能影响多个上游提供商的账户。

受影响用户的报告描述了异常的模型使用和支出警报。一些用户表示，未经授权的活动似乎出现在多个提供商账户中。据报道，OpenAI、Anthropic 和 Google 正采取措施，封锁已暴露凭据、恢复访问权限或处理未经授权的费用。

现有报道没有提供经验证的已暴露密钥数量。OpenCode 尚未公布 Console 用户总数，因此该公司所称的 1.4% 无法换算为可靠的受害者人数。

该公司也未公开详述攻击者如何进入这一遗留系统。它没有解释凭据在静态存储时如何受到保护、攻击者绕过了哪些控制措施，或入侵者是否访问了其他工作区数据。

这些缺口很重要，因为“蒸馏攻击”一词描述的是被盗模型访问权限的推定用途，而不一定是入侵技术。模型蒸馏通常指收集一个模型的输出，以训练或改进另一个模型。被盗的 API 密钥可以资助这类活动，但并不能说明密钥是如何获得的。

因此，初步披露仅支持一个更为有限的结论：攻击者进入了一个遗留的 Console 系统，提供商密钥可能已暴露，且随后出现了未经授权的模型使用。具体入侵路径，以及将该访问行为与模型蒸馏联系起来的证据，仍未披露。

独立报道还记录了响应期间一个不同寻常的问题。OpenCode 联合创始人 Dax Raad 表示，一些前沿模型最初曾协助分析该事件，但当恶意材料触发其安全控制后，后来拒绝了相关请求。

此后，OpenCode 获得了 OpenAI Daybreak Blue 项目的访问权限。据报道，该项目可让经过审查的防御人员使用较不可能拒绝合法安全调查的模型。这一事件为漏洞增添了第二个问题：防御人员日益依赖安全策略可能中断事件分析的 AI 系统。

Console 边界改变了哪些人面临风险

组织必须将已确认的 Console 暴露与本地 OpenCode 代理更广泛的安全态势区分开来。

OpenCode 可在本地运行，并直接连接模型提供商。其文档称，通过旧版本地 /connect 流程添加的凭据存储在 ~/.local/share/opencode/auth.json。较新的 OpenCode V2 安装会将保存的凭据存储在本地 SQLite 数据库中，通常位于同一 OpenCode 数据目录下。

这些本地凭据所经路径不同于保存在 Console 工作区中的提供商密钥。OpenCode 维护者 Dax Raad 表示，此次漏洞涉及的是 OpenCode Console，而非 OpenCode 本身。他还表示，直接在应用中配置的密钥不会传到该公司。

这一说法很重要，但不应就此结束企业调查。资产清单很少能区分命令行工具与其可选的云账户。开发者可能使用本地代理、登录 Console、加入多个工作区，并在一段时间内连接不同的提供商账户。

因此，一台机器可能安装了 OpenCode，却并未受到所报告漏洞的影响。反过来，某位开发者也可能曾通过浏览器或另一台已不再保留该可执行文件的机器使用 Console。仅搜索终端设备无法形成完整的受害者名单。

正确的调查单位是四类记录之间的关系：开发者身份、本地 OpenCode 安装、Console 工作区和提供商凭据。安全团队需要对这四项进行核对。

这会给工具采用分散的工程组织带来即时压力。员工可能连接了个人提供商密钥、团队凭据或项目专用服务账户。每一种选择都会产生不同的影响半径。

个人密钥可能带来直接费用，并暴露员工的提供商账户。共享团队密钥可能影响多个应用。若属于更大云项目、且权限范围广泛的云凭据遭暴露，则可能带来模型使用之外的后果。

同样的区分也适用于源代码和对话数据。当前公开报道支持已存储提供商凭据可能暴露这一结论，但并未证明每个代码库、提示词、本地文件或 OpenCode 对话都被访问。

不过，调查人员不应将不确定性误作安全保证。在 OpenCode 发布详细的事后报告之前，受影响组织应询问：该遗留系统是否包含请求记录、账户元数据、工作区成员信息，或其他对攻击者有用的信息。

OpenCode 自身的 安全文档还指出，其本地代理未在沙箱中运行。权限系统有助于用户查看并批准操作，但并不提供安全隔离。OpenCode 建议在需要真正隔离时使用容器或虚拟机。

这一威胁模型与 Console 事件是分开的。不过，它也解释了为何查找安装实例很重要。即使没有证据表明其终端遭入侵，一个能够执行 shell 命令、修改文件并访问网络的代理，也值得接受审慎治理。

组织应将 Console 暴露视为紧急凭据事件，同时应将发现的本地代理视为更广泛的终端与开发安全问题。将这些结论合并为一项说法，要么会夸大漏洞，要么会低估该代理的常规权限。

如何在开发者设备上查找 OpenCode

一项有效的发现流程应结合可执行文件搜索、进程证据、本地数据路径、软件包记录和身份信息。

首先询问开发者是否使用过 OpenCode Console，或是否收到过事件通知邮件。这一询问比盲目扫描终端设备更快，也直接针对已确认的暴露群体。在做出任何变更前，应保留该邮件，并记录每个被提及的工作区和凭据。

身份团队应在单点登录日志、浏览器访问记录、DNS 遥测数据、安全 Web 网关事件和费用记录中搜索 OpenCode 域名。这些来源可识别终端软件包清单遗漏的前用户和仅通过浏览器访问的用户。

在 macOS 和 Linux 上，防御人员可以检查当前 shell 中是否存在该可执行文件：

前两条命令会定位 shell 已知的可执行文件路径。版本命令可以确认已发现的二进制文件能够运行，但团队在取证收集期间应避免执行不受信任的文件。应改为对可疑二进制文件进行哈希计算或隔离。

活动进程提供了另一项信号：

进程搜索仅显示收集时正在运行的软件。它们无法证明 OpenCode 从未安装过，而且可执行文件可能已被重命名。

软件包管理器可以提供历史或当前安装证据。在开发者系统上，应审查 Homebrew formulas 和 casks、全局安装的 JavaScript 软件包、shell 安装记录、受管理的应用目录，以及终端管理工具提供的软件清单。

团队应明确搜索 opencode 可执行文件，而不应假定仅存在一种软件包名称。打包和安装方式可能发生变化，而名称相近的项目可能造成误报。

OpenCode 数据目录比单独的可执行文件提供更强的证据。对于旧版本地安装，应检查文档中列出的路径：

不要将凭据文件内容输出到终端日志、工单或聊天系统中。简单列出目录即可在不暴露密钥的情况下确认其存在。

OpenCode V2 可通过其调试命令报告数据库位置。其提供商文档称，常见的本地数据库路径为 ~/.local/share/opencode/opencode.db，但环境设置和发布渠道可能会改变该路径。

在 Windows 上，防御人员可以使用内置命令查找可执行文件和活动进程：

用户配置文件、软件包管理器清单、Windows 应用程序控制日志和终端检测遥测数据能够揭示更多安装实例。应搜索每个用户配置文件，而非只检查运行扫描的账户。

容器化开发环境需要单独覆盖。应搜索经批准的开发镜像、Dev Container 配置、Docker 历史记录、远程工作区和短暂的 CI 环境。对员工笔记本电脑的扫描将遗漏仅安装在容器或云开发主机内的代理。

仓库搜索可以查找 OpenCode 配置文件、策略参考或安装脚本。它们不应不加区分地收集源代码或密钥。将搜索范围限制在已知配置名称和安装命令内，然后与仓库所有者核实每项结果。

Shell 历史记录也可能包含安装或调用证据。这些记录很敏感，因为其中可能含有令牌和私密命令。仅应在组织的事件响应和隐私程序下收集它们。

检测不应只回答某个二进制文件是否存在。对于每项已确认的安装，应记录用户、设备、版本、安装方式、最后一次观察到的执行时间、本地数据位置、Console 登录状态、工作区成员身份和已连接的提供商。

最重要的问题是，用户是否在受影响的 Console 工作区中保存了提供商凭据。仅含本地凭据的本地安装不属于目前所述的泄露范围。即使当前设备上已没有 OpenCode 可执行文件，Console 用户也可能需要立即轮换凭据。

OpenCode 的常规本地提供商流程支持多种服务。其本地提供商指南说明了直接凭据和基于环境变量的云端身份验证。这种多样性意味着发现脚本应寻找关联关系，而不是将所有可能的密钥复制到中央报告中。

环境变量需要特别处理。它们的名称可以表明某个进程可使用哪些提供商，但其值属于密钥。检测系统应记录变量曾存在，但不应捕获其完整内容。

终端团队还应查找未启用身份验证的 OpenCode 服务器模式。根据该项目的威胁模型，服务器模式为可选功能，并应使用 OPENCODE_SERVER_PASSWORD 进行 HTTP Basic Authentication。暴露在本地或远程的服务器构成需要处置的独立风险，尽管它不是此次 Console 泄露的已报告原因。

对于缺乏可靠软件资产清单的组织而言，此次事件正是建立清单的理由。AI 编程代理是具备网络访问能力并关联凭据的可执行开发工具。它们应纳入与 IDE 扩展、包管理器、构建工具和远程管理软件相同的资产控制体系。

可搜索的技术文档系统可以帮助团队保留安装记录、响应决策和责任归属，避免将它们分散在私密消息中。同样的原则也适用于工程知识库：只有当响应人员能够检索并关联证据时，证据才有价值。

响应应从提供商侧处置开始

在凭据签发方的提供商处撤销已暴露凭据，比从存储它的应用程序中删除更可靠。

首先，保留通知并识别 OpenCode 所列出的每一项凭据。记录其提供商、工作区、所有者、项目、权限、创建日期和已知依赖服务。切勿将完整密钥粘贴到事件记录中。

其次，在每个受影响提供商自身的控制台中撤销密钥。从 OpenCode 中移除凭据并不会使攻击者已持有的副本失效。提供商侧撤销会关闭授权路径。

第三，只有在确认旧凭据已被禁用后，才创建替代凭据。为不同项目、环境和工具使用不同密钥。避免以另一个被广泛共享的密钥替换一个共享密钥。

第四，更新依赖已撤销密钥的合法应用程序。应与服务所有者协调此步骤，因为快速轮换可能中断开发环境、定时任务、测试系统和生产工作负载。

第五，从最早可能暴露的时间开始审查提供商使用情况。报告显示，潜在暴露最早可追溯至 2026 年 10 月 17 日 00:30 UTC。谨慎的调查应纳入更早的缓冲时间，并持续至确认撤销完成。

查找陌生模型、令牌用量突然激增、异常请求时间、新来源网络、意外区域，以及触及预算上限的项目。将这些事件与开发活动、CI 任务和已知自动化工作负载进行对比。

第六，检查账单和安全警报。未经授权的模型请求可能首先表现为支出异常，而非登录警报，因为 API 密钥不需要交互式账户会话。

第七，通过官方支持或安全渠道联系提供商。要求其保留相关请求元数据、识别滥用行为、恢复被错误暂停的项目，并说明报销流程。

第八，从每个 Console 工作区中移除过时凭据和提供商连接。在 OpenCode 提供足够技术信息、供组织风险负责人批准该决定之前，不要重新连接替代密钥。

第九，降低未来任何被盗密钥的价值。在支持的情况下，使用提供商侧预算、速率限制、项目隔离、最小权限、过期机制、网络限制或服务身份。

预算控制并非安全边界。它们可以限制财务损失并加快检测，但攻击者仍可能在预算耗尽前消耗敏感模型容量或触发账户处置。

第十，检查本地机器，但不要假定它们导致了此次暴露。审查 OpenCode 数据路径、版本、活动进程、配置和服务器模式设置。卸载软件前先保留可疑工件。

如果本地凭据从未存储在 Console 中，应根据证据和组织政策进行轮换，而不是基于“所有 OpenCode 密钥均已泄露”这一未经证实的说法。对于孤立的开发密钥，轮换成本较低；但草率的大规模轮换可能造成服务中断，并模糊事件时间线。

第十一，识别本地代理可访问的下游密钥。经用户批准后，OpenCode 可以访问 shell 工具和项目文件。遭泄露的提供商密钥不会自动暴露仓库令牌、云凭据或签名密钥，但如果终端证据显示存在恶意命令或未经授权的访问，则应审查这些资产。

第十二，监控替代凭据。新密钥应配置比旧密钥更严格的警报。调查人员需要了解，可疑请求是否在轮换后停止，还是通过另一条访问路径再次出现。

第十三，记录关于是否继续使用 Console 的决定。记录应注明负责的风险所有者、已审查的证据、尚存的未知因素，以及再次允许在其中存储凭据前所需的控制措施。

最后，在提供商活动、账单记录、身份日志和终端发现相互一致之前，保持调查开放。干净的笔记本电脑扫描无法证明 Console 凭据安全。已撤销的密钥无法消除暴露服务器的风险。每一层回答的是不同问题。

“蒸馏”标签仍是事件叙述中最薄弱的一环

OpenCode 已将此次事件与大规模模型蒸馏联系起来，但公开证据尚不足以证实这一动机或机制。

蒸馏活动可以使用一个模型的输出训练或改进另一个模型。大规模开展这一过程需要大量请求，并可能产生高额提供商费用。被盗 API 密钥可让攻击者获得付费推理访问权限，而无需使用自己的计费账户。

这种解释具有合理性，但合理性并不等同于归因。OpenCode 尚未发布请求样本、流量模式、目标模型、攻击者基础设施或其他指标，以证明未经授权的使用流入了训练管道。

这一表述还可能混淆两项不同的行为。未经授权访问遗留系统是此次泄露。使用被盗凭据进行高频查询则是滥用。蒸馏只是这种滥用的一种可能目的。

安全团队在采取行动前不需要确定攻击者的最终目标。无论凭据盗窃被用于蒸馏、垃圾信息、基准测试、转售还是其他未经授权的推理，响应措施都相同。

不过，这一标签对问责很重要。将事件称为蒸馏攻击，可能会将注意力转向模型竞争和地缘政治访问限制。将其称为凭据泄露，则会将注意力引向遗留系统的存储、分段、监控和退役。

两个议题都值得调查，但目前只有其中一个已被明确证实。有记录的事件涉及未经授权访问遗留系统及暴露的持有者凭据。所称的蒸馏关联仍是等待支持证据的公司定性。

此次事件还暴露了 AI 辅助防御中的矛盾。据报道，OpenCode 团队在攻击者持续探测其系统期间一直使用 AI 代理。一些模型后来拒绝分析恶意内容，因为这些请求看起来类似于被禁止的进攻性活动。

在此前涉及 Hugging Face 的事件中，也出现过类似问题。防御者认为，模型护栏无法可靠地区分正在分析同一漏洞材料的事件响应人员和攻击者。应对方式往往转为使用本地受控或经过特别批准的模型。

这种权衡并不意味着限制较少的模型天然更安全。拒绝较少的模型可能帮助获得授权的响应人员，但也可能协助攻击者。访问控制、审计追踪、隔离的分析环境和经验证的响应人员计划仍然必不可少。

因此，这次泄露让两项承诺面对运营现实。托管式 AI 网关承诺更简便地访问多个提供商，但也可能集中存放高价值凭据。带护栏的模型承诺更安全的行为，但这些控制可能会中断合法的事件响应。

两者都没有单一的产品级解决方案。组织需要假定网关可能失效的架构，以及不依赖某一个模型同意分析恶意代码的响应程序。

OpenCode 的公开威胁模型提供了有用背景。该代理可以执行命令和访问文件，而其权限提示并非沙箱。这种设计赋予开发者灵活性，但也使身份、终端隔离和凭据范围成为核心安全控制措施。

不应利用此次泄露宣称开源代理天生不安全，或专有工具天生安全。核心问题在于凭据存放位置、可使用它们的人、活动监控方式，以及可信服务遭泄露时会发生什么。

技术复盘报告将支持得出更有力的结论。它应说明初始访问向量、受影响系统、凭据保护、暴露窗口、检测方式、攻击者行为、处置时间线，以及“蒸馏”评估背后的证据。

在此之前，买方应以清晰的证据层级评估此次事件。OpenCode 的 1.4% 范围数字属于公司声明。用户报告支持确有真实的未经授权使用。Console 架构解释了为何存储的提供商凭据至关重要。攻击者身份和确切目标仍未得到解决。

三项信号将显示响应是否奏效

下一项检验在于，OpenCode 和受影响的提供商是否会以可验证的证据和持久的控制措施，取代紧急披露。

第一个信号是一份详细的 OpenCode 事件后报告。它应说明遗留系统如何仍可访问、凭据如何存储、哪些控制措施失效，以及公司为何认为该活动涉及蒸馏。

一份完整报告将增强人们对该暴露范围已被理解并受到控制的信心。若继续援引 1.4% 这一数字，却不提供分母、根本原因或受影响凭证数量，则会削弱这种信心。

第二个信号是服务提供商一侧的处置。OpenAI、Anthropic、Google 及其他受影响服务应能够识别未经授权的请求，完成适当的赔付，为被错误暂停的项目恢复服务，并帮助客户确认已撤销的密钥不再有效。

这一过程将检验模型提供商能否围绕跨平台凭证事件展开协作。它也会揭示，当前的欺诈控制措施是否能在大量可计费请求累积之前发现被盗的 AI 密钥。

第三个信号是 OpenCode Console 内部的架构变更。用户应关注凭证有效期是否缩短、服务提供商连接是否实现更强隔离、审计日志是否改进、旧版系统是否更严格地退役，以及当密钥出现异常行为时是否提供更清晰的告警。

这些控制措施将减少对单一存储型持有者密钥的依赖。若替换后的密钥仍回归到实质相同的架构，眼前的事件或许会结束，但潜在的集中风险依然存在。

OpenCode 安全漏洞并不意味着每一台运行 OpenCode 的开发者机器都遭到了入侵。它表明，一个可选的托管层可能会将关联的服务提供商账户转化为共同的事件暴露面。

安全团队应针对这一更狭义的发现采取精准行动：查找相关安装实例，识别 Console 的关联关系，从源头撤销受影响凭证，并与各服务提供商核验活动记录。

随后还应提出一个更棘手的问题：你的组织是否清楚哪些 AI 代理能够执行代码、它们的凭证存放在哪里，以及当其中一道信任边界失效时，由谁负责响应？