MCP 协议的安全噩梦：2026 年 AI 连接器的信任危机

你可能听说过 Model Context Protocol（MCP）——那个让 AI Agent 能够调用工具、读写文件、发送 HTTP 请求的协议。它被认为是 2026 年 AI 应用开发最重要的基础设施之一。

但今天，我要给你泼一盆冷水。

过去 15 个月里，MCP 生态已经积累了 数十个 CVE 漏洞，包括命令注入、路径穿越、供应链投毒——而且这些漏洞不是来自第三方小项目，是来自官方工具和热门服务器。与此同时，大量 MCP 服务器在没有任何认证保护的情况下暴露在公网上，安全问题已经不是"潜在的"风险，而是正在发生的真实威胁。

这篇文章，我会用通俗的语言，把 MCP 安全危机拆解清楚：到底哪里出了问题？为什么这么多人还在用？以及，你应该怎么保护自己？

什么是 MCP？为什么它突然这么火？

在理解安全问题之前，先要知道 MCP 到底是什么。

你可以把 MCP 想象成 AI 世界的"USB 接口"。过去，如果你想让 AI 模型读写文件、查数据库、发 HTTP 请求，每做一个新功能都需要单独开发集成。但 MCP 提供了一套统一的标准——只要一个服务器实现了 MCP 协议，任何兼容 MCP 的 AI 客户端都能直接调用它的能力。

举个例子：一个 MCP 文件服务器实现了"读文件"和"写文件"两个工具。Claude、GPT、或者任何基于这些模型开发的 AI 应用，只要连接到这个服务器，就能直接读写文件，不需要额外开发。

这就是为什么它突然火了起来。

2025 年下半年开始，AI Agent（AI 智能体）成为行业最热门的方向——让 AI 自动完成复杂任务，而不是只做单轮问答。MCP 正好解决了 Agent"怎么操控外部工具"的问题。各大 AI 公司、开发者社区、开源项目都在疯狂建设 MCP 服务器生态。

但问题也随之而来：人们在追求速度和功能的同时，安全被放在了第二位。

三类真实发生的攻击手法

MCP 的安全问题不是理论推导，而是已经真实发生的攻击。

第一类：命令注入——你的服务器被远程控制

命令注入是最直接、最危险的漏洞类型。攻击者通过构造特殊的输入，让 MCP 服务器执行它不应该执行的系统命令。

2025 年，mcp-remote 服务器被发现存在严重的命令注入漏洞，编号 CVE-2025-6514。这个漏洞允许攻击者通过 MCP 请求，在服务器上执行任意 shell 命令。

更让人意外的是，Anthropic 官方的 Git MCP 服务器也被发现了三个漏洞（CVE-2025-68143/44/45），同样涉及路径穿越和命令注入。

想象一下这个场景：你给 AI 分配了"帮我整理代码仓库"的任务，AI 连接了 Git MCP 服务器读取文件。但恶意构造的仓库内容，让 MCP 服务器执行了 rm -rf /——你的整台服务器被清空了。

第二类：供应链攻击——你安装的包早已被篡改

2026 年 3 月，安全研究者发现了SANDWORM 攻击：攻击者大规模 fork 正常的 MCP 服务器 npm 包，改名后重新发布，其中植入了恶意代码。用户在没有仔细核对的情况下，安装了这些"李鬼"包，AI 配置中就悄悄引入了一个流氓 MCP 服务器。

这就像你在 npm 上搜索一个热门工具，装完之后发现它偷偷在后台下载挖矿程序——只不过 MCP 版本更危险，因为它直接拥有 AI 的"信任"，可以操控 AI 的工具调用行为。

与此同时，另一个被称为 SmartLoader 的木马病毒被发现在多个 MCP 包中传播，专门攻击制造业企业的 AI 系统。

第三类：数千个服务器"裸奔"在公网上

2026 年初，一项安全扫描发现，数千个 MCP 服务器在没有任何认证机制的情况下暴露在公网上。这些服务器直接接受来自任何客户端的请求——没有 API Key、没有权限验证、没有任何访问控制。

如果你的 AI 应用连接到了其中一个不安全的服务器，不仅 AI 的行为可能被劫持，你本地的文件路径、工作目录、凭据信息都可能被暴露。

攻击是怎么实现的？用大白话解释

看完上面的描述，你可能会想：攻击者到底是怎么做到的？

