mcploitable MCP 安全靶场实战：七类漏洞、OWASP ASI 与 Docker 隔离教程

摘要： 本文介绍 mcploitable——一个专门用于授权安全培训与研究的故意脆弱 MCP 靶场。它把邮件助手、分析助手、账户恢复、插件管理器、计算器、长期记忆助手与多 Agent 编排器包装成七个普通 MCP Server，每个服务器隐藏一种真实 Agent 安全缺陷；另有三类风险以引导式模拟呈现，共同映射 OWASP Agentic Applications Top 10（2026）。最重要的结论是：mcploitable 可以帮助团队直观看到 Prompt Injection、工具滥用、权限混淆、供应链投毒、意外代码执行、记忆污染与 A2A 信任滥用，但它包含真实代码执行能力，只能运行在项目提供的无网络 Docker 隔离容器中，绝不能连接真实密钥、数据、账户或生产 MCP 客户端。本文以防守和验证为主，讲解安全安装、CTF 层级、七类场景、控制修复、审计证据与企业培训设计，不提供可直接用于真实目标的攻击载荷。

核心结论

mcploitable 值得用于 MCP Server 开发、AI Agent 安全评审和企业红蓝对抗培训，因为它把抽象风险变成可观察的真实效果：敏感 canary 是否离开边界、工具是否执行了越权动作、代码是否在隔离容器中运行。它不是生产安全扫描器，也不是普通 MCP 工具包；安装它等于主动引入已知漏洞，环境隔离是使用前提而非可选项。

• 适用对象： MCP 开发者、Agent 平台团队、安全工程师、红蓝队、AI 治理与审计人员。
• 核心内容： 7 个可攻防 box + 3 个引导式 simulation，覆盖官方所映射的 OWASP Agentic Top 10 2026。
• 最高风险： asi05-calc 包含真实 eval/exec 类代码执行；官方明确要求只在无网络、只读文件系统、drop capabilities、非 root Docker 容器中运行。
• 版本判断： 截至 2026 年 8 月 22 日，官方仓库没有可核验的稳定 Releases，使用时应固定具体 Git commit，而不是默认追踪不断变化的 main。
• 实施建议： 使用专用测试主机或临时虚拟机、假凭据和 canary 数据；先运行 guided simulations，再逐步进入 box；培训结束后删除容器、镜像、缓存与客户端注册。

背景与主要变化

MCP 让 Agent 可以发现并调用邮件、数据库、浏览器、文件、支付和云平台工具。传统应用通常由代码明确决定“何时调用哪个 API”，而 Agent 系统把部分控制权交给语言模型：模型会读取用户请求、外部内容、工具描述、工具输出和记忆，再选择下一步动作。这使攻击面不再局限于代码漏洞，也包括“被模型当作指令的数据”和“被错误信任的工具身份”。

mcploitable 的设计灵感来自 Metasploitable，但对象从操作系统和网络服务转为 Model Context Protocol。官方仓库把它描述为一组“看起来普通”的 MCP Servers：服务器本身不显示靶场提示，不提供 scoreboard、hint tool、secure mode 或 capture flag。漏洞处于潜伏状态，学习者通过一个不可信 artifact 触发风险，成功与否由真实效果判定，而不是由模型输出一段“我被攻击了”的文字判定。

这种设计纠正了 Agent 安全培训中的常见偏差：只测试模型会不会识别恶意语句，却不测试系统有没有确定性控制。模型拒绝攻击是有价值的，但它会随模型、提示词、上下文压力和攻击写法变化；服务器端权限校验、输入验证、数据最小化、签名身份和出站过滤则不应由模型“自行决定是否遵守”。

官方映射以 OWASP Top 10 for Agentic Applications（ASI）2026 为框架。需要注意，这不等于 mcploitable 获得 OWASP 官方认证，也不意味着十类风险只能用该项目测试。项目维护者在仓库和个人文章中给出了映射、场景设计与实验结果；本文将其标为官方项目声明，不把它写成独立第三方认证。

靶场组成与 OWASP ASI 映射

