LiteLLM × Starlette BadHost 零凭证 RCE 链

一句话：Horizon3 把 LiteLLM MCP 测试端点的"需认证"命令注入（CVE-2026-42271）与
Starlette Host 头校验绕过（CVE-2026-48710 "BadHost"）链起来，认证被整体跳过，
变成对 AI 网关的未认证 RCE，CVSS 10.0，且两个组件 2026-09-02 同批进 CISA KEV（在野）。

要点：

• 前提：自托管 LiteLLM 1.74.2–1.83.6，且依赖树里 Starlette ≤ 1.0.0
• /mcp-rest/test/connection、/mcp-rest/test/tools/list 接受完整 server 配置
  （command/args/env），stdio transport 下 LiteLLM 会在 proxy 主机上直接 spawn 命令
• BadHost 绕过的是"用 Host 头校验来当认证门"的实现——框架层解析差异让
  proxy API key 检查整体失效，"authenticated bug"→"unauthenticated RCE"
• 影响：任意命令执行、窃取模型厂商凭证/API keys、横向进入接入的 AI 基础设施
• 修复：LiteLLM ≥ 1.83.7 + Starlette ≥ 1.0.1；KEV 里相邻还有 LiteLLM
  CVE-2026-59822（认证绕过）和 Kestra 命令注入，AI 网关/编排组件正被成体系收割

原语抽象：应用层把"可伪造头的校验"当认证门，框架层解析差异（BadHost）一绕，
认证假设整体崩塌——认证强度由依赖树里最弱的一层决定。
亲戚手法：信任边界工程学家族（与 pre-auth-rce-enterprise-java-bonita-ofbiz
的过滤器差异/JWT 硬编码同族）；差异：两个独立组件的 CVE 互为前提的链式打法，
且载体是 AI 网关——AI 基础设施正被当作普通 Web 攻击面收割。
防御启示：认证判断不能依赖任何可歧义的外部输入（Host/XFF 等）；框架组件
（Starlette 这类传递依赖）的升级要当安全补丁管理。

原文: https://horizon3.ai/attack-research/vulnerabilities/cve-2026-42271-chained-with-cve-2026-48710/
来源发布时间: 2026-06-01