系统:运行中
← 返回所有攻击
INFRASTRUCTURE CRITICAL NEW

LiteLLM CVE-2026-47101→40217:从低权限用户到管理员与 RCE

Obsidian Security 于 2026 年 6 月披露了一条由三个漏洞构成的 LiteLLM 利用链,可将默认低权限用户提升为 proxy_admin 并实现代码执行——对 AI 网关的 CVSS 9.9 级接管。

2026-06-18 // 6 min affects: litellm, ai-gateways

这是什么?

2026 年 6 月 16 日Obsidian Security 公开披露了广泛部署的开源 AI 网关 LiteLLM 中的三个漏洞。串联之后,它们构成一条 CVSS 9.9 的路径,可将默认的低权限用户一路提升至 proxy_admin 角色,进而在网关主机上实现远程代码执行。三个 CVE 分别是:

  • CVE-2026-47102 —— 因 /user/update/user/bulk_update 缺少字段级授权而导致的权限提升。user_role 字段未受保护、可被调用方控制写入,任何能触达这些处理器的用户都能将自己提升为 proxy_admin
  • CVE-2026-47101 —— 授权绕过:非管理员可创建或修改虚拟密钥,其 allowed_routes 被原样持久化,从而获得本不该拥有的路由访问权限,包括仅限管理员的路由。
  • CVE-2026-40217 —— “自定义代码”护栏的沙箱逃逸。管理员可达的路由会编译并运行管理员提供的 Python,而所谓基于 exec() 的沙箱并未真正隔离,导致服务器端代码执行。

据 Obsidian,整条利用链已在 LiteLLM v1.83.14-stable(2026 年 5 月 2 日发布;6 月中旬公开披露)中修复。它不同于 MCP 测试端点 RCE,即 CVE-2026-42271——后者已于 2026 年 6 月被 CISA 加入 KEV 目录;截至本文撰写时,47101/47102/40217 这条链没有公开的 KEV 记录。

工作原理

这条链是一份授权失效的教科书,而非针对模型的攻击。每一环都拆掉一道屏障:

  1. 绕过路由授权(47101)。 LiteLLM 在密钥管理端点上信任调用方提供的 allowed_routes 并逐字存储。低权限账户创建一个引用了越权路由的虚拟密钥。
  2. 提升为管理员(47102)。 触达 /user/update(或批量变体)后,攻击者直接写入敏感的 user_role 字段——自我提升为 proxy_admin,从而获得对用户、团队、密钥、模型以及提示历史的完全访问。
  3. 执行代码(40217)。 作为管理员,攻击者触达护栏的编译/测试路径,在失效的沙箱中运行 Python,从而在网关进程上实现 RCE。

此处不复现任何 payload,理解教训也无需如此:触及角色或路由的“配置”写入是一项授权决策,而 LiteLLM 却把其中数项当作普通的字段更新。反复出现的根因是:路由门把用户可控的密钥状态当作兜底授权来查询,从而颠倒了授权模型。

为何重要

AI 网关并非被动的请求路由器——它是控制平面基础设施。利用链一旦得手,Obsidian 指出攻击者可触达主机级机密,如 LITELLM_MASTER_KEYLITELLM_SALT_KEYDATABASE_URL,以及 OpenAI、Anthropic、Gemini、Bedrock、Azure 及其他已配置后端的提供商凭据。仅凭一个位置,网关就成为机密保险库、授权代理人,以及智能体与模型之间的中间人。

该研究还展示了一种更具 AI 特性的后果:被攻陷的网关可以改写模型响应并操纵下游智能体——包括编码智能体——使其调用攻击者选定的工具。这样,服务器接管就变成针对网关所供给一切内容的供应链跳板。若你在一队智能体前部署 LiteLLM,其影响半径就是它所中介的全部凭据与全部智能体行为的并集。

防御

  • 立即打补丁。 升级到 LiteLLM v1.83.14-stable 或更高版本,据 Obsidian 该版本封堵了整条链。同时确认已越过单独追踪的 CVE-2026-42271 与 CVE-2026-42208 的修复。
  • 暴露后轮换密钥。 若未打补丁的实例曾可从互联网访问,应假设机密已泄露。按优先级轮换:提供商 API 密钥、LITELLM_MASTER_KEYLITELLM_SALT_KEY、数据库凭据,最后重新签发虚拟密钥。
  • 让网关离开公网。 将 LiteLLM 视为任何承载机密的控制平面:仅限私有网络,置于经认证的入口之后。该生态中绝大多数快速跟进的利用都针对暴露的实例。
  • 对“配置”写入强制字段级授权。 凡用户输入会设置 user_roleallowed_routes、团队归属或策略元数据之处,都应作为仅限管理员的操作来把关,而非普通更新。审计所有密钥/用户写入处理器。
  • 隔离或禁用“自定义代码”护栏。 以最小权限运行代理,置于无主机磁盘或 shell 访问(除非确属必需)的容器中,使 exec() 逃逸带给攻击者的收益尽可能小。
  • 监控工具调用与出站流量。 对自助式角色变更、以宽泛 allowed_routes 创建的虚拟密钥,以及网关的异常出站流量发出告警。被攻陷并操纵智能体的网关,会表现为意料之外的工具调用。

状态

CVE类别影响修复版本
CVE-2026-47101授权绕过虚拟密钥上的越权 allowed_routesv1.83.14-stable(整条链)
CVE-2026-47102权限提升/user/update 自我提升为 proxy_admin受影响:< 1.83.10
CVE-2026-40217护栏沙箱逃逸exec() 实现服务器端代码执行护栏修复已发布;v1.83.14-stable
CVE-2026-42271(单独)MCP 测试端点注入RCE;已列入 CISA KEV1.83.7

正确的定性不是“又一个 LiteLLM RCE”,而是:AI 网关如今已是承载执行的控制平面,而它的若干权限边界却被当作普通数据字段来实施。请修补这条链,轮换它可能触及的一切,并把每一次设置角色或路由的写入都当作其本应是的授权决策来对待。

Sources