七个 box 允许学习者提交一个受控 artifact，让 Agent 与 MCP Server 正常交互，再观察漏洞效果；后三类更难用“捕获秘密”表示，因此项目选择 guided simulations。

ASI 类别	场景/服务	核心风险	防守学习目标
ASI01 Agent Goal Hijack	asi01-mail / mail assistant	不可信邮件改变 Agent 目标并造成数据外带	隔离数据与指令、限制渲染器自动请求、出站控制
ASI02 Tool Misuse	asi02-analytics	被污染工单引导高权限查询与外泄	最小数据库权限、查询 allowlist、结果级授权
ASI03 Identity & Privilege Abuse	asi03-recovery	confused deputy 与恢复身份绑定错误	服务端绑定已验证身份、不可由 Agent 改写恢复目标
ASI04 Agentic Supply Chain	asi04-plugin	MCP tool/plugin 输出投毒和伪造发布者	签名、来源验证、版本固定、sink 侧密钥剥离
ASI05 Unexpected Code Execution	asi05-calc	不可信公式/数据进入 eval/exec	禁止动态执行、使用解析器与沙箱、最小权限
ASI06 Memory/Context Poisoning	asi06-memory	恶意记忆跨会话触发	记忆来源、写入审批、召回过滤、秘密不进上下文
ASI07 Insecure Agent-to-Agent	asi07-a2a	共享总线上的 peer message 被赋予权限	Agent 身份签名、能力令牌、消息级授权
ASI08 Cascading Failures	./play simulation	规划器错误向执行器和下游传播	熔断、独立校验、限速、补偿事务
ASI09 Human-Agent Trust Exploitation	./play simulation	人类过度相信流畅的 Agent 建议	来源展示、风险提示、双人复核与决策分离
ASI10 Rogue Agents	./play simulation	Agent 超出授权范围执行	最小能力、范围约束、审批与运行时策略

前三到七类 box 不是可以公开部署的演示服务。尤其是计算器场景，真实代码执行会发生；即使项目使用 fake secrets，只要用户把容器挂载到真实目录、开放网络、加入真实环境变量或使用 --local，风险就可能越过设计边界。

想先理解 MCP Client、Server、Tools 与权限边界，可通过 AI Stack Nav 的 MCP 安全与权限教程站内搜索补充基础。

L0 到 L3 控制阶梯

mcploitable 的可攻防层不是简单的“漏洞开/关”开关，而是四级控制阶梯：

• L0： 接近真实事故最初暴露的开放状态，缺少关键控制。
• L1： 增加软信号，例如告诉模型内容不可信，但仍依赖模型判断和拒绝。
• L2： 加入真实但不完整的确定性控制，可以阻挡显而易见的尝试，却仍保留可被绕过的缺口。
• L3： 目标是结构上正确的控制墙，由服务端确定性执行，不依赖模型是否“听话”。

这一阶梯的教学意义是比较“模型护栏”和“系统控制”。L1 可能在较强模型上看起来有效，但模型更换、上下文变长或语句变形后不一定保持；L3 应通过身份绑定、权限限制、签名来源、sink 过滤和数据不可达等方式，让模型即使被说服也无法造成目标效果。

项目作者报告，跨三种 victim model 的实验中，L3 在 105 次 wall 尝试中为零落地。这是维护者自己的实验结果，适合用来理解项目论点，但不应外推为所有 MCP 部署或所有攻击的通用安全率。团队应在自己的 Agent、模型和策略下复测。

安全前置条件

在下载代码前，先确认以下条件全部成立：

1. 明确授权。 只测试自己拥有或明确获准的实验环境，不把 payload、技巧或工具用于第三方 MCP Server。
2. 专用宿主。 优先临时虚拟机；不要在存有云凭据、SSH Key、浏览器 Cookie、WordPress 密码或客户资料的日常电脑上运行。
3. Docker 隔离。 只使用项目推荐的 Docker 路径，不使用 ./install.sh --local，除非是在可随时销毁的离线开发机上审查源码。
4. 禁止真实秘密。 .env 只放项目提供的 fake/canary 数据，不转发宿主环境变量，不挂载 $HOME、云凭据目录或生产仓库。
5. 禁止外网暴露。 不映射不必要端口、不改成 host network、不把 MCP stdio 包装成公网 HTTP/SSE 服务。
6. 建立清理计划。 记录客户端注册、容器、镜像、volume 和临时文件，结束后逐项卸载和删除。
7. 保留审计证据。 记录使用的 commit、Docker 配置、场景、级别、模型、结果和修复控制，但日志中不保存真实 Token。

