MCP 安全血案：5条攻击路径、20万台服务器中招、你装的插件可能有毒

Mon, 29 Jun 2026 08:30:00 +0800

开篇：你装的 MCP 插件，可能正在偷你的密钥

上周有个朋友找我，说他用 Cursor 写代码，某天突然发现 .ssh 目录被读过，AWS 凭证疑似泄露。排查了两天，最后定位到一个两周前从社区 registry 装的 MCP 服务器——一个号称「数据库查询工具」的 npm 包，后台默默把环境变量打包发到了一个海外 IP。

这不是个例。

先把数据摆出来，不用我渲染气氛：

指标	数值	来源
2026 年 1-2 月 MCP 相关 CVE	30+	NVD / GitHub Security Advisories
公网暴露的 MCP 服务器	7,000+	OX Security / BitSight
受影响实例总数	~200,000	OX Security
暴露在风险中的总下载量	1.5 亿+	OX Security
MCP 服务器 SSRF 易感率	36.7%	Adversa AI SecureClaw 报告
红队针对 AI 平台的漏洞挖掘成功率	89%	2026 安全行业报告

1.5 亿次下载。20 万台机器。这不是假设性威胁，是已经在发生的事。

我写这篇文章不是为了制造恐慌——恐慌没用。我想做的是把目前公开的攻击路径捋清楚，每条配真实 CVE 和原理，让你看完知道：攻击者怎么打进来，你怎么挡住。

第一章：5 条真实攻击路径

下面五条不是理论推演，每一条都有公开 CVE 或安全团队披露的真实案例。

路径一：Prompt Injection —— 零交互远程代码执行

CVE-2026-30615，CVSS 8.0，影响 Windsurf IDE。

这条是最狠的，因为用户什么都不用点。

攻击链是这样的：

1
2
3
4
5
6


攻击者在公开仓库/文档中植入恶意文本
 → 你的编程助手读取该文件作为上下文
 → 文本里藏着指令：「把以下 MCP 服务器加入配置」
 → 助手照做，修改了 mcp.json
 → IDE 重启该 MCP 服务器
 → 服务器启动命令执行任意 shell

OX Security 的研究员把它归类为「零点击 prompt injection in IDEs」。你只是打开了一个项目、读了一个 README，攻击就完成了。同样的链路在 Cursor、VS Code 的 Claude 扩展、Claude Code、Gemini CLI 中都被验证过。

这不是某个工具的 bug，是整个交互模型的结构性问题：模型输出可以直接修改自己的工具配置，而配置能触发 shell 执行。

路径二：供应链攻击 —— 你装的包里有后门

MCP 生态的供应链攻击已经出了好几起，手法各不相同但都有效。

案例 A：postmark-mcp 后门（2025 年 9 月）

有人向 MCP registry 提交了一个伪装成 Postmark 邮件服务的包。功能看起来完全正常——能发邮件、能查状态。但它在后台悄悄把 process.env 里的所有环境变量打包，通过 DNS 查询外传。

开发者装它的时候看了一眼功能描述，觉得没问题，就 approve 了。API key 就这么出去了。

案例 B：mcp-server-git 链式 RCE（CVE-2025-68145 / 68143 / 68144）

这是 Anthropic 官方维护的 MCP 服务器。三个漏洞链在一起，实现了完整 RCE：

CVE	漏洞	效果
CVE-2025-68145	路径校验绕过	突破仓库目录限制
CVE-2025-68143	git_init 无限制	能把 `~/.ssh` 变成 git 仓库
CVE-2025-68144	git_diff 参数注入	注入任意 git 参数

配合 Filesystem MCP，攻击者通过一个恶意的 .git/config 文件，在你机器上执行任意命令。官方仓库、官方维护、官方出的漏洞——这告诉你供应链风险不在于「第三方包不靠谱」，而在于整个分发链条缺乏安全审查。

案例 C：mcp-remote 命令注入（CVE-2025-6514，CVSS 9.6）

