CVE-2026-42271:LiteLLM MCP 接口命令注入漏洞分析

原创

Ga0Y1u
Ga0Y1u

Ga0Sec碎碎念

2026年6月17日 17:06
浙江

去阅读

一、产品介绍

LiteLLM 是由 BerriAI 开发的开源 AI 网关/代理服务器，目前在 GitHub 上拥有超过 18,000 个 Star。它作为一个统一的中间层，旨在简化对多个大语言模型（LLM）API 的调用管理。通过 LiteLLM，用户可以使用统一的 API 格式（兼容 OpenAI SDK）来调用包括 OpenAI、Anthropic Claude、Google Gemini、Azure OpenAI、AWS Bedrock 等在内的 100+ 种 LLM 服务。

LiteLLM 的核心能力包括：负载均衡、速率限制、成本追踪、API Key 管理、模型回退策略、以及 MCP（Model Context Protocol）服务器集成。它被广泛应用于企业内部 AI 基础设施、AI 初创公司的后端服务，以及各类需要统一管理多个 LLM 提供商调用的场景。

然而，正是其 MCP 服务器集成功能中的设计缺陷，导致了本次严重的安全漏洞。

二、漏洞概述

CVE-2026-42271 是 LiteLLM 中存在的一个命令注入漏洞。该漏洞位于 MCP 服务器的测试端点中，攻击者可以通过构造特定的 HTTP 请求，在 LiteLLM 服务器上执行任意系统命令。2026 年 6 月 8 日，美国 CISA 将该漏洞列入已知被利用漏洞目录（KEV），确认该漏洞已被攻击者在野外积极利用。

更为严重的是，安全公司 Horizon3.ai 的研究人员发现，该漏洞可以与另一个漏洞 CVE-2026-48710（Starlette BadHost Host 头验证绕过）组合利用，将原本需要认证的 RCE 升级为无需任何凭证的未授权远程代码执行，组合漏洞的 CVSS 评分达到 10.0 满分。

三、漏洞成因

3.1 MCP 测试端点的设计缺陷

LiteLLM 的 MCP（Model Context Protocol）功能允许用户配置外部 MCP 服务器，以便将 MCP 工具集成到 LiteLLM 的代理管道中。为了提升用户体验，LiteLLM 提供了两个预览/测试端点：

POST /mcp-rest/test/connection -- 在保存前预览/测试 MCP 服务器连接
POST /mcp-rest/test/tools/list -- 列出 MCP 服务器配置中的可用工具

这两个端点的设计初衷是：接收用户提交的 MCP 服务器配置（JSON 格式），然后尝试连接到该 MCP 服务器以验证配置的正确性。

3.2 危险的 stdio Transport 处理

MCP 协议支持多种传输方式（transport），包括 stdio（标准输入输出）、SSE 和 Streamable HTTP。当 transport 设置为 stdio 时，LiteLLM 需要启动一个本地子进程来与 MCP 服务器通信。问题在于：LiteLLM 会直接使用用户提交的 command 和 args 字段来构造并执行子进程，而对这些字段没有进行任何安全过滤或校验。

3.3 权限控制不足

更糟糕的是，这两个测试端点仅要求请求携带一个有效的 API Key，而不检查该 Key 的权限级别。任何角色的用户（包括最低权限的内部用户）都可以调用这些端点。这意味着，只要攻击者能够获取到任意一个有效的 API Key（甚至可以通过内部调用模式泄露），就能够利用此漏洞执行任意系统命令。

3.4 漏洞根因总结

漏洞的根本原因可以归结为两点：(1) 用户可控的参数（command 和 args）被直接传递给了子进程创建函数，属于典型的 OS Command Injection 模式；(2) 授权检查仅验证了“是否为有效 Key”，而未验证“是否具有管理权限”，导致攻击面被大幅扩大。

四、漏洞复现

4.1 环境准备

目标环境：LiteLLM 1.83.6（受影响版本），使用默认配置启动，Master Key 为 sk-litellm-master-key。攻击者已知该 Master Key（或在现实场景中通过其他方式获取到任意有效 API Key）。(自行使用docker构建)

4.2 攻击步骤

Step 1：发送命令注入请求

向 /mcp-rest/test/tools/list 端点发送 POST 请求，在 JSON body 中设置 transport 为 stdio，并将 command 设置为系统 shell（如 bash），args 包含要执行的命令。下例将 id 命令的输出写入 LiteLLM 的 Swagger 静态资源目录中的一个文本文件：

