Claude Code 10 月 14 日更新静默修复网关密钥泄露：五类请求曾把第三方网关 API key 发给 Anthropic

10 月 14 日的 Claude Code changelog 更新里，藏在 131 条 bug 修复中间的两行 "Fixed"，值得所有走第三方网关的 Claude Code 用户停下来看一眼。原文很短：

"Fixed the server-managed settings request to Anthropic carrying a third-party gateway's API key when a managed settings file sets ANTHROPIC_BASE_URL"

"Fixed feature flag, startup, fast mode, profile and feedback requests to Anthropic carrying the API key configured for a third-party gateway (ANTHROPIC_BASE_URL); Anthropic API keys are still sent"

翻译成白话就是：在这个更新之前，如果你把 ANTHROPIC_BASE_URL 指向了第三方网关——OpenRouter、公司自建的 LLM 网关、云厂商的代理——Claude Code 有六类请求，会把你配给网关的那把 API key 原样塞进请求头，发往 Anthropic 官方。

你的模型对话流量确实走了网关，没错。但 feature flag（特性开关）、startup（启动）、fast mode（快速模式）、profile（资料）、feedback（反馈）这五类请求，以及 server-managed settings（服务端托管配置）请求，走的是 Anthropic 官方域名，却带着网关的钥匙。Anthropic 没有发 CVE，没有严重度评级，没有单独的安全公告，只是在 changelog 的日期节里写了两行修复说明。这是一次典型的"静默修复"。

拆开看：两条修复分别管什么

第一条针对的是企业场景。很多公司通过 MDM（移动设备管理）或统一的 managed settings 文件给员工统一下发 Claude Code 配置，其中就包括 ANTHROPIC_BASE_URL——员工的流量先走公司网关做审计、计费和内容策略。这个场景最要命的地方在于：终端用户本人可能根本不知道自己的客户端走了网关。他以为自己在和 Anthropic 直连，实际上他的网关密钥正被客户端悄悄递给 Anthropic，而他没有任何感知，也无从排查。

第二条覆盖面更广。feature flag、startup、fast mode、profile、feedback——这些都是 Claude Code 启动和运行时例行发出的"附带请求"：拉一下功能开关配置、上报一次启动事件、查一下资料、发一条反馈。它们的共同点是：用户看不见、感知不到、从来不会在界面上留下痕迹。你盯着终端里漂亮的流式输出，根本不会想到后台每隔一段时间，就有一把本该只属于网关的钥匙被送到了 api.anthropic.com。

而修复说明后半句 "Anthropic API keys are still sent" 恰恰说明这次修复做得相当细粒度。Anthropic 没有一刀切地把所有发往官方的请求都剥掉认证，而是区分了两种钥匙：如果你配的是 Anthropic 官方的 key，照发不误；只有当你配的是第三方网关的 key（即 ANTHROPIC_BASE_URL 被自定义时），才不再往 Anthropic 的请求里塞。这是一个"按钥匙归属路由认证"的修复，说明问题出在客户端认证逻辑的分支判断上，而不是简单的"忘了清 header"。

为什么这个 bug 属于最狡猾的那一类

网关用户的核心安全假设只有一句话："我的网关密钥只发给我的网关。"这个 bug 打碎的正是这个假设——而且打碎的方式极其隐蔽：主链路完全正确。

想想看，一个谨慎的工程师会怎么验证网关接入？他会抓包看模型请求的 Host 是不是网关域名，会看网关控制台的请求日志，会确认计费走的是网关的账单。所有这些检查都会通过，因为模型请求确实去了网关。问题出在那些他永远不会去检查的请求上：谁会去审计 feature flag 拉取请求的目标域名和 Authorization 头？谁会想到"反馈"功能会带着网关密钥？

