LLM 修复向第三方误传密钥漏洞

LLM 0.37.2 修复的是一个容易被忽略的密钥发送问题：你明明在调用第三方模型，工具却可能把已配置的 OpenAI API key 发给对方。原文列出了两个明确的触发条件，都与第三方 OpenAI-compatible API 的配置和调用方式有关。

对使用 LLM 命令行工具切换模型供应商的程序员，这条更新值得检查。它提醒我们：接口兼容，只代表请求格式能够对接；密钥是否发给了正确的服务，还要看客户端如何选择凭据。

哪两种情况会把密钥发错地方

作者说明，Daniel de Araujo 报告了两个安全问题，对应 GHSA-v9h7-jj4g-f862 和 GHSA-r639-rr7r-x72w。LLM 0.37.2 修复了这两个问题，但原文没有分别交代公告编号与触发条件的对应关系。

第一种情况是：配置通过 api_key_name 指定了密钥名称，但这个名称对应的密钥从未存储过。此时，工具可能意外把已经配置的 OpenAI API key 发给第三方供应商。

这里要区分「写了一个密钥名称」和「真正存好了这个密钥」。配置里有引用，不代表引用的凭据存在。原文描述的风险，恰好出现在这个缺口上。

第二种情况是：模型配置带有 responses: true，运行时又传入了 -o chat_completions 1。这个组合也可能导致 OpenAI API key 被发送给第三方。

原文没有展开内部调用链，因此不能进一步断言是哪段回退逻辑出了错，也不能推断所有 Responses 与 Chat Completions 切换都会触发问题。

问题不是请求调用失败，而是请求可能带上了不该发送的密钥。

为什么接入第三方端点会涉及 OpenAI 密钥

LLM 支持通过 extra-openai-models.yaml 接入其他供应商的 OpenAI-compatible API endpoints。大白话讲，就是沿用兼容 OpenAI 的接口格式，让同一个客户端调用不同供应商。

从 0.37 开始，这套机制可以通过新增的 llm openai endpoint add 命令管理。

这很方便，但也把两个需要分别处理的问题放到了一起：请求应该发往哪个端点，以及请求应该携带哪把密钥。前者正确，并不能保证后者正确。

这次修复暴露出的两个边界也很具体：一个是指定凭据不存在，另一个是模型配置与运行参数发生组合。只验证默认配置能否成功请求，很容易漏掉这些路径。

我的判断

我认为这条更新最有价值的地方，是给出了可以直接核对的触发条件。使用 LLM 接入第三方服务的人，可以检查自己的配置是否涉及 api_key_name、responses: true 和 -o chat_completions 1，无需先理解整个客户端实现。

但它是一则简短的安全修复公告。作者没有提供复现代码、受影响版本范围、实际泄露案例，也没有说明修复后的具体行为。不能据此声称某个用户已经泄露密钥，更不能把风险扩大到所有 OpenAI-compatible 客户端。

相比按供应商分别配置客户端，统一入口减少了使用成本，也要求工具正确维护端点与凭据的对应关系。哪种方式更适合团队，原文没有对照数据；这里能确认的是，LLM 曾在上述两个条件下出现凭据发送问题，并在 0.37.2 中修复。

能拿来做什么

• 如果你使用 LLM 调用第三方模型，检查当前版本是否包含 0.37.2 的修复，并核对相关端点配置。
• 检查 api_key_name 指向的密钥是否确实已经存储，不要把填写名称当成凭据配置完成。
• 如果模型设置了 responses: true，检查脚本或日常命令是否同时传入 -o chat_completions 1，将这个组合列为排查重点。
• 如果你维护 Node 多供应商调用封装，可以把「指定密钥不存在」和「切换接口调用方式」加入凭据路由验证，检查请求最终发往哪里、携带哪一组凭据。