LiteLLM 三漏洞链可致低权用户接管服务器

Obsidian Security 的研究人员披露，LiteLLM proxy 上的默认低权限账户可以通过串联三个漏洞，提升到完整 admin 权限并在服务器上运行代码。

LiteLLM 是一个广泛部署的开源 AI gateway，它通过一个与 OpenAI 兼容的接口，代理对 100 多个 model provider 的调用。

服务器被接管后，会暴露其持有的每个 provider key、用于解密已存储凭据的密钥，以及经过它的每个 prompt 和 response。

Obsidian 将完整链条的评分定为 CVSS 9.9，属于 Critical。维护方 BerriAI 已在 LiteLLM v1.83.14-stable 中包含完整修复集，GitHub 显示其发布时间为 5 月 2 日。升级到该版本或更高版本即可关闭这条三 CVE 链。

这三个漏洞

第一个环节是 CVE-2026-47101，这是一个 authorization bypass。 当普通用户（internal_user）生成 virtual API key 时，LiteLLM 会存储调用者提供的 allowed_routes 字段，而不会根据用户角色检查它。

该字段本应限制 key 能做什么。 但 proxy 还把它当作兜底授权，因此非 admin 可以创建一个带有 allowed_routes: ["/*"] 的 key，这是一个可覆盖所有路由的通配符，包括仅限 admin 的路由。 同样未检查的写入也出现在其他 key management endpoint 上，这也是修复最终需要通过三个 pull request 才落地的原因。

在绕过 route gate 之后，其后的 handler 也变得可访问。 其中一些 handler 假定 gate 已经完成筛查，这就打开了两条路径。

其一是 CVE-2026-47102，这是 privilege escalation。 /user/update endpoint 允许用户编辑自己的记录，但不限制可写入的字段。 通过自我更新写入 user_role: "proxy_admin" 会被接受并保存，从而把调用者提升为完整 proxy admin。 org_admin 可以通过一条合法、设计内的代码路径访问该 endpoint，无需任何绕过；默认的 internal_user 则会在 CVE-2026-47101 之后到达这里。

为该 CVE 赋值的 VulnCheck 按 CVSS 4.0 评分为 8.7，按 3.1 评分为 8.8。

另一条是 CVE-2026-40217，这是 Custom Code Guardrail 中的 sandbox escape。 该组件会编译并运行管理员提供的 Python。 生产端点使用 exec() 运行代码，且没有进行源码级过滤。 当 exec() 获得一个不含 __builtins__ 的 globals dict 时，Python 会静默注入完整的 builtins module，从而让代码获得 __import__、open 和 eval。 因此，一个只调用 os.system 的普通 payload 就足以拿到 reverse shell。

X41 D-Sec 独立发现的另一条路径位于 /guardrails/test_custom_code playground endpoint，它通过运行时 bytecode 重写绕过了 regex deny-list。 两条路径最终都导向服务器端代码执行。

攻击者能得到什么

LiteLLM 位于关键枢纽位置，因此影响范围很大。 完整链条会暴露 master key、用于解密已存储凭据的 salt key，以及 database URL。 它还会暴露所有已配置的 provider key，包括 OpenAI、Anthropic、Gemini、Bedrock、Azure 以及其他服务。

配置文件或环境变量中的密钥是明文；数据库中的密钥虽已加密，但可借助 salt key 恢复。 经过网关传输的一切内容，包括 prompts 和 responses，都会变得可读，而在真实部署中，这些地方往往包含 PII、source code、internal tickets 以及粘贴进去的 secrets。

如果 proxy 同时运行作为 Model Context Protocol（MCP）或 agent gateway，OAuth tokens 和 tool credentials 也在影响范围内。

更严重的风险不是攻击者读到了什么，而是他们能改写什么。 该 gateway 位于 AI agent 与 model 之间的链路上，因此一旦被攻陷，就能篡改传输中的 response。

Obsidian 演示了这一点：通过一个被攻陷的 proxy 转发 Claude Code。 这不是 prompt injection。 攻击者并不是通过说服 model 误行为，而是利用 LiteLLM 内建的 callback mechanism，这是一种在每个 request 上触发、且不会出现在 admin UI 中的 extension point。 该 callback 会把 model 的 response 替换成伪造的 tool call，并重写 safety-check context，使该动作看起来像已获批准。

在演示中，开发者只输入一个单词 hello，攻击者就会在开发者机器上弹出 reverse shell。

除了这条链之外，LiteLLM 还给 proxy_admin 提供了一条有意设计的代码执行路径：其 MCP support 允许 admin 注册 stdio MCP servers，由 proxy 作为本地 subprocess 启动。 这是一种设计取舍而不是 bug，而且这些补丁不会改变这一点，因此拿到 admin 实际上就等同于拿到 code execution。

Obsidian 在 v1.88.0 上复现了这种 reverse shell。 同一套 stdio-MCP 机制中还存在一个真实漏洞 CVE-2026-42271，它允许调用者通过 LiteLLM 的 MCP preview endpoints 启动 subprocess；该漏洞已在野外被利用，并在本月早些时候被加入 CISA 的 KEV catalog。

这并不是 LiteLLM 今年第一次出问题。 3 月，一起 supply-chain compromise 在 PyPI 上给两个 LiteLLM 版本植入了后门；4 月，一个 critical SQL injection 在披露后 36 小时内就被利用。

Obsidian 将这里的链条描述为一个已披露的缺陷并附带可运行演示，而不是在野外观察到的利用，但 proxy 所处的位置仍使其持续成为攻击目标。

应对措施

升级到 v1.83.14-stable 或更高版本，这是首个包含完整修复集的发布。 然后进行审计。 重新核实每个持有 proxy_admin 的账户，并将该角色视为 host-level access。 检查 proxy 上的每一个 Custom Code Guardrail。

检查 config.yaml 中 litellm_settings.callbacks 下加载的 callbacks，因为这些不会出现在 console 中，也正是 RCE 之后攻击者最可能隐藏的地方。 验证部署代码的完整性，而不只是配置。 如果怀疑已经暴露，应轮换 provider keys、database credentials 以及任何已存储的 MCP tokens。

被攻陷的 proxy 不只是泄露数据。 它位于 agent 与 model 之间，并且可以伪造 agent 将要执行的 response。 让攻击者到达这一位置的链条，是每一层都存在错误的信任：route gate 信任了调用者提供的字段，handler 信任了 route gate，而实际上没有人真正检查。