这就是 agent 工具链里反复出现的一类问题：攻击面不在主链路，而在边角料请求。主链路是所有人都会盯着的地方——文档写得最细、测试覆盖最全、安全评审第一个看。但一个成熟的 agent 客户端背后，是几十种辅助请求在支撑：telemetry、特性开关、版本检查、配置同步、错误上报。它们天然被认为是"无害的"，天然不在安全审计的视野里，而它们恰恰共享着同一套认证逻辑和同一个配置读取路径。一次分支判断的疏忽，钥匙就走错了门。

类似的剧本在 agent 生态里不是第一次上演。MCP 工具描述被截断、prompt 注入经由工具元数据进入上下文、OAuth token 被日志系统原样记录——每一次都是主链路之外的"附带通道"先出事。这次 Claude Code 的网关密钥泄露，是这个剧本在"认证路由"这一章的新注脚。

诚实区：changelog 没说的，我们不替它说

写到这里，必须停下来做一次诚实标注，因为有几件事 changelog 原文没有说，而读者最想知道的恰恰是它们。

第一，Anthropic 没有发布 CVE，也没有给出严重度评级。两条修复就是 changelog 日期节下的普通 bug 修复条目，和"修复了双击选中单词的折叠行为"排在一起。不要把它脑补成一次正式的安全事件响应——至少从公开信息看，它不是。

第二，密钥是否被 Anthropic 服务端记录或留存，未知。changelog 只说了"不再携带"，没说过去携带的那些请求在 Anthropic 一侧发生了什么：是被网关鉴权直接拒绝、进了错误日志、还是被正常记录？原文一个字没提。任何"Anthropic 不会存你的 key"的说法都是猜测，我们不写猜测。

第三，受影响的版本范围，未知。changelog 页面按日期分组，不显示版本号（本文写作时页面上只有 "October 14, 2026" 的日期节，没有 v2.1.x 之类的版本号）。因此我们无法给出"从 x.y.z 到 x.y.z 受影响"的精确口径，只能说：10 月 14 日 changelog 更新之前的版本存在这个问题，更新之后的版本包含了修复。

把"未知"写清楚不是怯懦，是这类安全报道唯一负责任的写法。夸大成灾难是错的，轻描淡写成"修了就好"也是错的。

如果你走网关，现在该做三件事

先说结论：升级、轮换、审计。按这个顺序，一件都别省。

1. 升级到包含 10 月 14 日 changelog 更新的版本。运行 claude --version 看看你现在的版本，然后升级到最新。注意 changelog 页面本身不标注版本号，所以"最新版"就是你的目标——不要去找某个具体的修复版本号，因为官方没给。这个 bug 的修复是客户端行为变更，不需要你改任何配置，升上去就行。

2. 轮换你的网关 API key。这是最容易被"修了就好"心态跳过的一步，但逻辑上必不可少。你的网关密钥曾经被发往过 Anthropic 的服务器，而 Anthropic 是否记录、留存了它，是未知项（见上一节）。密钥一旦离开过它该去的地方，保守的安全实践只有一条：换掉。去你的网关控制台（OpenRouter、云厂商控制台或自建网关的管理后台）生成一把新 key，更新本地和 CI 里的配置，作废旧 key。整个过程通常不超过十分钟，成本极低，不做才是亏。

3. 审计企业 managed settings 的下发范围。如果你是团队的平台工程师或 IT 管理员，去查一下：哪些设备、哪些员工的 managed settings 文件里写了 ANTHROPIC_BASE_URL？这些人就是第一条修复覆盖的人群——他们甚至可能不知道自己走了网关。给他们发一封简短的通知，内容三句话：升级 Claude Code、轮换个人网关 key（如有）、忽略这封邮件之外的恐慌。另外值得在网关侧查一下请求日志：有没有来自 api.anthropic.com 方向的异常？虽然客户端不会告诉你历史泄露的全貌，但网关侧的 key 使用记录至少能帮你确认轮换是否彻底。

如果你从没设过 ANTHROPIC_BASE_URL，一直用的是 Anthropic 官方 key 或订阅登录，那这次修复和你无关——"Anthropic API keys are still sent"，你的请求行为没有任何变化。可以关掉这篇文章了。

