LiteLLM：认证回退必须绑定目标，MCP权限不等于管理员权限

wiki/ai/sources/litellm-auth-fallback-and-gateway-blast-radius.md

分类：ai / sources · 更新：2026-09-23 09:11

LiteLLM：认证回退必须绑定目标，MCP权限不等于管理员权限

核心判断与知识轴

MCP Gateway / harness-runtime / sandbox-security。 最值得复用的不是“又一个网关漏洞”，而是：身份校验失败不能自动变成另一种认证成功；允许转交上游认证，也必须绑定完整目标集合，并保持“本地已验证”和“等待上游验证”两种状态的区别。 MCP-Gateway-Runtime 若混合模型流量、MCP工具、管理API和出站代理，必须逐面计算权限范围，不能把入口会话等同所有能力。^[raw/articles/litellm-auth-fallback-fixed-code-2026-09-23.md]

这对Hermes接入外部工具有直接意义：Bearer字符串可能属于gateway、某个上游服务或完全无效；凭据存在不证明身份，转发成功也不证明正确目标有权执行。统一网关应减少凭据暴露，而非让任何一次认证回退借到所有下游的权限。

来源、日期与验证范围

Wiz原始研究发表于 2026-09-09；CVE记录发布于07-08，GHSA公开时间为07-22；CVE/CISA-ADP记录KEV加入日为09-02。都是历史记录，本轮09-23补入库，不是今日新漏洞。
CVE-2026-59822 / GHSA-7488-6r32-c95q：公告受影响范围 < 1.84.0，修复版 1.84.0。它是这一漏洞的最低修复线，不是最新版本或全产品安全保证。^[raw/articles/litellm-auth-fallback-fixed-code-2026-09-23.md]
固定实现：73869f0faf7d11ee21adcb5f91b8c33a340b6c2c（04-25）。已读认证方法和该提交返回的实现/测试diff；完整源码保存为原始附件。未安装或启动LiteLLM、未运行完整上游pytest、未探测公网实例。
本机执行21项提取方法的合成fixture；Request、认证器和registry为明确替身，因此只证明分支/集合逻辑，不证明真实上游OAuth、ASGI路由或工具调用安全。^[raw/notes/ai-radar-evidence-checks-2026-09-23.md]

机制一：从隐式降级到目标绑定的认证模式

旧分支在LiteLLM key校验返回401/403时构造空UserAPIKeyAuth()，却没有先判断目标是否需要OAuth透传。这样，失败的本地认证被转换成可继续进入MCP的匿名对象；实际可达工具仍受部署的server配置、allow_all_keys等条件影响，不能声称所有部署均能访问全部工具。^[raw/articles/litellm-wiz-auth-boundaries-2026-09-23.md]

固定实现的判定顺序：

明确的x-litellm-api-key始终走本地认证，不能因另有Authorization而逃入回退。
仅Authorization时先试本地认证；只有401/403且所有解析出的目标均配置auth_type=oauth2，才允许匿名透传。
x-mcp-servers出现就优先使用，包括显式空列表；无该头才解析/mcp/{server}或/{server}/mcp。空集合、未知目标、混合OAuth/非OAuth集合均拒绝回退。
500等非认证错误继续抛出，不应被当成上游OAuth模式。^[raw/articles/litellm-auth-fallback-fixed-code-2026-09-23.md]

关键边界：允许回退并没有证明opaque token有效，而是把验证责任交给指定上游。测试中/mcp/key加显式x-mcp-servers=oauth会按头里的目标判定，这是源码规定的优先级，不是已证实的绕过；只有继续核对实际数据面是否也使用同一目标集合，才能评价安全性。此处与agentgateway-session-policy-and-inspection-boundaries的session/backend/policy绑定直接相连。

机制二：公共发现路由不能靠整条URL的子串识别

同一修复将".well-known" in str(request.url)收紧为request.url.path.startswith("/.well-known/")，避免query、host或深层路径中的相似字符串触发公共分支。当前方法仍依赖host把该前缀下的路由严格限制为合法metadata资源；固定前缀检查本身不等于对整个应用路由表的证明。^[raw/articles/litellm-auth-fallback-fixed-code-2026-09-23.md]

这补充gemini-cli-oauth-bootstrap-and-workspace-trust：发现阶段既涉及出站，也涉及入站认证豁免；必须明确豁免对象、方法、路径规范化与最终handler，而不是让一个“看起来像discovery”的URL获得通用权限。

机制三：把攻击前置条件拆开，不拼接不存在的链

Wiz明确说，MCP认证绕过只提供MCP侧访问，不赋予管理员权限，也不能直接利用其另述的管理面RCE。管理面代码执行、未改默认管理员key、无认证管理员角色、管理员可配置的pass-through出站是不同条件，不可合并成“任意Bearer→管理员→云凭据”的必然链。^[raw/articles/litellm-wiz-auth-boundaries-2026-09-23.md]

另一耐久反例是“测试入口有限制、真实注册入口没有同等限制”：Wiz记录旧custom-code guardrail的测试入口有检查，而注册/编译路径遗漏。此处仅转述原始研究，未验证该sandbox是否足够强，不因移除builtins就给出Python沙箱安全结论。管理员代理出站也需要egress与云服务账号最小权限，不能把“管理员受信任”误解为没有云端影响范围。

对Hermes与内部runner的可执行启发

为凭据模式保留明确状态：本地已验证、上游待验证、拒绝；不要用一个空身份对象统一表示“允许”。
在隔离mock中配对测试未知/空/混合目标、显式key失败、500错误，以及Authorization与目标头冲突；随后读取实际served backend，补齐从策略判定到数据面的证据。
将MCP、管理API、代码注册、出站代理分别登记授权合同；测试入口与真实effect入口共用策略，并对真实状态读回验收。
凭据只记录引用和责任主体，不把token原文写入wiki、trace或候选账本。上述为建议，不代表本轮已改Hermes配置。

未解问题与深度判断

未验证目标别名/组解析、真实proxy规范化、上游token audience/撤销、在途请求和所有路由的同目标约束。新版本还需单独核配置与后续公告；本轮未做用户资产漏洞扫描。

晋升理由：原始公告、研究前置条件、固定实现与离线正反例能形成可迁移的认证回退合同，并纠正“一个漏洞自动贯通所有权限面”的错误叙述；价值高于只转发漏洞新闻。与Harness-Engineering和Agent-Benchmarks互链，供接入验收复用。

写入记录

2026-09-23 09:08 CST：新增LiteLLM认证回退、公共发现路径与权限面拆分分析；归档固定源码和原始公告，明确21项合成fixture及未执行的真实认证/数据面边界。