LiteLLM 漏洞链让低权限用户接管 AI 网关服务器

Obsidian Security 的研究人员披露，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 字段，而不检查该字段是否与用户角色匹配。

该字段本应限制密钥的可用范围。然而，代理也将其视为回退授权，因此非管理员可以生成一个密钥，这是一个通配符，可访问所有路由，包括仅限管理员的路由。同样的未检查写入问题也出现在其他密钥管理端点上，这就是为何修复需要三个 pull request 才能完成。

绕过路由门禁后，其背后的处理程序变得可访问。其中一些处理程序假设门禁已经完成了筛选，这打开了两个攻击路径。

其一是 CVE-2026-47102，权限提升漏洞。/user/update 端点允许用户编辑自己的记录，但未限制其可以写入哪些字段。包含 user_role: "proxy_admin" 的自我更新会被接受并保存，从而将调用者提升为完全代理管理员。org_admin 可通过合法、预期的代码路径直接访问此端点，无需绕过；而默认的 internal_user 在利用 CVE-2026-47101 后也可到达此端点。

分配该 CVE 的 VulnCheck 将其 CVSS 4.0 评分定为 8.7，CVSS 3.1 评分为 8.8。

另一个是 CVE-2026-40217，自定义代码防护栏中的沙箱逃逸漏洞，该防护栏用于编译和执行管理员提供的 Python 代码。

攻击者能获得什么

LiteLLM 处于一个关键瓶颈位置，因此影响范围很广。完整的漏洞链会暴露主密钥、用于解密存储凭证的盐密钥以及数据库 URL。它还会暴露所有已配置的提供商密钥，包括 OpenAI、Anthropic、Gemini、Bedrock、Azure 等。

配置文件或环境变量中的密钥是明文形式；数据库中的密钥是加密的，但可以通过盐密钥恢复。所有通过网关传输的内容（提示和响应）都变得可读，而在实际部署中，这些内容通常包含 PII、源代码、内部工单和粘贴的秘密信息。

如果该代理还作为 Model Context Protocol (MCP) 或代理网关运行，OAuth 令牌和工具凭证也在攻击范围内。

更严重的风险不在于攻击者能读取什么，而在于他们能改写什么。网关位于 AI 代理和模型之间的通信链路上，因此被攻破后，攻击者可以在传输过程中篡改响应。

Obsidian 针对通过被攻破代理路由的 Claude Code 演示了这一点。这不是提示注入。攻击者不是说服模型行为不当，而是利用 LiteLLM 内置的回调机制（一个在每个请求上触发且从未在管理 UI 中显示的扩展点）。该回调将模型的响应替换为伪造的工具调用，并重写安全检查上下文，使该操作显示为已批准。

在演示中，开发者输入了一个词 "hello"，攻击者就在开发者的机器上弹出了反弹 shell。

与漏洞链无关的是，LiteLLM 向 proxy_admin 提供了一个有意的代码执行路径：其 MCP 支持允许管理员注册 stdio MCP 服务器，代理会将其作为本地子进程启动。这是一个设计权衡而非漏洞，补丁也未改变这一点，因此获得管理员权限实际上就等于获得代码执行能力。

Obsidian 在 v1.88.0 版本上以这种方式复现了反弹 shell。同一 stdio-MCP 机制中的一个真实漏洞 CVE-2026-42271，允许调用者通过 LiteLLM 的 MCP 预览端点生成子进程；该漏洞已在野外被利用，并于本月早些时候被添加到 CISA 的 KEV 目录中。

这些都不是 LiteLLM 今年第一次遭遇困境。3 月，一次供应链攻击在 PyPI 上的两个 LiteLLM 版本中植入了后门；4 月，一个严重的 SQL 注入漏洞在披露后 36 小时内就被利用。

Obsidian 将此漏洞链描述为已披露的漏洞并附有可用的演示，而非在野外观察到的利用，但代理的位置使其不断成为攻击目标。

应对措施

升级到 v1.83.14-stable 或更高版本，这是第一个包含完整修复方案的版本。然后进行审计。重新验证每个持有 proxy_admin 权限的账户，并将该角色视为主机级访问权限。审查代理上的每个自定义代码防护栏。

检查从 config.yaml 中加载的回调，因为这些回调从不在控制台中显示，正是攻击者在获得 RCE 后会隐藏的地方。验证已部署代码的完整性，而不仅仅是配置。如果怀疑已被暴露，请轮换提供商密钥、数据库凭证以及所有存储的 MCP 令牌。

被攻破的代理不仅仅会泄露数据。它位于代理和模型之间，可以伪造代理据此执行操作的响应。让攻击者达到这一目的的漏洞链，是每一层都存在错误信任：路由门禁信任了调用者提供的字段，处理程序信任了路由门禁，而实际上没有人真正进行检查。