LiteLLM CVE-2026-59822 深度分析：一个空对象回退让 AI 网关的 MCP 会话裸奔

一句话结论

LiteLLM（BerriAI 出品的 LLM 代理/AI 网关）的 MCP Streamable HTTP 端点存在认证绕过：LiteLLM key 校验失败后，代码没有 fail closed，而是掉进 OAuth2 passthrough 回退分支，返回了一个空的 UserAPIKeyAuth() 对象。攻击者用任意伪造的 Authorization: Bearer whatever 就能建立"已认证"的 MCP 会话，进而调用该网关配置的所有 MCP 工具。这就是 CVE-2026-59822，CVSS 8.8（CWE-287/CWE-306），影响 1.84.0 之前所有版本。

时间线比补丁发布更刺眼：

时间	事件
2026-07-07	Wiz 蜜罐观察到该漏洞的在野利用（早于公开披露）
2026-07-08	CVE 编号发布（cvelistV5 记录）
2026-08	1.84.0 修复（PR #26463，commit 73869f0）
2026-09-02	CISA 纳入 KEV 目录
2026-09-16	联邦机构修复截止日（BOD 26-04）

再次出现"利用早于披露"的模式——和本站之前拆过的 Wiz 90 天 AI 蜜罐报告 里 LiteLLM 被攻击者当提款机的结论互相印证：AI 基础设施已经是主动攻击目标，不是理论风险。

漏洞原理：fail open 的回退分支

认证设计：两条路径共享一个出口

LiteLLM 的 MCP 端点支持两种认证模式：

1. 原生 key 认证：请求带 LiteLLM 签发的虚拟 key（sk-...），网关校验后按 key 的权限路由
2. OAuth2 passthrough：网关不校验 token 本身，把 Authorization 头透传给上游 MCP 服务器，由上游做 OAuth 校验

问题出在这两条路径的分发逻辑上。简化后的缺陷代码形状大致是：

async def authenticate(request) -> UserAPIKeyAuth:
    token = request.headers.get("authorization", "")

    # 路径 1：LiteLLM 原生 key 校验
    try:
        auth = await validate_litellm_key(token)
        return auth
    except HTTPException as e:
        if e.status_code in (401, 403):
            # 缺陷所在：校验失败后不是直接拒绝，
            # 而是尝试 OAuth2 passthrough 回退
            auth = await oauth2_passthrough_fallback(request)
            return auth   # ← 可能返回空对象

def oauth2_passthrough_fallback(request) -> UserAPIKeyAuth:
    # 修复前：不检查目标 MCP server 是否真的配置为 OAuth2 模式，
    # 直接构造一个"已认证"的空凭据对象返回
    return UserAPIKeyAuth()   # 空 object，但调用方拿它当已验证凭据

本质是 fail open：认证的语义应该是"要么返回有效凭据，要么抛异常拒绝"，而这个回退分支引入了第三种状态——"返回一个空的凭据对象"。后续的授权检查只判断"有没有 UserAPIKeyAuth"，不判断它是否为空，于是任意 Bearer 字符串畅通无阻。

这不是什么新奇的漏洞类型——它和本站拆过的 Kestra CVE-2026-49869（endsWith() 后缀误判绕过认证）、Postgres MCP Pro CVE-2026-85620（AST 节点类型错配绕过白名单）是同一族：认证/授权逻辑中的边界分支没有 fail closed。MCP 生态 9 月连发的几个 CVE 几乎全是这一模式。

1.84.0 的修复：门控 + fail closed

修复（PR #26463）做了两件事：

1. passthrough 只在配置了 OAuth2 时启用：目标 MCP server 必须显式配置为 OAuth2 模式，否则回退分支根本不存在
2. 解析失败一律拒绝：上游 server 无法解析、或不在 OAuth2 模式时，直接 fail closed 抛 401，不再返回空对象

修复后的语义回到了"二态"：有效凭据，或者拒绝。

为什么危害远超 CVSS 8.8：网关即控制面

单看 CVSS 8.8 好像只是"高级"。但 LiteLLM 的部署位置决定了实际影响是控制面级别的：

┌──────────────┐     ┌─────────────────────┐     ┌──────────────────┐
│ AI Agent /   │     │   LiteLLM Gateway   │     │  MCP Servers     │
│ Cursor/自研  │────▶│  - 持有各家模型 key  │────▶│  - 数据库查询工具 │
│ 客户端       │     │  - 记录全部 prompt   │     │  - 工单系统工具   │
└──────────────┘     │  - 自定义护栏代码     │     │  - CI/CD 工具    │
                     │  - Postgres 审计库   │     │  - 文件系统工具   │
                     └─────────────────────┘     └──────────────────┘
                            ▲ 攻击者拿下一个空会话 = 拿到右半边全部能力

一个"已认证"的空 MCP 会话意味着：