POST /mcp-rest/test/tools/list HTTP/1.1Host:Content-Type: application/jsonAuthorization: Bearer sk-litellm-master-key
{  \"transport\": \"stdio\",  \"command\": \"bash\",  \"args\": [\"-c\", \"id > /usr/lib/python3.13/site-packages/litellm/proxy/swagger/shell.txt\"]}

服务器收到该请求后，会将 command 和 args 传递给 Python 的 subprocess 模块执行。由于没有任何过滤，bash -c 后面的命令会被完整执行，id 命令的输出被重定向到 LiteLLM 静态文件目录下的 shell.txt 文件中。响应体中可能包含 \"Failed to connect to MCP server\" 错误信息，但此时命令已经执行完成。

Step 2：验证命令执行结果

通过 HTTP GET 访问 Swagger 静态目录下的 shell.txt 文件，获取命令执行结果，如果响应中包含 uid= 字样（Linux 系统下 id 命令的输出特征），即可确认命令执行成功，漏洞存在。

4.3 利用变形

攻击者可以根据目标环境灵活选择命令类型。在 Windows 环境下，可以将 command 设置为 cmd.exe，args 设置为 /c 后跟 Windows 命令（如 ipconfig /all）。在 Linux 环境下，可以使用 bash -c 执行任意命令。此外，如果目标不出网，还可以通过写入 webshell 的方式获取持久化访问。

除了将命令结果写入静态文件外，攻击者还可以使用反向 shell、DNS 外带、curl/wget 回传等方式获取命令输出。对于无回显场景，可以通过写入 webshell 或利用 sleep 时间差进行盲打验证。

4.4 未授权利用链（CVE-2026-42271 + CVE-2026-48710）

Horizon3.ai 披露的漏洞链将 CVE-2026-42271 的危险性推向了极致：

1.利用 CVE-2026-48710（Starlette BadHost 漏洞）：通过构造特殊的 Host 头，绕过 LiteLLM 的路由认证保护，使得原本受保护的 API 端点可以被未经认证的请求访问。

2.Starlette 是 LiteLLM 使用的底层 Web 框架，在 1.0.0 及之前版本中，当 Host 头设置为特定值时（如包含空格或特殊字符），认证中间件可能被绕过。

3.绕过认证后，攻击者即可直接调用 /mcp-rest/test/tools/list 端点执行任意命令，全程无需任何 API Key。

五、漏洞影响

5.1 影响范围

根据网络空间搜索引擎的数据，全球有数千个暴露在公网的 LiteLLM 实例。由于 LiteLLM 常用于承载企业 AI 业务的核心网关，受影响面涵盖了：

·AI 初创公司 -- 使用 LiteLLM 管理多个 LLM 提供商的后端服务

·大型企业 -- 内部 AI 基础设施中的模型路由和 API 管理

·云服务提供商 -- 为客户提供统一 LLM 接入能力的平台

·独立开发者 -- 部署在公网的个人 LiteLLM 实例

5.2 攻击者可以做什么

■ 窃取凭证：获取 LiteLLM 代理中存储的所有 LLM 提供商 API Key（OpenAI、Anthropic、Azure 等），这些凭证可用于滥用付费 API，造成巨额经济损失。

■ 远程控制：在 LiteLLM 服务器上执行任意系统命令，获取服务器的完全控制权。

■ 横向移动：以 LiteLLM 服务器为跳板，渗透内网中连接的其他 AI 基础设施和业务系统。

■ 数据窃取：截获和窃取通过 LiteLLM 转发的所有 LLM 请求和响应内容，其中可能包含企业敏感数据。

■ 持久化驻留：写入 webshell、添加计划任务或 SSH 公钥，实现对服务器的长期控制。

5.3 实际攻击案例

CISA 于 2026 年 6 月 8 日将该漏洞列入 KEV（Known Exploited Vulnerabilities）目录，明确指出已有攻击者在野外积极利用此漏洞。安全厂商已观测到针对暴露在公网的 LiteLLM 实例的扫描和利用行为，攻击者可能会利用已攻陷的实例进行挖矿、搭建代理节点或作为进一步攻击的跳板。

六、修复建议

6.1 立即升级（推荐）

LiteLLM 1.83.7 修复了权限控制问题：两个 MCP 测试端点现在要求调用者具有 PROXY\_ADMIN 角色，而非任意有效 Key。Starlette 1.0.1 修复了 BadHost 绕过漏洞。

6.2 临时缓解措施

如果暂时无法升级，建议采取以下临时措施：

·在反向代理或 API 网关上阻止对 POST /mcp-rest/test/connection 和 POST /mcp-rest/test/tools/list 的访问

·将 LiteLLM 实例限制在内网或可信网络段访问，不要暴露在公网

·轮换 LiteLLM 代理中存储的所有 API Key 和凭证

·审计日志，排查异常的 Host 头值和子进程执行记录

·启用 WAF 规则，检测针对这两个端点的恶意请求

七、总结

CVE-2026-42271 是一个典型的「用户输入直接传递至系统命令执行」类的漏洞。在设计 API 端点时必须坚守以下安全原则：

1. 永远不要信任用户输入 -- 任何来自客户端的数据在传递给系统级函数前，都必须经过严格的校验和过滤。
2. 最小权限原则 -- 敏感操作（如 MCP 服务器测试）应该有严格的权限控制，而非仅依赖简单的认证检查。
3. 纵深防御 -- 即使单点防御被突破（如认证绕过），多层安全机制仍然能够阻止完整的攻击链。
4. 及时响应与升级 -- 漏洞从披露到被列入 CISA KEV 仅用了不到两个月，攻击者的反应速度远超许多企业的补丁周期，安全团队需要建立快速响应机制。

对于 AI 基础设施的运维者而言，本次漏洞也是一个重要的警示：AI 网关和代理服务器正成为攻击者的高价值目标。LiteLLM 承载着通往多个 LLM 提供商的“万能钥匙”，一旦被攻陷，损失远不止于单台服务器的失陷。建议所有使用 LiteLLM 的用户立即检查版本并采取相应的安全措施，以保护企业和用户的数据安全。

参考资料

1. GitHub 官方安全公告:

https://github.com/BerriAI/litellm/security/advisories/GHSA-v4p8-mg3p-g94g
2. NIST NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-42271
3. Horizon3.ai 漏洞链分析 (CVE-2026-42271 + CVE-2026-48710)

本文仅用于安全研究和防御目的，请勿将文中技术用于非法用途。