给做企业 agent 落地的人：一句忠告

如果你正在给公司搭 agent 落地——统一网关、统一鉴权、统一审计——这次事件应该进你的 checklist，而且是以"模式"的身份进去，不是以"个案"的身份。

模式是这样的：任何 agent 客户端都会发出两类请求，一类是你要它发的（模型调用），一类是它自己要发的（telemetry、特性开关、配置同步、崩溃上报）。第二类请求的数量通常是第一类的数倍，而它们的安全属性——发给谁、带什么认证头、失败时怎么重试——几乎从不出现在厂商文档的显眼位置。你的威胁模型如果只覆盖了"模型流量走网关"，那就只覆盖了一半。

可操作的建议有三条。第一，把"密钥只发给谁"写成可测试的断言，而不是文档里的一句话：比如在 egress 代理上给网关 key 做域名白名单，一旦有发往非网关域名的请求携带了它就告警。第二，对 agent 客户端的版本升级建立和浏览器补丁同等级别的响应流程——这次修复是静默的，没有 CVE 推送会提醒你，不主动跟 changelog 就永远不知道。第三，定期抓包看一次真相：让客户端跑十分钟，把所有出站请求的 Host 和 Authorization 头列出来，花半小时，你会比读十篇安全博客更了解你正在用的工具。

时间线与影响面：能拼出的全貌

把已知事实摆成时间线：10 月 14 日，Claude Code 官方 changelog 的 "October 14, 2026" 日期节下出现两条修复，131 条 bug 修复中的两条，没有 CVE，没有单独公告。10 月 16 日的 changelog 更新（本文写作时页面最新的一节）没有再提及此事，说明修复被认为已完结。影响的起点则无法确定——changelog 不写版本号，我们既不知道这个 bug 是哪一版引入的，也不知道它静默存在了多久。这是"静默修复"的另一面代价：修复静默，引入也静默，暴露窗口的长度成了一个永远填不上的空。

影响面可以分三层看。第一层是个人网关用户：自己配了 ANTHROPIC_BASE_URL 指向 OpenRouter 这类公共网关的人。他们的 key 曾被发往 Anthropic，风险敞口取决于 Anthropic 服务端对这类"带错 key 的请求"的处理——未知，所以轮换是唯一稳妥的答案。第二层是企业 MDM 下发场景：员工无感知走网关，key 的归属可能是公司统一采购的网关额度，一把 key 泄露影响的是整个组织的配额和账单。第三层是自建网关的团队：key 背后可能是直连云厂商、按量计费的通道，泄露意味着别人理论上可以用你的 key 消费你的额度——注意是"理论上"，因为我们并不知道 Anthropic 是否会把收到的网关 key 用于任何用途，但"理论上能用"本身就足以触发轮换。

还有一个值得单独提醒的群体：在 CI 里跑 Claude Code（如 Agent SDK、headless 模式）并配置了网关的团队。这类场景下 startup、feature flag 这类附带请求同样会发出，而且 CI 机器通常 24 小时在线、频繁启动会话，附带请求的发送频率可能比个人桌面端高得多。如果你的 CI 镜像里 pin 了旧版本 Claude Code，升级的优先级应该提到最高。

结语：静默修复是好消息，也是坏消息

好消息是 Anthropic 修得干脆：两条修复，一条管企业托管配置，一条管五类附带请求，而且修复逻辑是细粒度的、按钥匙归属区分的，没有粗暴到影响正常用户。10 月 14 日之后升级的用户，这个问题就不存在了。

坏消息是"静默"本身。没有 CVE，没有安全公告，没有严重度评级——意味着没有标准化的通知渠道会把这件事推到你面前。你得自己养成看 changelog 的习惯，或者依赖你信任的媒体替你盯。这篇文章就是干这个的。