如果无法确认 Docker 是否真的阻断网络和挂载范围，不应继续。项目 README 声明 compose service 使用 network_mode: none 类隔离、只读文件系统、dropped capabilities 和非 root 用户；实际运行前仍应读取当前 docker-compose.yml 和 Dockerfile，不能只相信二手教程。

Docker 安装与隔离验证

截至核验日，官方仓库没有稳定 Release，建议记录并固定一个审查过的 commit。以下命令只用于本地授权实验，不包含攻击载荷。

git clone https://github.com/agileAlligator/mcploitable.git
cd mcploitable

# 保存当前提交，便于审计与复现
git rev-parse HEAD

# 阅读配置再构建
docker compose config
docker compose build

完成构建后，不要立即注册所有 Server。先检查服务的隔离属性：

docker compose run --rm -T mail

官方快速开始还列出：

docker compose run --rm -T calc

但 calc 包含真实代码执行，应最后测试，并只在已确认无网络、无可写挂载、无真实环境变量的临时主机上运行。Compose 中的 danger profile 只意味着普通 docker compose up 不会自动启动它；显式 run calc 仍会启动。

验证容器边界

建议从防守角度完成以下核验，而不是直接进入场景：

1. 检查 compose 渲染结果中是否存在宿主目录 bind mount。
2. 检查网络是否禁用，不允许 DNS 和外部 HTTP 请求。
3. 检查 root filesystem 是否只读，是否仅有明确的临时可写位置。
4. 检查运行用户不是 root，Linux capabilities 是否全部 drop。
5. 检查环境变量列表，确认没有继承 OPENAI_API_KEY、云 Key、GitHub Token 或代理凭据。
6. 检查容器退出后没有残留服务或开放端口。

不要通过向公网域名发送请求来“验证能否出网”，可使用本地受控的网络检查和 Docker inspection。企业内网还应在宿主防火墙或独立 VLAN 层增加第二道阻断，避免单个 compose 配置变更使靶场接触生产网络。

注册到 MCP Client

项目提供 ./install.sh，默认构建镜像并注册七个 Server；--local 是无 Docker 的本地脚本方式，官方明确标注为 unsandboxed。安全试点建议先手工注册一个低风险场景，而不是一次性注册全部。

{
  "mcpServers": {
    "mail-assistant-lab": {
      "command": "docker",
      "args": [
        "compose",
        "-f",
        "/absolute/path/to/mcploitable/docker-compose.yml",
        "run",
        "--rm",
        "-T",
        "mail"
      ]
    }
  }
}

不同 MCP Client 的配置字段和路径不同，应以客户端当前官方文档为准。注册后应确认：

• Server 只在调用时创建临时容器；
• MCP Client 没有把真实项目目录、Key 或其他 Server 的敏感工具注入同一 Agent 会话；
• 工具调用需要人工确认，尤其是写入、发送、账户恢复、插件安装、代码执行和支付类工具；
• 使用独立测试配置，不与日常 Codex、Claude Code 或 VS Code 工作区共用。

完成训练后运行项目卸载命令：

./install.sh --uninstall

然后复查客户端配置，确保七个靶场 Server 已全部移除。不要只删除仓库目录，因为 MCP Client 可能仍保留绝对路径或本地脚本注册。

./play 与 CTF 层的安全使用

官方 ./play 提供交互菜单：选择 box 和级别，提交一个受控 artifact，观察 victim Agent 行为。本文不提供攻击 payload；安全训练的目标应是理解信任边界、日志证据和确定性修复，而不是收集可迁移的攻击模板。

建议按以下顺序开展一次练习：

