LiteLLM AI网关漏洞链：低权限账户可接管服务器并泄露密钥

Obsidian 安全研究人员披露，通过串联三个漏洞，LiteLLM 代理上的默认低权限账户可提升至完全管理员权限并在服务器上执行代码。

LiteLLM 是一款广泛部署的开源 AI 网关，通过兼容 OpenAI 的单一接口代理调用 100 多个模型提供商的服务。服务器被接管将暴露其持有的所有提供商密钥、用于解密存储凭据的密钥，以及流经该网关的所有提示词和响应。

Obsidian 评定该完整漏洞链的 CVSS 评分为 9.9（严重级别）。维护方 BerriAI 已在 LiteLLM v1.83.14-stable 版本中完整修复该问题（GitHub 显示该版本发布于 5 月 2 日），建议用户升级至此版本或更高版本以修复这三个 CVE 漏洞。

一、三个漏洞详情

首个漏洞（CVE-2026-47101）是授权绕过问题。当普通用户（internal_user）生成虚拟 API 密钥时，LiteLLM 会直接存储调用者提供的 allowed_routes 字段，而不根据用户角色进行校验。该字段本应用于限制密钥权限，但代理却将其视为备用授权——非管理员用户可创建包含通配符 ["/*"] 的密钥，从而访问包括管理员专属路由在内的所有路径。由于其他密钥管理端点也存在相同缺陷，修复该问题共需合并三个拉取请求。

绕过路由限制后，攻击者可访问多个未实施二次校验的处理程序，进而触发以下两个漏洞：

其一是权限提升漏洞（CVE-2026-47102）。/user/update 端点允许用户编辑自身记录，但未限制可修改字段。攻击者通过提交包含 user_role: "proxy_admin" 的自更新请求即可获得完整代理管理员权限。组织管理员（org_admin）可通过合法路径触发此漏洞，而默认内部用户（internal_user）需先利用 CVE-2026-47101 漏洞。漏洞评级机构 VulnCheck 给出的 CVSS 4.0 评分为 8.7，CVSS 3.1 评分为 8.8。

其二是 Custom Code Guardrail 功能中的沙箱逃逸漏洞（CVE-2026-40217）。该功能会编译执行管理员提供的 Python 代码，但生产环境端点直接通过 exec() 运行代码且未实施源码级过滤。当 exec() 获取的 globals 字典不含 __builtins__ 时，Python 会隐式注入完整内置模块，使攻击代码获得 __import__、open 和 eval 等危险函数。通过调用 os.system 的简单载荷即可实现反向 Shell。你是否想过，这样一个看似安全的“自定义护栏”功能，竟然成了攻击者直接拿下服务器的跳板？此外，X41 D-Sec 独立发现的 /guardrails/test_custom_code 端点漏洞，可通过运行时字节码重写绕过正则表达式黑名单限制，最终同样导致服务器端代码执行。

二、攻击者能获取哪些信息

作为关键枢纽节点，被攻陷的 LiteLLM 网关将暴露主密钥、用于解密存储凭据的盐密钥及数据库 URL，同时泄露所有已配置的提供商密钥（包括 OpenAI、Anthropic、Gemini、Bedrock、Azure 等）。配置或环境变量中的密钥以明文存储，数据库中的密钥虽经加密但可通过盐密钥还原。所有流经网关的提示词和响应均会被窃取，实际部署环境中这些数据通常包含 PII 信息、源代码、内部票据和粘贴的密钥等敏感内容。

若代理同时作为模型上下文协议（MCP）或 Agent 网关运行，OAuth 令牌和工具凭证也将面临风险。更严重的威胁在于攻击者不仅能窃取数据，还能篡改 AI 模型返回的响应。Obsidian 演示了通过被入侵代理路由 Claude Code 时，攻击者利用 LiteLLM 内置回调机制（该机制在每个请求时触发且不会显示在管理界面中），将模型响应替换为伪造的工具调用，并重写安全检查上下文使操作显示为已批准状态。演示中开发者仅输入“hello”一词，攻击者便在其机器上弹出反向 Shell。这就意味着，你以为只是测个简单的问候词，对手可能已经悄悄端掉了你的开发环境。

值得注意的是，即使不考虑漏洞链，proxy_admin 角色本身也拥有代码执行能力：MCP 支持功能允许管理员注册 stdio MCP 服务器，代理会将其作为本地子进程启动。这属于设计权衡而非漏洞，因此获取管理员权限实质上等同于获得代码执行能力。Obsidian 在 v1.88.0 版本中通过此方式复现了反向 Shell 攻击。此外，同一 stdio-MCP 机制中的真实漏洞（CVE-2026-42271）允许调用者通过 LiteLLM 的 MCP 预览端点生成子进程，该漏洞已被野外利用并于本月被列入 CISA 的已知 exploited 漏洞目录。

这并非 LiteLLM 今年首次出现安全问题：3 月其 PyPI 发布的两个版本遭供应链攻击植入后门；4 月披露的关键 SQL 注入漏洞在 36 小时内即遭利用。Obsidian 强调本次漏洞链目前仅作为概念验证披露，尚未发现野外利用案例，但该代理的关键位置使其持续成为攻击目标。

三、修复建议

立即升级至 v1.83.14-stable 或更高版本（首个包含完整修复的版本），并执行以下操作：

1. 重新审计所有持有 proxy_admin 权限的账户，该角色应视为主机级访问权限
2. 检查代理上所有 Custom Code Guardrail 配置
3. 审查 config.yaml 中 litellm_settings.callbacks 加载的回调函数（这些内容不会显示在控制台且是攻击者隐藏后门的理想位置）
4. 不仅检查配置还需验证部署代码的完整性
5. 若怀疑存在泄露，立即轮换提供商密钥、数据库凭证及所有存储的 MCP 令牌

需特别警惕：被入侵的代理不仅是数据泄露源，更可篡改 Agent 与模型间的通信数据。该漏洞链的根源在于各层级信任机制的失效——路由网关信任了调用者提供的字段、处理程序信任了路由网关的校验，而实际上没有任何环节实施有效验证。

参考来源：LiteLLM Vulnerability Chain Lets Low-Privilege Users Take Over AI Gateway Servers