最后回到开头那句话：网关用户的核心安全假设是"网关密钥只给网关"。这个假设被打破一次，就应该被加固一次——不是加固成另一句口号，而是加固成一条能被测试、被告警、被审计的规则。下一次出事的可能不是 Claude Code，可能是你工具链里的任何一个 agent 客户端。到那时，希望你的 egress 代理先比 changelog 更早告诉你。

技术上它是怎么发生的：一次合理的推测

changelog 没有给根因分析，但从修复的措辞可以做出相当可靠的推测——注意，以下是推测，我会明确标出哪句是事实、哪句是推理。

事实：模型主请求走自定义 ANTHROPIC_BASE_URL 时认证是正确的，网关能正常鉴权；只有发往 Anthropic 官方的附带请求带错了 key；修复后"Anthropic 的 key 照发，网关的 key 不再发"。

推测：Claude Code 客户端内部很可能有一套统一的"请求构造器"：从配置里读出当前生效的 API key，往每个出站请求的 Authorization 头里塞。模型请求在构造时被正确地路由到了网关 URL，所以 key 和 URL 是配对的。但 feature flag、startup、feedback 这类请求的目标是写死的 Anthropic 官方域名——它们不走网关，却共享了同一套"取当前 key"的逻辑。于是出现了一种错位的配对：URL 是 Anthropic 的，key 是网关的。

为什么说这个推测可靠？因为修复措辞 "Anthropic API keys are still sent" 暴露了修复的形状：修复不是在"发往 Anthropic 的请求"上统一去掉认证头，而是在"往请求里塞 key"的那一步加了一个判断——这把 key 是谁的？如果是 Anthropic 自家的，照塞；如果是第三方网关配的，不塞。这正是"按钥匙归属路由认证"的逻辑，也反过来印证了 bug 的位置：出在认证装配层，而不在 URL 路由层。

这个细节对开发者有直接的启发：当你写任何会发出多种出站请求的客户端时，"key 归谁"和"请求发给谁"必须是两个独立的决策，不能默认它们永远一致。 只要你的客户端同时支持自定义 base URL 和直连官方两种模式，这两个决策的交叉点就是 bug 的温床。Claude Code 踩了这个坑，你的 agent 网关、你的内部 CLI 工具，写认证逻辑时都值得对着这个案例自查一遍。

横向看：这不是 Claude Code 一家的毛病

把视野拉开一点，ANTHROPIC_BASE_URL / OPENAI_BASE_URL 这类"换 base URL 走网关"的用法，是整个 agent 工具生态的通用模式：OpenRouter、Cloudflare AI Gateway、各云厂商的模型网关、自建的 LiteLLM 代理，全都靠这个环境变量接入。而"附带请求不认 base URL"几乎是所有这类客户端的通病——telemetry 发给厂商官方、版本检查走官方 CDN、崩溃上报走官方端点，这些硬编码的官方域名在引入 base URL 覆盖时，经常被遗忘在重构之外。

区别只在于，大多数客户端的附带请求要么不带认证、要么带的是匿名遥测 ID，所以即使目标错了，后果也只是"遥测数据发给了厂商"这种隐私层面的问题。Claude Code 这次的特殊之处在于：它的附带请求带了高价值的密钥材料——一把能直接消费网关额度的 API key。同样是"附带请求走错门"，带什么出门决定了事件的等级。这也是为什么同样写 changelog，别人的一行修复无人问津，这两行值得单独写一篇文章。

对网关运营者来说，这件事还有另一层含义：你的网关 key 一旦被发往上游厂商，即使厂商可信、即使最终"没出事"，你的威胁模型里也应该把它当作一次泄露来处理。因为"可信"不等于"被授权"——Anthropic 从未被你的安全策略授权持有这把 key。密钥管理的铁律是按授权边界划分，而不是按信任程度划分。这也是为什么本文坚持把"轮换 key"列为必做项，而不是可选项：轮换的依据不是"Anthropic 会作恶"，而是"它不该有"。