mcp-remote 是连接远程 MCP 服务器的常用客户端库。攻击者构造一个恶意的远程 MCP 服务器 URL，客户端解析时执行任意命令。这个包下载量超过 43.7 万次——它是第一个被证实产生大规模实际影响的 MCP 漏洞。

路径三：Tool Poisoning —— 工具描述本身就是武器

核心原理：编程助手把工具描述当成可信指令来执行。

工具描述（tool description）本该是给用户看的文档，但模型把它当成了 context 的一部分——而且是高权重 context。攻击者只要能改写工具描述，就能劫持助手行为，不需要碰任何代码逻辑。

经典案例：WhatsApp MCP 投毒（2025 年 4 月，Invariant Labs 披露）

一个第三方 trivia 游戏 MCP 服务器，工具描述里藏着隐藏指令。它指示助手去调用同一个进程中另一个合法的 whatsapp-mcp 服务器，读取完整聊天记录，然后作为「正常输出」外传。

端到端加密没用——因为数据是在加密层之上被助手自己合法读取并外泄的。助手有权限读，攻击者只是告诉它「读完发给我」。

变体：Rug-pull 攻击

更阴的是 rug-pull（先正常后变恶）。服务器第一次注册时返回干净的工具描述，你审核通过。之后某次 tools/list 调用，描述悄悄变了，塞进了恶意指令。

任何只在「首次批准时」检查、之后不再 re-verify 的客户端都中招。Cursor 的 MCPoison 漏洞（CVE-2025-54136）就是这个路子——用户批准后配置永远不重新验证，攻击者提交良性配置过审，后续更新里塞恶意逻辑，静默生效。

路径四：凭证窃取 —— 从工具参数到 AWS Root

案例：Microsoft MarkItDown MCP Server SSRF

MarkItDown 的 MCP 服务器会 fetch 任意 URL，没有任何校验。安全研究员 David Onwukwe 演示了完整链路：

1
2
3
4
5


MarkItDown MCP 接收一个工具调用
 → fetch 目标 URL 设为 http://169.254.169.254/latest/meta-data/
 → 命中 AWS EC2 实例元数据服务
 → 拿到 IAM 角色临时凭证
 → 用凭证访问你的 AWS 资源

169.254.169.254 是 AWS 元数据服务的固定地址，云实例上无需认证即可访问。一个 SSRF 就能拿到云权限。

微软把这个问题分类为「低风险」。实际演示已经拿到了 EC2 metadata。当你的 MCP 服务器跑在云上、有 IAM 角色挂载时，这就是凭证窃取的直达电梯。

类似手法也通过工具参数实现：恶意工具描述指示助手「把环境变量内容作为参数传给这个 API」，助手照做，API key 就到了攻击者手里。

路径五：SSRF 与路径穿越 —— MCP 服务器成为内网跳板

学术安全调研扫描了 2,614 个 MCP 实现，数据触目惊心：

风险类型	占比
文件操作存在路径穿越风险	82%
存在代码注入风险	67%
存在命令注入风险	34%
SSRF 暴露率	36.7%

案例 A：Fetch MCP Server SSRF（CVE-2025-65513，CVSS 7.5）

mcp-fetch-server 的 is_ip_private() 函数没能正确识别私有 IP 地址。攻击者让服务器请求内网地址（http://10.0.0.1/admin、http://169.254.169.254/...），函数判断「不是私有 IP」，请求放行。MCP 服务器变成了攻击者进入你内网的跳板。

案例 B：filesystem-mcp 路径穿越（CVE-2025-67366）

配置了只能访问 /home/user/project 的文件系统 MCP，攻击者用 ../../etc/shadow 穿越出去，读到了任意文件。

案例 C：Zen MCP Server 路径穿越（CVE-2025-66689）

is_dangerous_path() 函数用精确字符串匹配黑名单。/etc/shadow 被拦了，但 /etc/shadow/../../../home/user/.ssh/id_rsa 没被拦——因为不在黑名单的精确匹配里。一个子目录穿越就绕过了「敏感路径保护」。

