MCP 命令注入实战拦截：3 个真实 CVE + 一个检测 DemoMCP 命令注入实战拦截：3 个真实 CVE + 一

MCP 命令注入实战拦截：3 个真实 CVE + 一个检测 Demo

一句话总结（BLUF）：过去两个月里，MCP 服务器暴露了三个真实漏洞——CrewAI stdio RCE（CVSS 9.8）、LiteLLM MCP-REST 命令注入（CVSS 8.7，已被积极利用）、以及 Amazon Q Developer MCP 自动执行漏洞（CVSS 8.5）。三者共享同一个根因：MCP 配置是可执行内容，而不是数据。本文逐一拆解这三个 CVE，然后展示一个可运行的 40 行校验器，它能在这类漏洞随代码发布之前将其拦截。

为什么 MCP 配置是一个信任边界问题

Model Context Protocol（MCP）是 AI Agent 连接工具的方式——文件系统、数据库、浏览器、你的 CI 流水线。协议的 stdio transport 优雅而简单：你的配置文件写着"运行 python ./server.py"，客户端就会照做，把它当作你机器上的一个子进程，带着你的环境运行。

这个设计本身就是漏洞。一个 MCP 配置是可执行内容，但协议中没有任何机制把它当作可执行内容来处理。没有白名单、没有沙箱、没有"这个配置可信吗？"的检查点。一个恶意仓库、一个仿冒包（typosquatted package），或一个往你工作区丢入 MCP 配置的投毒 PR，距离用你的凭据运行任意代码只有一步之遥。

下面这三个 CVE 不是假设。它们就是这种模式，已在真实世界中公开披露。

CVE-2026-2287 — CrewAI MCP StdioTransport RCE（CVSS 9.8）

这是什么：在 CrewAI 中，StdioTransport.__init__() 将用户可控的命令字符串零校验地直接传给 stdio_client()。任何指向恶意命令的 MCP 服务器配置都会触发任意操作系统进程执行。

为什么重要：这是一个主流 Agent 框架——不是冷门工具。漏洞类别是"工具注入（Tool Injection）"：一个 LLM 生成的 tool_call 参数，或一个投毒的配置文件，在没有中间检查的情况下变成了一条 OS 命令。

状态：已披露给 MSRC（Case 126356），公开跟踪编号为 CVE-2026-2287。

CVE-2026-42271 — LiteLLM MCP-REST 命令注入（CVSS 8.7，已被积极利用）

这是什么：LiteLLM 的 AI 网关暴露了 POST /mcp-rest/test/connection 和 POST /mcp-rest/test/tools/list——这些端点本意是在保存 MCP 服务器配置前预览它。它们接受完整配置（包括 command、args、env），并且对于 stdio 配置，会在代理主机上以子进程形式启动传入的命令，且不做任何沙箱隔离。在出现积极利用后，CISA 于 2026 年 6 月 8 日将其加入已知被利用漏洞（Known Exploited Vulnerabilities，KEV）目录。

更糟的是：与 CVE-2026-48710（一个 Starlette Host 头绕过）链式利用后，它会变成无需认证的 RCE，组合 CVSS 高达 10.0——无需任何凭据。野外已观察到利用后的行为：Web shell 安装、凭据窃取、横向移动。

状态：已在 LiteLLM 1.83.7 中修复（测试端点现在需要 PROXY_ADMIN 角色）。如果你运行着 LiteLLM 网关且尚未打补丁，这是一次需要放下手头一切事去执行的升级。

CVE-2026-12957 — Amazon Q Developer MCP 自动执行（CVSS 8.5）

这是什么：Language Servers for AWS（< 1.65.0）会从工作区的 .amazonq/mcp.json 文件中自动加载并执行 MCP 服务器配置——无需用户同意，不做工作区信任验证。被启动的进程继承了开发者的完整环境，暴露了 AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、CLI 认证令牌、API 密钥以及 SSH agent 套接字。

为什么重要：攻击面不是网络服务——而是开发者的编辑器。一个恶意 PR、一个仿冒包，或一个假的求职面试题，往工作区里丢入 .amazonq/ 配置，Amazon Q 就会运行它。

状态：由 Wiz Research 披露（2026 年 4 月 20 日报送；已在 Language Servers 1.65.0 / Amazon Q 2.20 中修复）。

三者背后的共同模式

CVE	触发方式	可执行元素	凭据暴露
CVE-2026-2287（CrewAI）	MCP 配置 / tool_call	`command` 字符串 → `stdio_client()`	完整进程环境
CVE-2026-42271（LiteLLM）	对测试端点的 HTTP 请求	`command` + `args` + `env` → 子进程	所有已存储的 provider 密钥
CVE-2026-12957（Amazon Q）	工作区 `.amazonq/mcp.json`	打开即自动运行 `command`	AWS 凭据、SSH agent

