LiteLLM CVE-2026-49468：网关自身路由中的 Host 头身份验证绕过

这是什么？

2026 年 6 月 17 日，GitHub 安全公告数据库公布了 LiteLLM 中一个严重的身份验证绕过漏洞，标识为 GHSA-4xpc-pv4p-pm3w，编号 CVE-2026-49468。LiteLLM 是部署最广泛的 LLM 代理/网关之一——它是 CrewAI、DSPy、Microsoft GraphRAG 以及大量智能体框架底层的模型路由层——因此其代理中的一个免认证漏洞所覆盖的攻击面非常大。

该漏洞是一种Host 头注入，可绕过 LiteLLM 自身的授权层（CWE-290，通过欺骗绕过身份验证）。它影响 1.84.0 之前的所有版本，并已在 1.84.0 中修复。公告将其评为严重，CVSS v4 评分较高：网络攻击向量、低复杂度、无需身份验证和用户交互。该漏洞由 Le The Thang（KCSC） 和 Kim Ngoc Chung（One Mount Group） 负责任地报告。

如果你觉得似曾相识，那是对的。它是 BadHost（CVE-2026-48710）——2026 年 5 月同类性质的 Starlette 漏洞——在应用层的”表亲”，并证明这一类漏洞能够在框架修补之后依然存活。

工作原理

LiteLLM 在 litellm/proxy/auth/auth_utils.py 中的 get_request_route() 函数里决定传入请求对应哪条路由。该函数读取 request.url.path 来计算用于授权决策的有效路径。

在基于 Starlette 的应用中，request.url 是根据客户端提供的 Host 头重建的。因此 request.url.path 部分受攻击者影响。而 FastAPI 则使用取自 ASGI 请求行的路径将请求分发到处理器——这是另一个事实来源。通过伪造 Host 头，攻击者可使鉴权层评估的路径与 FastAPI 实际执行的路径发生分歧。

# 基于 2026 年 6 月 17 日公开公告的概念示意。
# 此处不复现针对任何真实系统的有效载荷。

鉴权层 (get_request_route → request.url.path，由 Host 派生)：
    看到一个无害 / 非特权路径  → 检查通过

FastAPI 路由器 (路径取自 ASGI 请求行)：
    分发到特权管理端点 → 处理器执行

结果是：一个本应被访问控制拒绝的请求，仍然抵达了受限的管理端点。其根本原因与 BadHost 完全相同——基于客户端可控的头部派生值做出安全决策——只不过这次它位于 LiteLLM 自身代码中，而非 Starlette。修补框架并没有消除这一模式；应用自己又重新实现了它。

关键在于：并非所有部署都可被利用。根据公告，在上游对 Host 头进行规范化或校验的环境实际上受到保护：CDN、WAF、带严格 server_name 校验的反向代理，以及按主机路由的云负载均衡器，都会在请求抵达 LiteLLM 之前剥离或拒绝该操纵。**LiteLLM Cloud 客户不受影响。**真正处于风险中的，是一个或多或少直接暴露于不可信网络、前面没有任何主机校验的 LiteLLM 代理。

为什么重要

网关是一个汇聚点。团队之所以把 LiteLLM 放在模型前面，正是为了集中管理密钥、预算、速率限制和路由——这意味着它的管理端点凌驾于代理所代理的每一个供应商凭据和策略之上。对这些端点的免认证访问价值很高，而 LiteLLM 已在约两个月内被披露了一个免认证 SQL 注入、一条经 MCP 端点的 RCE 链以及这次身份验证绕过。

更深层的要点是漏洞类别的复发。BadHost 已在 Starlette 层于 1.0.1 中修复。然而同样的错误——“用 Host 派生的路径来做鉴权决策”——在上一层、在 LiteLLM 自身的路由辅助函数中再次出现，拥有自己的 CVE 和自己的补丁。框架补丁并不会回溯性地修复重新派生同一不可信值的应用代码。如果你跟踪了 BadHost 并据此认为自己的网关因此是干净的，那个结论是错的。

防御措施

将 LiteLLM 升级到 1.84.0 或更高版本。这就是修复方案，公告指出它无需任何配置更改——锁定依赖、重建、重新部署。对任何可从互联网访问的代理，应将其视为优先补丁。

**在代理前置一层 Host 校验。**若无法立即升级，请将 LiteLLM 置于 CDN、WAF 或强制严格 Host / server_name 校验的反向代理之后，或按主机路由的负载均衡器之后。拒绝任何 Host 头中包含 /、?、#、空白或超出 RFC 9112 authority 语法字节的请求。这既缓解 CVE-2026-49468，也能抵御下一个变种。

**收紧网络暴露面。**模型网关很少需要从开放互联网访问。将其绑定到内部平面，用 mTLS 或客户端证书保护管理端点，并实施最小权限网络策略，使代理只能被合法调用它的服务访问。

**停止基于头部派生路径进行授权。**与 BadHost 相同的架构教训：永远不要基于由客户端可控头部重建的值做出授权决策。在 ASGI/Starlette 代码中，应基于 scope["path"]（来自请求行）而非 request.url.path（由 Host 派生）来做路由和访问控制。审查你自己栈中的自定义中间件和路由辅助函数是否存在同一模式。

**梳理网关的 CVE 节奏。**鉴于 LiteLLM 的一连串披露，请订阅该项目的 GitHub 安全公告，在依赖扫描器中跟踪 GHSA 编号，并为代理你模型密钥的组件设定一个明确且较短的补丁 SLA。

状态

项目	参考	日期	备注
公开公告	GitHub GHSA-4xpc-pv4p-pm3w / CVE-2026-49468	2026-06-17	严重，CWE-290
受影响版本	LiteLLM < 1.84.0	—	代理鉴权层
修复版本	LiteLLM 1.84.0	2026-06-17	无需配置更改
根本原因	get_request_route() 读取由 Host 派生的 request.url.path	—	鉴权/路由不一致
不受影响	LiteLLM Cloud；前置校验 Host 的 CDN/WAF/反向代理/LB 的部署	—	上游规范化 Host
报告者	Le The Thang（KCSC）、Kim Ngoc Chung（One Mount Group）	2026-06-17	负责任披露
关联类别	BadHost（CVE-2026-48710），Starlette < 1.0.1	2026-05-22	同一不一致，框架层

真正的标题不是”又一个 LiteLLM 漏洞”。而是：一个 Host/路径不一致问题，已在框架中修复过一次，又回到了网关自身的代码中——这证明这一类漏洞需要的是模式层面的防御（永远不要基于头部派生的路径进行授权），而不仅仅是一次版本升级。