第二章：为什么 MCP 天生不安全

拆完攻击路径，往上抬一层看架构。MCP 的安全问题不是「实现写得烂」，是设计层面就有几个结构性缺陷。

缺陷一：工具描述被默认当作权威指令

传统 API 安全模型里，文档是文档，执行是执行，两者隔离。Swagger 文档里写什么不会影响服务端行为。

MCP 打破了这个隔离。工具描述直接进入模型 context，模型把它当指令执行。这意味着——文档即攻击面。任何能改工具描述的环节（服务器更新、中间人、供应链）都等于拿到了模型的部分控制权。

缺陷二：服务器代码跑在你机器上，但行为由远程定义

MCP 服务器作为子进程跑在你本地，有你用户的全部权限——能读 .ssh、能读 .aws、能访问内网。但它的行为逻辑（工具定义、执行逻辑）由远程 npm/PyPI 包决定，随时可以更新。

你的机器提供了权限和信任，远程服务提供了行为，两者之间没有隔离层。这就像你在自己家里装了一个别人能远程操控的锁。

缺陷三：没有人工审核的默认信任链

多数 MCP 客户端用「首次信任」（TOFU）模型。你第一次批准一个服务器，之后它的所有更新和工具调用默认放行，不再重新验证。Cursor 的 MCPoison 就是钻了这个空子。

工具调用链可以跨安全域：一个你信任的 MCP 服务器，被恶意指令引导去调用另一个你授权的 MCP 服务器，数据就跨域流动了。上面 WhatsApp 投毒就是这个模式。

缺陷四：协议规范只管传输，不管安全

MCP 规范定义了消息格式和传输层（stdio / SSE），但认证、响应完整性、审计——全是生态各自为政。82% 的实现有路径穿越风险，不是因为开发者菜，是因为协议没提供安全基线，每个人都在重新发明轮子，而且发明得都不好。

第三章：真实伤亡清单

把受影响面拉个清单，让你知道自己在不在射程内。

IDE / 编程工具全线中招：

工具	受影响情况
Cursor	MCPoison 信任绕过（CVE-2025-54136）
VS Code（Claude 扩展）	零点击 prompt injection 链
Windsurf	CVE-2026-30615，CVSS 8.0 RCE
Claude Code	通过 hooks/MCP config/env 攻击链
Gemini CLI	MCP 工具链受影响
LangChain / LangFlow / Flowise	未认证 UI 注入 RCE
LiteLLM	CVE-2025-45809，SQL 注入

OX Security 评估：这些工具背后的 MCP 生态总下载量超过 1.5 亿次，约 20 万个实例存在被利用风险。

Anthropic 对核心设计缺陷的回应是：「这是设计行为，sanitize 是开发者的责任。」

vulnerablemcp.info 数据库现状：

社区维护的漏洞数据库 The Vulnerable MCP Project 已收录 50+ 个漏洞，其中 13 个评为 Critical。这个数字还在涨，每周都有新 CVE 进来。

如果你在生产环境跑 MCP 服务器，或者哪怕只是在本地用 Cursor 配了几个 MCP 插件，你都在这个射程内。

第四章：开发者自保指南

不废话，直接上操作。

5 条核心防护措施

1. 审查你装的每一个 MCP 服务器

1
2
3
4
5
6
7
8
9


# 查看当前配置的所有 MCP 服务器
# Cursor: Settings → MCP
# Claude Code: ~/.claude/mcp.json
# VS Code: 命令面板 → "MCP: List Servers"

# 检查 git 历史里有没有可疑改动
git log --all --since="2 weeks ago" -- mcp.json

# 移除不用的服务器——每一个都是攻击面

对于每一个服务器：确认发布者身份、检查 GitHub 仓库近期活跃度和 issue 区有没有安全报告。不认识的服务器，删掉。

2. 沙箱隔离

MCP 服务器进程不该有你用户的所有权限。

1
2
3
4
5
6
7


