从低权限 Key 到 AI Gateway 接管：LiteLLM 漏洞链完整剖析

一、摘要

近日，LiteLLM 被披露存在多处高危安全风险。我们在授权本地环境中对相关漏洞进行了复现验证，确认攻击者在获取低权限用户凭据后，可能沿着“虚拟 Key 路由权限绕过 → 用户角色提升 → 管理面接管 → MCP / Guardrail 执行面扩展”的路径，逐步扩大对 LiteLLM AI Gateway 的控制能力。

LiteLLM 常作为企业统一大模型 API 网关使用，位于业务应用、Agent 编排层与 OpenAI、Anthropic、Gemini、Azure OpenAI、Bedrock、私有模型等模型服务之间，集中承载模型路由、API Key 管理、用户与团队权限、成本控制、审计、MCP 工具和 Guardrail 等能力。一旦 LiteLLM 网关被接管，攻击者可能进一步触达模型 API Key、数据库连接凭据、OAuth Token、MCP 工具凭据、提示词、模型响应和 Agent 工作流，影响范围不再局限于单个接口，而可能扩展到整条企业 AI 调用链。

本次重点关注以下 4 个漏洞：

二、漏洞背景：LiteLLM 在企业 AI 栈中的位置

LiteLLM 并不是一个普通业务系统，而是企业 AI 应用栈中的基础设施组件。它通常部署在业务应用、Agent 编排层和上游模型服务商之间，承担统一网关的角色。

image.10.png

从安全视角看，LiteLLM 同时具备三类高价值属性：

• 控制面价值高，掌握用户、团队、路由、模型、Key 和预算等管理能力；
• 数据面价值高，可能经过提示词、模型响应、上下文、审计日志和工具调用结果；
• 执行面价值高，MCP、Guardrail、自定义回调、Pass-through 等能力连接外部系统或本地执行环境。

因此，本次漏洞的核心风险不是“某个接口返回 200”，而是低权限凭据可能被用于撬动 AI Gateway 的控制面与执行面，形成可串联的攻击链。

三、漏洞要点

3.1 CVE-2026-47101：通配路由授权绕过

LiteLLM 支持通过 allowed_routes 限制虚拟 Key 能访问的接口范围。受影响版本中，服务端对低权限调用者申请高权限路由缺少充分校验，导致普通用户可创建覆盖管理面的路由 Key。

3.2 CVE-2026-47102：字段级权限缺失导致角色提升

/user/update 原本用于用户信息更新，但受影响版本未严格限制可修改字段。在攻击者已经获得 /user/update 访问能力的情况下，可尝试将自身 user_role 修改为 proxy_admin。该漏洞的关键不是“能访问接口”，而是“可写字段无权限隔离”。

3.3 CVE-2026-42271：MCP 测试端点触发服务端执行行为

MCP 测试端点用于验证 MCP Server 连接，但受影响版本允许低权限用户提交 stdio 类型配置，并由 LiteLLM 服务端按配置创建临时 MCP Client。

3.4 CVE-2026-40217：Guardrail 自定义代码沙箱绕过

Guardrail 自定义代码测试接口会编译并执行用户提交的代码。受影响版本依赖手写黑名单过滤危险特征，例如 import、__builtins__ 等明文关键字。公开 PoC 和本地验证均表明，基于字节码、对象反射或字符串拼接等方式可绕过该过滤逻辑。

四、攻击链还原：从低权限 Key 到 Gateway 接管

本次漏洞最值得关注的是“可串联性”。单个漏洞已经具备较高风险，多个漏洞组合后，攻击路径会从普通 API 权限问题升级为 AI Gateway 控制面和执行面接管。

image.11.png

攻击链的关键变化如下：

换句话说，攻击者不需要直接攻击大模型本身，只要控制模型网关，就可能间接影响模型调用、工具调用和下游 Agent 工作流。

五、漏洞复现

5.1 测试环境

5.2 复现结果摘要

5.3 复现截图

CVE-2026-47102：/user/update 角色提升

低权限用户访问用户管理接口返回未授权：

具备 /user/update 路由访问能力后，尝试修改自身角色：

角色提升后，原始用户 key 可访问用户管理接口。

CVE-2026-47101：通配 route key 越权

低权限用户创建 wildcard route key：

使用 wildcard key 访问管理员接口。

CVE-2026-42271：MCP REST 测试端点服务端触发

低权限 key 调用 MCP REST 测试端点：

服务端侧触发测试行为 / callback 命中：

CVE-2026-40217：Guardrail 自定义代码沙箱绕过

/guardrails/test_custom_code 返回沙箱绕过验证结果。

六、影响与 AI 供应链洞察

6.1 潜在影响

若攻击者成功利用上述漏洞链，可能造成：

• 接管 LiteLLM 管理权限；
• 创建、删除或篡改用户、团队、虚拟 Key 和模型路由；
• 获取或滥用上游模型服务商 API Key；
• 接触数据库连接串、Salt Key、OAuth Token、MCP 工具凭据等敏感信息；
• 读取或影响经过网关的提示词、模型响应和审计日志；
• 通过 MCP 或 Guardrail 相关能力进一步扩展到服务端执行面；
• 劫持企业内部 AI Agent、自动化工作流或工具调用链路。