1. 选择一个场景和 L0。 例如 mail 或 analytics，只使用项目自带 fake data。
2. 写出资产与边界。 明确 secret、untrusted artifact、Agent、MCP tool、sink 和成功效果。
3. 运行无害基线。 先观察正常输入时工具调用链和日志。
4. 使用项目指导进行授权测试。 不扩展到外部目标，不增加真实 URL、凭据或生产账户。
5. 收集服务端证据。 只以 canary 是否跨越边界、权限动作是否发生为准，不以模型措辞为准。
6. 逐级比较 L1、L2、L3。 记录控制放在哪一层、为什么有效或失效。
7. 编写修复验收。 确认恶意 artifact 被阻断，同时正常业务仍可完成。
8. 销毁环境。 卸载 MCP 注册、停止容器、删除临时数据和日志中的敏感字段。

可选 CTF 层位于 harness/lab/，通过一个 artifact submission entry point 和 L0→L3 梯度组织教学。其规则强调 two-plane、level ladder 和 scoring contract；官方 README 不在公开规则里放答案。企业内训应延续这一做法：把“攻击者输入面”和“维护者控制面”分开，避免学生直接修改服务端或读取内部答案。

七个 Box 的防守拆解

ASI01：邮件与间接 Prompt Injection

邮件内容是数据，但 Agent 可能把其中的自然语言当成更高优先级任务。场景还包含客户端渲染器自动抓取图像 URL 的出站通道，因此只在 Prompt 中写“不要泄露”并不充分。

有效控制包括：将不可信内容标记与隔离；禁止外部内容决定工具参数；渲染器默认不自动请求任意 URL；为出站域名设置 allowlist；敏感字段在模型上下文和渲染 sink 之前剥离；对异常 URL 和数据拼接记录审计。

ASI02：分析工具与高权限数据库

自然语言分析助手如果使用 service-role 等高权限连接，污染工单可能引导其读取集成 Token 或员工 PII，再通过客户可见回复外带。修复不能只靠 SQL 关键词黑名单。

应使用专用只读账户、行列级权限、查询模板、表 allowlist、结果级授权、敏感列遮蔽和出站 DLP。Agent 不应拥有“查询一切”的通用能力，用户可见回复也不应直接拼接未分类的数据库结果。

ASI03：账户恢复与 Confused Deputy

恢复工具的核心不是 Agent 是否相信用户，而是服务端是否把动作绑定到已验证、不可由当前请求重写的账户身份与联系方式。正确控制必须在 send_reset 等 sink 上执行，而不是让模型判断“这个邮箱看起来合理”。

ASI04：插件和工具供应链

插件描述、发布者字段和工具输出都可能成为指令载体。签名只证明某个主体发布了 artifact，不自动证明它安全；如果发布者身份可自声明，签名也没有意义。

需要可信注册表、不可伪造的发布者身份、签名验证、版本固定、变更审查、工具描述 diff、运行时权限限制，以及在 credential sink 侧拒绝把密钥作为普通参数传给第三方工具。

ASI05：计算器与意外代码执行

任何把不可信表达式交给 eval/exec 的“计算器”都可能越过数学运算边界。应使用受限语法解析器、明确操作符 allowlist、输入规模限制和独立进程沙箱；即便使用容器，也不能把宿主目录、Docker Socket、云凭据或外网暴露给它。

ASI06：长期记忆污染

记忆的危险在于延迟触发：当前会话写入一条看似普通的 note，之后无关会话召回并执行。防守需要记录记忆来源、创建者、时间、信任等级和用途；写入前做隐私与安全过滤；召回后把记忆作为不可信证据，而不是系统指令；高风险记忆写入和删除需审批。

ASI07：不安全 A2A 通信

Peer Agent 的名称不能等于身份，共享消息总线上的内容不能自动拥有调用支付或发布工具的权力。服务端应验证签名、会话、能力令牌、目标范围和动作参数；编排器只能代理调用者被授予的权限，不能因为“另一个 Agent 说可以”就升级权限。

企业训练与验收方案

企业不应把“成功触发漏洞”作为唯一成绩。更有价值的训练交付物应包含：

