FlawOpen

flawopen.com/AI Security/litellm-mcp-preview-command-injection-cve-2026-42271

● CVE-2026-42271 · CVSS v4 8.7[1] · 高危
安全研究 · FlawOpen

LiteLLM MCP 命令注入：CVE-2026-42271

GTIG 确认 CVE-2026-42271 遭到利用：有效的 LiteLLM 密钥可通过 MCP 预览功能执行命令。请升级至 1.83.7 或更高版本。[1], [6], [8]

CVSS 向量CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:N/SA:N[1]
💡 通俗易懂的原理解析 (ELI5)

工坊允许访客在登记工具前先试用。预览台可以启动工坊里的强力机器，因此只有主管才应向它发出指令。在存在漏洞的 LiteLLM 版本中，任何被接受的门禁卡都能到达预览台。另一个独立的 Starlette 漏洞还可能欺骗依据重建 URL 判断访问权限的门卫；这两个边界必须分别修复。 在另一个窗口，访客可以在包裹标签上写入斜杠或问号。工作人员重建地址时把这段文字粘进去，并将其误读为一条新路线，但包裹仍沿原来的走廊投递。这对应 Starlette 中独立的 Host 与路径混淆。[1], [3], [5]

核心概念与专有名词

Model Context Protocol (MCP)
一种协议，使 AI 网关等应用能够连接外部工具和数据源。LiteLLM 的预览端点会在保存配置前测试 MCP 服务器配置。[1]
stdio 传输
一种 MCP 连接模式，会在本地启动子进程，并通过标准输入和标准输出交换消息。该进程在 LiteLLM 代理主机上以代理服务的操作系统权限运行。[1], [2]
基于角色的授权
服务器端检查，仅允许具备所需角色的身份执行操作。CVE-2026-42271 中，预览路由缺少保存操作所使用的 PROXY_ADMIN 检查。[1], [2]
CVE-2026-48710（Starlette BadHost）
独立的 Starlette 漏洞：无效 Host 请求头可能导致 request.url.path 与路由实际使用的路径不同。Horizon3 报告称，在某些依赖组合中，这可能绕过 LiteLLM 的基于路径认证；它不属于 CVE-2026-42271。[3], [5], [4]
MCP stdio 命令允许列表
LiteLLM 在 stdio 传输中接受的可执行文件 basename 集合。它会在配置验证时检查，并在创建客户端前再次检查旧记录。它不是沙箱，因为允许的运行时可能会解释传入参数。[8]

框架映射

攻击执行流程分解

步骤 1

确认 LiteLLM 版本和端点暴露情况

维护者公告指出，受影响版本为 LiteLLM >=1.74.2 且 <1.83.7，利用需要有效的代理 API 密钥；修复前，任何已认证密钥持有者（包括低权限内部用户密钥）都能访问预览路由。GTIG 将 CVE-2026-42271 列入确认遭利用清单；判断此 CVE 的前提条件时，应采用维护者公告所述的已认证威胁模型。[1], [6]

步骤 2

低权限密钥可访问管理级预览操作

端点接受完整的 MCP 服务器配置，包括 stdio 命令、参数和环境变量。服务器验证了密钥，却没有检查 PROXY_ADMIN 角色，因此任何已认证密钥持有者都能调用预览操作。[1]

步骤 3

预览操作在代理主机上启动进程

为了测试提交的 stdio 配置，LiteLLM 会创建 MCP 客户端，并以代理服务权限启动所配置的子进程。这是在网关主机上执行命令，而不只是 AI 模型返回了不安全文本。[2], [8]

步骤 4

另一个 Starlette 漏洞可能削弱认证边界

Horizon3 报告称，在存在受影响 Starlette 版本时，CVE-2026-48710 可能使基于路径的认证看到与 Starlette 选中路由不同的 request.url.path。研究人员称，他们将其与 CVE-2026-42271 串联，在受影响部署中移除了 API 密钥前提。应将此攻击链归因于研究人员；两个 CVE 的根因和补丁各不相同。[5], [3], [4]

步骤 5

修补两个边界并核验实际解析的依赖

LiteLLM 1.83.7 修复了预览路由：现在要求 PROXY_ADMIN，且 tools/list 有显式身份验证。补丁还会在新建/更新请求中检查命令允许列表，并在 _create_mcp_client 中再次检查以覆盖旧配置。允许列表不是沙箱；允许的运行时仍会解释参数。Starlette 在 1.0.1 中单独修复了 CVE-2026-48710；请检查实际解析出的依赖组合，并独立评估所报告的攻击链。[1], [8], [4], [7]

步骤 6

近期攻击活动背景（2026 年 10 月 7 日报道）

Black Lotus Labs 报告称，PoeLLM 恶意软件样本可能针对 /mcp-rest/test/connection；BleepingComputer 也报道了该活动尝试利用 CVE-2026-42271。报告并未证明所有感染主机都是通过此 CVE 遭到入侵，也未证明所有 LiteLLM 目标都存在漏洞。应将其视为当前攻击目标的证据，而非可归因于此漏洞的受害者数量。[9], [10]

根本原因剖析 (Root Cause)

LiteLLM 的问题是在两个 MCP 预览路由上缺少角色检查：任何有效的代理 API 密钥都能在没有 PROXY_ADMIN 角色的情况下调用它们。连接预览接口接受调用方提供的 stdio 配置，并以代理进程的权限启动其中的命令。另一个独立的 Starlette 漏洞允许格式错误的 Host 标头导致 request.url.path 与 Starlette 实际路由的路径不一致；Horizon3 报告称，将此行为与 LiteLLM 组合后，基于路径的 API 密钥校验可能被绕过。这是两个不同的漏洞：应分别修复 LiteLLM 的授权和命令执行边界，并将 Starlette 更新到 1.0.1 或更高版本。[1], [8], [3], [4], [5]

源代码对比：漏洞与安全实现

此代码片段对应 LiteLLM 已合并的执行边界修复：创建 stdio 客户端前先检查命令 basename，因此旧数据库/配置记录也会经过该检查。补丁还会验证新建和更新的服务器配置，并将两个预览端点限制为 PROXY_ADMIN；/test/tools/list 也增加了显式 user_api_key_auth 依赖。允许列表不是沙箱：允许的运行时仍可能解释其参数。预览功能应仅限管理员，并以最小权限运行代理。[1], [2], [8]

源码摘录: LiteLLM stdio 客户端校验代码片段

存在漏洞的实现
# _create_mcp_client：添加 stdio 命令防护前的实现。
if server.command and server.args is not None:
    stdio_config = MCPStdioConfig(
        command=server.command,
        args=server.args,
        env=resolved_env,
    )
加固后的安全修复
# _create_mcp_client：对数据库/配置中的旧记录再次执行校验。
if server.command:
    base_command = os.path.basename(server.command)
    if base_command not in MCP_STDIO_ALLOWED_COMMANDS:
        raise HTTPException(
            status_code=403,
            detail="MCP stdio command is not in the allowlist",
        )

if server.command and server.args is not None:
    stdio_config = MCPStdioConfig(
        command=server.command,
        args=server.args,
        env=resolved_env,
    )

工程与系统安全加固清单

参考来源

← AI Security Directory →