前言

MCP Server 自 2024 年 11 月由 Anthropic 正式推出，至今已发展一年多，现已成为支撑大规模 AI 应用安全治理的基础设施。

随着企业在自动化流程、跨系统集成以及 AI 应用落地中的需求不断增长，MCP Server 逐渐成为满足多组件协同与任务执行的重要基础设施。

如今，许多开源的 Agent 开发框架都已支持引入 MCP Server，大量 MCP Server 部署带来了需要集中化管理的需求，也带来了许多新的攻击面。

Stdio 命令执行

MCP 目前支持两种主要传输机制（类型）：

Stdio 传输：通过标准输入输出流（stdin/stdout）实现本地进程间的直接通信，无需网络开销，性能最佳。该方式适用于同一机器上的本地进程交互。
流式 HTTP 传输：基于 HTTP POST 发送客户端消息，支持服务器发送事件（Server-Sent Events）实现消息流功能。

Stdio 传输机制下，MCP Server 会启动一个本地子进程，使用该进程的标准输入输出流进行数据交换：

MCP Server 向子进程的标准输入写入 JSON-RPC 格式的请求数据。
子进程接收请求，执行对应逻辑后，将响应结果通过标准输出返回。
MCP Server 读取标准输出内容，解析后将结果返回给调用方。

由于 Stdio 类型允许直接配置启动命令或脚本，一旦配置不严谨或缺乏限制，攻击者可能借助该机制注入恶意命令，导致命令执行漏洞。

像早些时候发现的字节开源深度研究框架：DeerFlow，系统本身没有认证授权，还允许直接配置Stdio类型MCP Server，其底层使用的是MCP官方的Python SDK实现。

我在6月24日给项目核心贡献人发了邮件告知漏洞，但很可惜没有收到任何邮件回复。

前两日看项目代码，有人给仓库提交了个pull，默认情况下不开启MCP Server配置，算是对这个漏洞进行了修复。

该项目没有release版本管理，在该pull被合并的commit：75ad3e0dc61de2bc38b12a87586bc2643e4f60c2 之前的代码都是存在漏洞的。

同时我对一些集中化管理MCP Server的网关系统进行了分析，也发现普遍存在安装Stdio类型MCP Server命令缺乏过滤的问题。

比如某1k star的开源MCP Server管理平台，底层是基于MCP官方的typescript-sdk。

还有用Go开发的，MCP官方没有sdk，用的是第三方实现的库。

未授权访问

随着MCP Server的不断发展，涌现出许多MCP Server快速创建框架，如Python的FastMCP，TypeScript的MCP Framework等。

通过这些框架，小白开发者也可以快速创建出MCP Server，但由于开发者安全水平问题，大多数没有认证授权的安全意识，甚至是直接对公网开放。

比如FastMCP，可以通过http.header="content-length: 9" && http.header="HTTP/1.1 404 Not Found" && http.header="server: uvicorn" && "text/plain" && http.body="Not Found" && http.body_hash="9d1ead73e678fa2f51a70a933b0bf017" ZoomEye 语法进行测绘。