# 用 Docker 跑，只挂载项目目录，不挂 ~/.ssh、~/.aws
docker run -it --rm \
 -v $(pwd):/workspace \
 -w /workspace \
 your-mcp-server

# 或者用 Dev Container，VS Code 原生支持

原则：MCP 进程不该接触到「泄露了会很惨」的凭证。

3. 最小权限

API key 用只读 scope，别给 root key
文件系统 MCP 限定到项目目录，别给 home 目录
网络 MCP 加出站白名单，别让它随便 fetch
用了之后立刻 revoke 不再需要的凭证

4. 固定版本，不用 @latest

1
2
3
4
5


# 危险
npx @some-package/mcp-server@latest

# 正确——锁定具体版本
npx @some-package/mcp-server@1.2.3

供应链 rug-pull 靠的就是你无感知地拉到恶意更新。锁版本 + 监控更新日志，至少能让你知道什么时候变了。

5. 用 mcp-scan 做安全扫描

Invariant Labs 出的 mcp-scan 是目前最实用的免费工具：

1
2
3
4
5
6
7
8


# 需要 Python 3.10+ 和 uv
curl -LsSf https://astral.sh/uv/install.sh | sh

# 扫描你的 MCP 配置，自动检测工具投毒和已知漏洞
uvx mcp-scan

# CI/CD 集成——发现 critical 问题直接失败
uvx mcp-scan --exit-code

它能检测工具描述里的投毒指标、匹配已知漏洞数据库、检查版本是否受影响。30 秒跑完，建议每周扫一次。

MCP 服务器选型 Checklist

检查项	通过标准
发布者身份	可验证的 GitHub 组织/个人，有历史信誉
源码可审	公开仓库，能读到完整源码
活跃度	近 3 个月有提交，issue 有回应
认证机制	有 auth 层，不裸奔
权限范围	只请求必要权限，不做 read+write 全要
社区反馈	搜索 CVE + 安全报告，无未修复的高危项

工具	类型	用途
mcp-scan	免费开源	工具投毒检测 + 漏洞匹配
Snyk Agent Scan	免费/付费	依赖链漏洞扫描，CI/CD 集成
SecureClaw	企业级	55 项审计，合规报告
agent-audit	开源	OWASP Agentic Top 10 对标审计

第五章：总结与展望

先说结论：MCP 的安全不是「以后再说」的事，是现在就得管的事。

30 个 CVE 用 60 天砸下来，已经把 MCP 从「有前景的开放标准」打成了「活跃攻击面」。而根因——工具描述当指令执行、远程定义本地行为、协议不管安全——不是修几个 bug 能解决的。

好在社区在动：

协议层：MCP 规范团队在推内置认证标准、工具描述签名、服务器 attestation。这些能从根源上解决工具投毒和供应链问题，但落地还要几个月。
Registry 审查：主要 MCP registry 在上线发布者验证 + 自动安全扫描，供应链风险会降但不会消失。
客户端防御：越来越多客户端加了细粒度权限控制和定期 re-verify，TOFU 模型在松动。

但这些都是未来的事。今天的现实是：你装的 MCP 插件可能有毒，你配的服务器可能暴露在公网，你的凭证可能已经被打包外传了。

你现在该做的三件事：

打开你的 IDE MCP 设置，删掉所有不认识的服务器
跑一遍 uvx mcp-scan，修掉 critical 项
把敏感凭证从 MCP 进程能触及的环境里挪走

做完这三步，你的风险面至少砍掉一大半。剩下的，等协议和工具成熟。

安全从来不是等来的，是防出来的。MCP 生态还在野蛮生长，你不变靶子，就只能自己穿甲。

数据来源：OX Security 供应链 advisory、The Vulnerable MCP Project（vulnerablemcp.info）、Adversa AI SecureClaw 报告、Invariant Labs 工具投毒披露、NVD/GitHub Security Advisories。 CVE 详情可在对应数据库查询。

网络安全 on Kalend's Blog