6.2 为什么这对 AI 基础设施致命

传统 Web 漏洞通常影响某个业务接口，而 AI Gateway 漏洞影响的是“模型调用入口”。在企业 AI 架构中，LiteLLM、vLLM、Ollama、ModelScope 等组件构成 AI 基础设施核心。

这些组件具备共同特征：

本次 LiteLLM 漏洞链说明：攻击者不一定需要直接攻破大模型本身，也不一定需要突破业务后端。只要掌握 AI 调用链中的网关组件，就可能间接控制模型访问、工具调用和 Agent 行为。

七、排查・修复・检测规则

7.1 版本排查

检查 LiteLLM 版本：

litellm --version

或检查 Python 包版本：

python -m pip show litellm

建议统一升级至：

LiteLLM >= v1.83.14-stable

升级后建议重新验证：

• 低权限用户无法创建 allowed_routes=[“/*”] 的 Key；
• 非管理员无法通过 /user/update 修改 user_role；
• 低权限用户无法访问 /user/list 等管理接口；
• 低权限用户无法访问 MCP 测试端点，或无法提交 stdio 命令类配置；
• Guardrail 自定义代码测试能力不再依赖可绕过的手写正则沙箱。

7.2 Key 与角色排查

重点检查虚拟 Key 中是否存在异常路由配置：

allowed_routes = [“/*”]
allowed_routes 包含 /user/*
allowed_routes 包含 /key/*
allowed_routes 包含 /guardrails/*
allowed_routes 包含 /mcp-rest/*

重点关注异常角色变化：

internal_user -> proxy_admin
internal_user_viewer -> proxy_admin
普通用户短时间内调用 /user/update 后角色发生变化

如发现低权限用户创建了包含管理接口或通配符的 Key，应立即禁用并追踪来源。

7.3 日志排查

建议搜索以下敏感接口访问记录：

POST /key/generate
POST /user/update
GET /user/list
POST /mcp-rest/test/connection
POST /mcp-rest/test/tools/list
POST /guardrails/test_custom_code

重点关注连续行为链：

/key/generate -> /user/update -> /user/list
/key/generate -> /mcp-rest/test/connection
/key/generate -> /guardrails/test_custom_code

7.4 修复与加固

7.5 自研检测规则建议

可基于 HTTP 日志、网关日志、审计日志和数据库变更记录增加如下检测逻辑：

规则 1：低权限用户调用 POST /key/generate 且请求体包含 allowed_routes
规则 2：allowed_routes 包含 /*、/user/*、/key/*、/guardrails/*、/mcp-rest/*
规则 3：POST /user/update 请求体包含 user_role=proxy_admin
规则 4：非管理员 Key 调用 /user/update 并修改 user_role 字段
规则 5：同一用户短时间内连续出现 /key/generate、/user/update、/user/list
规则 6：低权限用户访问 /mcp-rest/test/connection 或 /mcp-rest/test/tools/list
规则 7：MCP 测试请求中出现 transport=stdio、command、args、env 字段
规则 8：访问 /guardrails/test_custom_code 且 custom_code 出现对象反射、字节码、dunder 字符串拼接等高危特征
规则 9：非管理员用户短时间内创建多个虚拟 Key 或修改多个路由范围
规则 10：LiteLLM 进程出现异常外联、异常子进程或未知 MCP 工具注册行为

我们已基于本地复现链路沉淀自研检测规则，可用于 LiteLLM 相关访问日志、网关日志和主机行为日志的威胁狩猎与持续监测。如有需要，可进一步提供 AI 基础组件漏洞情报监测与风险排查服务。

7.6 应急处置建议

如发现疑似利用行为，建议按以下顺序处置：

• 立即限制 LiteLLM 管理端访问入口；
• 导出并留存访问日志、数据库审计记录和配置文件；
• 禁用异常用户、异常虚拟 Key 和异常 route key；
• 恢复被异常提升的用户角色；
• 升级 LiteLLM 至修复版本；
• 轮换可能泄露的模型 API Key、数据库凭据、OAuth Token 和 MCP 工具凭据；
• 排查主机是否存在异常进程、计划任务、反连行为或新增文件；
• 对接入 LiteLLM 的下游 AI Agent、MCP 工具和自动化工作流做完整性检查。

八、参考

参考链接

• LiteLLM 官方项目：https://github.com/BerriAI/litellm
• LiteLLM 修复版本：https://github.com/BerriAI/litellm/releases/tag/v1.83.14-stable
• VulnCheck Advisory：https://www.vulncheck.com/advisories/litellm-privilege-escalation-via-api-key-generation
• Huntr 漏洞信息：https://huntr.com/bounties/8e75edfb-ff05-4e63-bfca-2d93d03fb3b9

关于我们

本文由云鼎实验室基于团队漏洞情报能力与授权本地复现验证整理。团队主要聚焦 AI 基础设施、AI Agent、MCP 生态、模型网关、AI 组件供应链等方向的安全研究与漏洞情报分析。

图片

END

更多精彩内容点击下方扫码关注哦~

关注云鼎实验室，获取更多安全情报

图片