MCP 服务器正在成为新的攻击面

Model Context Protocol 现在有了自己的安全漏洞数据库，已收录50条记录。¹

60天内提交了30个CVE。在调查的2,614个MCP实现中，82%存在易受路径遍历攻击的文件操作漏洞。38%至41%的服务器完全没有身份验证机制。² 官方MCP Inspector工具——开发者用来调试MCP服务器的工具——存在远程代码执行（RCE）漏洞。广泛使用的mcp-remote包存在操作系统命令注入缺陷。¹

这不是理论上的攻击面。这些是真实的CVE，存在于真实的软件包中，而开发者此刻正将它们连接到Claude Code、Codex CLI和Cursor上。

摘要

MCP服务器是智能体生态系统中增长最快的集成接口，同时也是审计最薄弱的环节。漏洞数据库已有50条记录：13个严重、32个高危。输入验证失败和提示词注入占了50个漏洞中的30个。本周一天之内，三个不同的MCP服务器就暴露了三个SSRF漏洞。³ 趋势显而易见：社区发布MCP服务器的速度远超审查速度。

核心要点

• Claude Code用户： 每连接一个MCP服务器，就是在扩展一个信任边界。现在就运行claude mcp list，审计已连接的服务器。如果仍在使用几个月前安装的社区MCP服务器，请检查它们是否已打过补丁。
• 工具链开发者： PreToolUse钩子是MCP工具调用到达未审计服务器之前的最后防线。建议添加钩子来验证MCP工具输入——尤其是那些接受URL、文件路径或Shell命令的服务器。
• MCP服务器作者： MCP规范说明”应始终有人工参与”。请将其视为”必须”。验证所有输入，绝不通过字符串拼接将用户可控的字符串传递给Shell命令，绝不信任OpenAPI规范中未经URL验证的$ref值。

数据概览

Vulnerable MCP Project维护着一个MCP安全问题数据库。¹ 当前状态如下：

严重程度： 13个严重、32个高危、5个中危。¹ 32位安全研究人员贡献了研究成果。受影响的服务器包括Anthropic自己的Git MCP服务器、官方MCP Inspector、Microsoft MarkItDown、GitHub Kanban、Figma、Jira、Grafana、Neo4j、Kubernetes，以及20多个社区构建的服务器。¹

调查结果最为触目惊心：2,614个MCP实现中，82%存在易受路径遍历攻击的文件操作漏洞。² 也就是说，五分之四的MCP服务器会让攻击者读取到本不该访问的文件。

五种攻击模式

60天的CVE爆发揭示了五种反复出现的攻击模式：²

1. 工具投毒。 将恶意指令嵌入MCP工具描述中。智能体读取描述后信以为真，利用自身的授权工具执行隐藏指令。被投毒的工具本身从未执行——智能体的合法工具替它完成了攻击。我们在部署与防御悖论中分析过这一模式：信任是传递的，审计却不是。

2. 通过外部数据进行提示词注入。 从GitHub issue、Slack消息、邮件或网页获取内容的MCP服务器，会将攻击者控制的文本引入智能体的上下文。注入目标不是MCP服务器本身——而是读取服务器输出的智能体。静默数据外泄攻击面是其一般形式；MCP服务器是最常见的攻击向量。

3. 初次批准后的信任绕过。 Claude Code在首次使用时会要求您批准MCP服务器。但此后，工具定义可以在会话之间发生变化而不一定重新提示——安装时安全的服务器在更新后可能行为完全不同。这种重新验证的缺口是结构性的：协议不要求对工具描述进行加密签名。²

4. 供应链攻击。 被植入后门的MCP服务器发布到注册表中，包括冒充合法服务器的恶意包。这与我们在供应链即攻击面中记录的供应链攻击模式如出一辙，只不过应用到了MCP生态系统。

5. 跨租户暴露。 在共享托管环境中，多个MCP服务器可以在执行前拦截彼此的函数调用。⁴ 从外部看似坚固的隔离边界，在多个服务器共享同一进程或容器时便形同虚设。

SSRF攻击模式

本周一次扫描中，三个不同的MCP服务器暴露了三个SSRF漏洞：³

• n8n-mcp： 通过实例主机注入实现的认证后SSRF
• mcp-from-openapi： 通过OpenAPI规范中的$ref值触发SSRF——恶意规范中包含内部URL，导致服务器在初始化期间获取这些资源
• stata-mcp： 对用户提供的URL验证不足

