编号	风险	一句话解释
Ag1	Agentic 机制滥用	Agent 被诱导执行非预期动作
Ag2	工具链安全	调用的工具本身有漏洞或恶意
Ag3	多 Agent 信任链	Agent 间传递的信息被污染
Ag4	上下文投毒	恶意内容注入 Agent 的上下文窗口
Ag5	权限提升	Agent 突破任务边界获取更高权限
Ag6	记忆/状态污染	持久化记忆被投毒，影响后续决策
Ag7	工作流劫持	攻击者篡改 Agent 的执行流程
Ag8	身份冒用	Agent 假冒其他身份执行操作
Ag9	资源耗尽	无限循环、Token 滥用导致成本失控
Ag10	审计缺失	没有日志，出事无法追溯

技术	代表工具	隔离强度	性能开销	适用场景
Bubblewrap (namespace)	Codex CLI	中	极低	文件系统隔离，开发环境
gVisor (用户态内核)	Google Cloud Run	高	中	容器级隔离，云端部署
MicroVM (Firecracker)	Docker Sandbox, Northflank	最高	高 (128MB+/VM)	企业级隔离，多租户
Container (Docker)	Docker Sandboxes	中-高	低	通用场景
WASM	Cosmonic	中	极低	插件级隔离

操作类型	为什么必须审批	典型后果
删除资源	误删无法自动恢复	数据丢失
支付/转账	资金不可逆	直接经济损失
生产部署	影响线上用户	服务中断
凭证变更	可能导致权限失控	安全事件
外部 API 调用	无法撤回	数据泄露

检查项	怎么查	红线
来源	GitHub/GitLab 仓库地址	无仓库或个人小号
Star 数	低于 100 需警惕	低于 10 且刚发布
维护频率	最近 commit 时间	超过 6 个月无更新
依赖树	`npm audit` / `pip-audit`	有已知 CVE 未修
代码审查	快速扫一眼主入口文件	有混淆代码或可疑网络请求

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 详情可在对应数据库查询。

Mcp安全 on Kalend's Blog

AI Agent 安全实战：从 MCP 漏洞到权限沙箱，生产环境必须知道的事

OWASP Agentic Top 10：AI Agent 的专属安全标准

权限最小化：Agent 不该用你的钥匙开门

三个核心原则

Amazon 的真实教训

沙箱隔离选型：五种技术，怎么选

五种主流技术对比

Codex vs Claude Code：两种截然不同的策略

Docker Sandbox 的 microVM 升级

场景推荐

敏感操作审批流：哪些事不能让 Agent 自己决定

必须人工审批的操作

Approval Gate 实现方案

读写分离原则

供应链安全审计：MCP Server 不是随便装的

安装前必做检查

运行时监控

Docker MCP 的供应链方案

全链路审计追踪：出事能追溯

审计日志必须包含的字段

异常行为检测

落地安全检查清单