交付物	必须回答的问题	验收标准
Threat Model	资产、入口、信任边界、Agent 和 sink 是什么	能画出完整调用链，不遗漏客户端渲染与 A2A
Exploit Evidence	哪个 canary 或动作越过了什么边界	仅使用假数据，以服务端日志判定
Root Cause	缺的是提示词、授权、身份、隔离还是输入验证	定位到确定性控制层，不只写“模型被骗”
Remediation	控制放在哪里、如何阻断	L3 恶意用例失败，正常业务保持通过
Regression Test	修复能否长期验证	自动执行、固定 commit、无真实外部副作用
Audit Record	谁在何时以何授权测试	可追溯且不包含真实密钥
Cleanup Record	哪些 MCP 注册、容器和数据已移除	客户端无残留 Server，宿主无开放端口

推荐把一个场景拆成红队、蓝队、平台治理三种角色：红队只控制 artifact；蓝队只能修改服务器端控制和测试；治理人员审核权限、日志、证据和清理。这样可以模拟真实企业分工，并避免同一个人同时知道内部答案和攻击面。

对于你计划的“AI Agent 安全治理中心”类付费项目，mcploitable 可以作为测试数据来源和教学靶场，但不能直接打包成面向公网的在线演示。更安全的产品化方式是提供离线 Docker Lab、检查清单、修复模板、审计报告和一次性 canary，而不是托管故意脆弱 Server。

对比与选型建议

方案	主要用途	是否主动包含漏洞	适合阶段
mcploitable	MCP/Agent 安全培训与控制验证	是，且含真实 RCE	隔离实验、红蓝对抗、课程
MCP 安全扫描器	分析已有 MCP Server 的代码、工具描述或行为	否	上线前检查与持续审计
Prompt Injection 测试集	验证模型/应用对恶意指令的响应	测试输入为恶意内容	Eval、CI、红队
运行时策略网关	拦截越权工具调用、限制数据和出站	否	生产防护
普通 MCP 示例 Server	学习协议与工具开发	通常否	入门开发

mcploitable 不应取代生产扫描、代码审计和运行时策略。它的价值在于建立共同语言：开发者、安全人员与管理者能看到同一个失败效果，再讨论控制应该放在 Agent Prompt、MCP Server、Identity Provider、数据库、网络还是人类审批层。

风险、限制与注意事项

第一，项目没有稳定 Release。main 分支、Dockerfile、compose、工具描述和场景都可能变化。培训材料必须记录 Git commit；升级前重新审查镜像构建、依赖、网络和挂载。

第二，Docker 不是绝对安全边界。错误挂载 Docker Socket、宿主目录、设备或高权限 capability，可能让容器逃逸或读取宿主资产。专用 VM、无网络、防火墙和无真实凭据应形成多层隔离。

第三，模型客户端可能带来额外外连。即使 MCP Server 容器无网络，承载 Agent 的客户端或模型 API 仍可能把 Prompt、工具输出和 canary 发送到云供应商。应阅读数据处理条款，仅使用假数据，禁用不必要的日志与训练用途。

第四，靶场结果不等于生产安全证明。L3 在项目场景中挡住已知目标，只说明该控制针对这些测试有效；新的工具组合、协议版本、客户端渲染器和供应链仍会产生未知风险。

第五，攻击知识具有双重用途。培训材料应限制到授权环境、保留规则和监督，不公开可直接迁移的 payload，不鼓励扫描或测试第三方 MCP Server。

第六，真实动作必须人工审批。邮件发送、账户恢复、插件安装、密钥访问、代码执行、付款、发布内容、删除数据和权限修改都应采用最小权限、参数验证、可撤销操作和 human-in-the-loop。

事实依据与来源