MCP服务器中的SSRF尤其危险，因为服务器通常拥有智能体所不具备的网络访问权限。以下展示一个恶意OpenAPI规范如何演变为凭证窃取：

步骤1. 攻击者发布一个看似合法的MCP服务器，封装了某个外部API。该服务器使用mcp-from-openapi从OpenAPI规范生成工具。

步骤2. OpenAPI规范中包含一个指向内部地址的$ref：

components:
  schemas:
    Config:
      $ref: "http://169.254.169.254/latest/meta-data/iam/security-credentials/role-name"

步骤3. 在initialize()期间，MCP服务器通过获取URL来解析$ref。服务器运行在您的基础设施上——在您的VPC内、您的笔记本电脑上、或您的CI容器中。请求从受信任的来源发往AWS元数据端点。

步骤4. 元数据端点返回临时IAM凭证：访问密钥、密钥和会话令牌。

步骤5. 服务器现已获取您的云凭证。它可以通过工具响应将其外泄、记录到外部端点，或直接使用。

整个过程中智能体没有任何恶意行为。用户批准了MCP服务器。OpenAPI规范看起来一切正常。$ref解析发生在底层库中，远低于任何人的审查范围。SSRF将MCP服务器的网络位置转化为了攻击者的网络位置。

Microsoft在2026年3月修补了一个严重的Azure MCP SSRF漏洞（CVE-2026-26118）——同样的模式应用于Azure：一个高严重性权限提升漏洞，可窃取身份验证令牌并获取对Azure资源的未授权访问。⁵

应对措施

审计已连接的服务器。 运行claude mcp list，逐一检查每个服务器。将其与Vulnerable MCP Project数据库进行交叉比对。¹ 移除不再使用的服务器。

锁定服务器版本。 如果通过npm或pip安装MCP服务器，请锁定版本，不要自动更新。升级前仔细阅读变更日志——信任绕过模式意味着更新可能在无需重新批准的情况下改变工具定义。

添加输入验证钩子。 在MCP工具调用上添加PreToolUse钩子，可在输入到达服务器之前进行验证：

#!/bin/bash
# .claude/hooks/validate-mcp-input.sh
INPUT_JSON=$(cat)
TOOL_NAME=$(echo "$INPUT_JSON" | jq -r '.tool_name // empty')

# Block MCP tools that accept URLs from passing internal addresses
if echo "$TOOL_NAME" | grep -q "^mcp__"; then
  TOOL_INPUT=$(echo "$INPUT_JSON" | jq -r '.tool_input | tostring')
  if echo "$TOOL_INPUT" | grep -qiE '(169\.254\.|10\.|172\.(1[6-9]|2|3[01])\.|192\.168\.|localhost|127\.0\.0\.1|metadata\.google|169\.254\.169\.254)'; then
    echo "Blocked: MCP tool input contains internal/metadata address" >&2
    exit 2
  fi
fi
exit 0

考虑传输层隔离。 HTTP MCP服务器在独立进程中运行，具有明确的网络边界。Stdio服务器则共享智能体的进程上下文。两种传输方式都不是天生安全的——更关键的因素在于服务器是否能访问凭证、内部网络或敏感文件路径。请根据威胁模型选择能提供所需隔离边界的传输方式。

关注漏洞数据库。 vulnerablemcp.info上的Vulnerable MCP Project是目前最接近MCP生态系统CVE追踪器的资源。安装新服务器前务必查阅。

MCP生态系统增长迅猛——已索引3,000多个服务器，每月下载量超过1亿次。⁶ 但安全态势并未同步跟进。一个一年前还不存在的数据库中已有50个漏洞。问题不在协议本身，而在于实现。

参考来源

常见问题

Claude Code自带的MCP服务器是否受到影响？

漏洞主要影响社区构建和第三方MCP服务器，而非Claude Code的核心MCP基础设施。但官方MCP Inspector工具确实存在过RCE漏洞，因此”官方”并不等于”免疫”。

是否应该停止使用MCP服务器？

不必。MCP是强大的集成层。但应将每个MCP服务器视为一个信任边界。审计已连接的服务器，锁定版本，并为接受URL、文件路径或Shell命令的服务器添加输入验证钩子。

如何检查MCP服务器是否存在漏洞？

运行claude mcp list查看已连接的服务器。将每个服务器与Vulnerable MCP Project数据库进行交叉比对。检查服务器的GitHub仓库中是否有近期的安全公告。