用一个具体的攻击链来演示：

攻击者给你发送一封邮件，附件是一个"代码优化建议.txt"
↓ 
你让 AI 读取这个文件，AI 通过 MCP 文件服务器读取
↓ 
文件内容被注入了一段恶意指令（类似 SQL 注入，但针对 MCP 协议）
↓ 
MCP 服务器没有做输入过滤，把恶意指令当成正常命令执行
↓ 
攻击者通过这个渠道拿到了你 ~/.aws/credentials 的内容
↓ 
攻击者把凭据上传到自己的服务器

整个过程没有触发任何告警——AI 在"正常工作"，用户完全不知情。

这就是为什么这类攻击特别危险：它不破坏任何东西，AI 还在正常回复，但数据已经在后台被偷走了。

安全工具开始涌现：有用吗？

好消息是，安全社区已经注意到了这些问题，并且开始推出防护工具。

MCP-Shield 是一个专门审计 MCP 服务器安全性的工具。它可以在你安装一个 MCP 服务器之前，检查它是否存在已知的漏洞模式、恶意的网络请求、可疑的文件操作。

VellaVeto 是一个运行时防火墙——它部署在 AI 和 MCP 服务器之间，监控每一次工具调用。你可以把它理解成 AI 世界的"流量警察"：AI 说"我要读 ~/.aws/credentials"，VellaVeto 会拦截这个请求，检查它是否符合你设定的安全策略，如果不符合就直接拒绝。

VellaVeto 还有一个有意思的功能叫"Consumer Shield"（用户端防护）：即使你使用的是商业 AI 服务，它也能在本地拦截和清理敏感信息，防止你的文件路径、凭据被 AI 提供商看到。

ContextGuard 提供的是运行时监控能力——实时记录 MCP 服务器的所有行为，发现异常时告警。

这些工具的出现说明安全意识在觉醒，但它们的使用门槛目前还比较高，需要一定的配置和管理。对于大多数普通用户来说，"安全问题"依然是 invisible risk。

作为普通用户，你现在能做什么

如果你正在使用基于 MCP 的 AI 应用或开发相关项目，这里有几件你现在就可以做的事：

第一，不要安装来源不明的 MCP 服务器。 和 npm、pip 生态一样，MCP 包也有被篡改的风险。只安装你信任的、经过社区验证的服务器。如果可能，核对包的作者和仓库信息。

第二，给你的 MCP 服务器加认证。 如果你在自建 MCP 服务器，至少加上 API Key 认证，不要让它裸奔在公网上。

第三，关注工具生态的进展。 MCP-Shield 这类审计工具正在变得越来越易用。在你部署一个新的 MCP 服务器之前，花几分钟做一次安全检查。

第四，如果你在企业环境使用 AI Agent，和安全团队谈谈 MCP 的风险。 OWASP 已经在 2026 年推出了"Agentic 应用 Top 10 风险"榜单，MCP 安全是其中重要的一部分。

一个值得思考的问题

MCP 安全危机背后，其实有一个更深层的矛盾：速度和安全的取舍。

AI 应用生态正在以惊人的速度扩张。开发者需要快速集成各种工具，用户需要 AI 能做越来越多的事。在这种压力下，安全往往成为"之后再说"的事情。

但 MCP 的特殊性在于：它不是一个普通的库或者 API，它是 AI 系统的"触手"。如果 MCP 被攻破，攻击者拿到的不只是数据，而是AI 的控制权。

这个风险级别，和我们过去熟悉的 Web 安全、数据安全不在同一个量级。

当越来越多的 AI Agent 开始进入生产环境，开始操作文件、发送请求、管理凭据——MCP 的安全性，实际上决定了 AI 应用安全的下限。

这个危机，目前还没有被足够多人意识到。

参考来源：

VellaVeto（MCP 防火墙）: https://github.com/paolovella/vellaveto
OWASP Agentic Top 10 (2026): https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/
CVE-2025-6514 (mcp-remote 命令注入): https://nvd.nist.gov/vuln/detail/CVE-2025-6514
SANDWORM MCP 供应链攻击: 相关安全博客
MCP 安全漏洞列表: https://www.practical-devsecops.com/mcp-security-vulnerabilities/
Invariant Labs MCP 安全通报: https://invariantlabs.ai/blog/mcp-security-notification-tool-poisoning-attacks