• 官方已确认： mcploitable 是故意脆弱的 MCP Server 集合，被项目称为“Model Context Protocol 的 Metasploitable”。
• 官方已确认： 项目包含 7 个可攻防 box 与 3 个 guided simulations，映射 OWASP Agentic Top 10 2026。
• 官方已确认： asi05-calc 可产生真实代码执行；项目明确要求只在 bundled、network-isolated Docker 容器内运行。
• 官方已确认： compose service 设计为无网络、只读文件系统、drop capabilities 和非 root；用户仍需在当前 commit 上自行验证配置。
• 官方已确认： ./install.sh 为推荐 Docker 注册方式，./install.sh --local 无 Docker 隔离并被标注为 unsandboxed。
• 项目作者实验： 作者报告 L3 control wall 在三类模型、105 次尝试中没有落地；这是维护者结果，不是独立第三方认证。
• 编辑判断： 固定 commit、专用 VM、分阶段训练、服务端证据、清理记录和不提供通用攻击载荷属于本文安全实施建议。
• 待验证事项： 不同 MCP Client、模型版本、企业网络、运行时网关和未来协议版本下的效果需要团队独立测试。

FAQ

mcploitable 是什么？

mcploitable 是一个故意包含漏洞的 MCP 安全培训靶场。它用七个普通外观的 MCP Server 和三个引导模拟展示 Agent Goal Hijack、Tool Misuse、身份与权限滥用、供应链投毒、代码执行、记忆污染、A2A 信任滥用等风险。

mcploitable 可以部署到公网吗？

绝对不可以。官方明确警告其中一个场景会产生真实代码执行，所有 Server 只能在无网络 Docker 容器中运行，不得暴露到不可信网络，也不得连接真实数据、凭据或系统。

是否可以在日常电脑上使用 --local？

不建议。./install.sh --local 会移除 Docker 的网络、文件系统、用户和 capability 隔离。只有在可销毁、无凭据、无真实数据的离线开发机上审查源码时才考虑。

项目是否覆盖 OWASP Agentic Top 10？

官方项目将七个 box 和三个 simulation 映射到 OWASP Agentic Top 10 2026。该映射有助于课程组织，但不等于 OWASP 对项目进行官方认证，也不意味着完成十个场景就证明生产系统安全。

L0、L1、L2、L3 有什么区别？

L0 是接近事故开放状态；L1 主要依赖模型识别不可信内容；L2 加入部分确定性控制但仍留缺口；L3 使用服务器端结构性控制形成正确的安全墙。核心学习目标是从“劝模型拒绝”转向“让越权动作无法发生”。

靶场需要真实 API Key 吗？

靶场 Server 不应接收任何真实 Key。若 victim Agent 使用云模型，模型供应商凭据应只存在于隔离客户端环境，并确保不会传入 MCP 容器、日志、Prompt 或 canary 数据；也可根据项目支持使用本地或专用测试模型。

可以把 mcploitable 接入 Codex 或 Claude Code 吗？

可以作为授权实验 MCP Server 注册，但必须使用单独客户端配置、Docker 隔离、假数据和人工工具确认，不能与真实项目、个人目录、生产 MCP Servers 或日常凭据共享同一 Agent 会话。

如何判断一次测试成功？

不要以模型是否说出“我被攻击了”为标准。项目强调按效果评分：假 canary 是否真正离开边界、越权动作是否真正执行、代码是否在隔离容器中运行。判断应来自服务端与审计日志。

完成训练后如何清理？

先执行 ./install.sh --uninstall，再检查 MCP Client 配置是否还有七个 Server；停止并删除容器、镜像和临时 volume；清除测试日志和缓存；确认宿主无开放端口、无残留脚本和无真实凭据暴露。

mcploitable 能代替 MCP 安全扫描器吗？

不能。mcploitable 是故意脆弱的训练靶场；安全扫描器用于检查你的真实 Server；运行时网关用于生产拦截。三者可以组合，但用途不同。

参考来源

• mcploitable 官方 GitHub 仓库与 README
• mcploitable Docker Compose 配置
• mcploitable CTF Lab Rules
• mcploitable 官方实验结果
• mcploitable Guided Simulations 说明
• 项目作者：Building mcploitable
• OWASP Top 10 for Agentic Applications 2026
• Model Context Protocol 官方文档

会员充值教程

会员充值与订阅排查资料

适合阅读会员充值、订阅购买、权益对比和支付问题类文章后继续转化。

AI 订阅充值失败排查包 整理常见支付失败、地区限制、订单未到账和账号异常处理步骤。 查看资料包 会员权益对比表 对比不同 AI 工具会员权益、价格、适用人群和购买建议。 查看资料包