• 调用任意已配置的 MCP 工具：数据库查询工具 → 拖库；CI/CD 工具 → 投毒构建产物；文件工具 → 读敏感文件。这正是 Postgres MCP Pro 和 AWS 官方 MCP server 系列 CVE 的同一攻击面
• API key 大厅：LiteLLM 进程内存里持有 OpenAI/Anthropic/Google 等全部上游 key，配合同批披露的 CVE-2026-59821（见下节）可以直接代码执行提取
• patch-gap 被武器化：1.84.0 在 4 月底就已发布，7 月 7 日 Wiz 蜜罐才捕获利用——补丁空窗约十周，没升级的实例全程裸奔
• 审计面成为高价值目标：网关日志与审计库里有全公司所有 Agent 的调用记录和上游 key 痕迹，一旦会话被污染就是全公司级别的凭据事件

Wiz 蜜罐的实测数据

• 7 月 7 日蜜罐捕获在野利用——比 CVE 披露早一天，比 KEV 收录早近两个月
• 2026 年 2 月扫描：公网 3,074 个 LiteLLM 实例，其中 294 个（9.6%） 接受文档示例 master key sk-1234，这 294 个里又有 191 个（6.2%） 连认证都完全没启用
• 本站 9/14 的 Wiz 蜜罐 90 天报告记录了攻击者用单字符 Bearer 绕过、从内存提取 master key 的完整手法

连带漏洞：CVE-2026-59821 护栏代码执行

同一轮披露还有 CVE-2026-59821：LiteLLM 允许管理员定义自定义护栏（guardrail）——围绕推理请求运行的 Python 代码。Wiz 发现生产注册路径没有应用 UI"Run Test"路径同款的禁用模式检查和内建函数剥离沙箱，提交的 Python 可以在代理进程内直接执行（Wiz 测试容器里以 root 跑）。

单独看它需要"能创建护栏"的权限，不构成未认证 RCE。但危险在于组合：修复前，没有配置 master key 的实例会把未认证调用者当代理管理员，护栏端点又没有一致地要求 admin 角色——于是"未认证 → 注册恶意护栏 → 进程内 Python 执行"成为一条现实可行的链。

应急响应清单

立即（今天）：

1. 升级到 ≥ 1.84.0：容器、serverless、甚至工程师本机连生产工具的 laptop 网关都要覆盖。需要护栏代码执行修复的升到 1.82.0-stable 以上即可，但 59822 必须 1.84.0
2. 无法立即升级就封端口：在网络层禁掉 /mcp/ 及相关路由（官方公告明确建议），或在网关前加一层要求网络认证的代理
3. 审计 MCP 访问日志：找"从未匹配过任何真实 LiteLLM key 的 Bearer token"——重点看 7 月初（披露窗口）和 9 月 2 日（KEV 收录，漏洞公开化）前后的异常会话

本周：

4. 轮换凭据：假设暴露过的实例颁发的都是脏会话——轮换 LLM provider key、MCP 工具凭证、以及"已配置工具能触达的一切秘密"
5. 盘点影子部署：数据科学和应用团队起 LiteLLM 的速度远快于资产清单更新。按进程名、镜像名、典型端口扫一遍
6. 默认凭据体检：sk-1234 还能登进来的实例，问题不是 59822，是运维

长期：

7. 把 AI 网关当 Tier-1 控制面：和数据库、CI/CD 系统同级的打补丁纪律、网络隔离（deny 到云 metadata 端点的 egress）、最小权限 workload identity
8. fail closed 审计：自建或二开的 MCP 网关代码，搜一遍所有 except 分支——凡是认证失败后的"回退/降级"路径，都必须以抛异常结束，不允许返回兜底对象

供应链视角：这不是 LiteLLM 一家的问题

把 9 月的 MCP 相关 CVE 摆在一起看：

• Atlassian MCP 路径遍历（CVE-2026-73498）
• AWS 官方 MCP server 命令注入（CVE-2026-87911）
• Postgres MCP Pro 白名单绕过（CVE-2026-85620）
• LiteLLM 认证绕过（本文 CVE-2026-59822）
• ArcadeDB MCP token 明文泄露（CVE-2026-67357）

共同根因是结构性的：MCP server 层不在任何现有的资产管理、供应商尽调、漏洞跟踪流程里。6 月的 MCP 安全危机 30 CVE 报告 和 7 月测量研究（91.8% 的公网 MCP server 无 OAuth）指向同一结论——这个层的治理缺口在扩大而非收敛。Cloud Security Alliance 的《Agentic MCP Security Best Practices》指南已把强制 OAuth 2.1 + PKCE + server metadata 校验写成基线要求，加上昨天拆解的 MCP 治理面三巨头产品化，行业正在补课，但补课速度取决于你们团队今天有没有把 /mcp/ 路由从公网摘下来。

参考资料

• GitHub Advisory: GHSA-7488-6r32-c95q
• 修复 PR: BerriAI/litellm#26463（commit 73869f0，v1.84.0）
• CISA KEV 目录条目 CVE-2026-59822（2026-09-02，截止 2026-09-16）
• Wiz Research: AI Infrastructure Honeypot（第三方佐证，蜜罐 7/7 捕获利用）
• Hive Security: LiteLLM CVE-2026-59822 — Your AI Gateway Is a Cloud Control Plane
• 本站相关文章：LiteLLM CVE-2026-42271 MCP 注入实战 · Wiz AI 蜜罐 90 天报告 · MCP 治理面成型 2026