每一个都与命令注入密切相关，每一个都可以通过一个配置时检查来拦截，这个检查问的是：这个 MCP 配置是否在运行危险命令、是否暴露了密钥、或者是否把 stdio 和 env 混在了一起？

一个可运行的检查：CCS `MCPSecurityValidator`

下面是检测逻辑。它是真实的、开放的，运行在一个很小的 Python 类中。安装它：

pip install ccs-verifier

from ccs.guardrail import MCPSecurityValidator

malicious = {
    "name": "file-ops-server",
    "transport": "stdio",
    "env": {"OPENAI_API_KEY": "sk-proj-***"},
    "tools": [
        {
            "name": "purge_all",
            "implementation": 'def purge_all():\n    os.system("rm -rf /data/user/*")',
            "env": {},
        },
        {
            "name": "run_shell",
            "implementation": 'subprocess.call(["bash", "-c", user_cmd])',
            "env": {},
        },
    ],
}

result = MCPSecurityValidator.validate_mcp_config(malicious)
print(result["safe"])  # False

针对一个同时模拟三个 CVE 模式的配置的实际输出：

{
  "safe": false,
  "issues": [
    {
      "severity": "HIGH",
      "type": "stdio_env_exposure",
      "message": "stdio transport with env variables",
      "cve_ref": "CVE-2026-12957",
      "remediation": "Use env_isolation or switch to sse/http transport"
    },
    {
      "severity": "CRITICAL",
      "type": "command_injection",
      "pattern": "rm -rf",
      "cve_ref": "CVE-2026-42271"
    },
    {
      "severity": "CRITICAL",
      "type": "command_injection",
      "pattern": "os.system",
      "cve_ref": "CVE-2026-42271"
    },
    {
      "severity": "CRITICAL",
      "type": "command_injection",
      "pattern": "subprocess.call",
      "cve_ref": "CVE-2026-42271"
    }
  ]
}

干净的配置可以通过：

safe = {
    "name": "reader",
    "transport": "sse",
    "env": {},
    "tools": [{"name": "read", "implementation": "def read(): return open(f).read()", "env": {}}],
}
print(MCPSecurityValidator.validate_mcp_config(safe)["safe"])  # True

校验器标记的内容：

command_injection — rm -rf、curl | sh、wget | bash、eval(、exec(、os.system、subprocess.call（CVE-2026-42271 模式）
env_exposure — 工具 env 中的 API_KEY、SECRET、TOKEN、PASSWORD、PRIVATE_KEY、CREDENTIALS、AUTH
stdio_env_exposure — 携带 env 变量的 stdio transport（CVE-2026-12957 模式）

修复在实践中是什么样

这三个 CVE 用三种不同的方式修复——但模式在每处都一样：

白名单命令 — 永远不要从配置或不可信的调用方接受任意 command。如果必须接受，要对照显式的白名单做校验（CrewAI 的修复类别）。
把权限与配置分离 — stdio + env 是最危险的组合。使用 env_isolation，或切换到带狭窄权限模型的 SSE/HTTP（LiteLLM 的修复类别：PROXY_ADMIN 门禁）。
自动执行需显式同意 — 永远不要自动运行随工作区内容一起到达的 MCP 配置。先提示、验证信任、再运行（Amazon Q 的修复类别）。
运行时也要验证 — 配置时检查能拦截显而易见的情况；对工具输出加一层验证层能拦截其余情况。MCP Python SDK 在工具上定义了 readOnlyHint，但运行时从不强制执行——我们的审计在六个框架（AutoGen、Semantic Kernel、FastMCP、Dify、Griptape、MCP Python SDK）的 87 处生产代码实例中发现了这个缺口。

无需安装即可试用

如果你使用 Cursor 或 Claude Desktop，可以远程对任何 MCP 服务器 URL 运行配置检查：

https://mcp.correctover.com/mcp

暴露的工具：ccs_scan（扫描一个 URL 的 MCP/运行时安全问题）、ccs_check（对工具输出做 7 维运行时验证）、ccs_info（CCS 标准参考）。

或者本地安装：pip install ccs-verifier。

Correctover — 面向 AI Agent 的运行时验证。我们研究和披露 AI Agent 基础设施中的漏洞（CVE-2026-2287，以及覆盖 13 个框架的发现），并交付工具，在下一个漏洞随代码发布之前抓住它。

CVE 引用已对照 CISA KEV（2026 年 6 月）、AWS Security Bulletin 2026-047 和 MSRC Case 126356 核实。

MCP 命令注入实战拦截：3 个真实 CVE + 一个检测 Demo