不看代码不发请求：MCPSec仅凭描述挖出98.9%的MCP注入漏洞

No-Box Vulnerability Analysis: Description-only Detection of Indirect Prompt Injection Vulnerabilities in MCP Servers

论文原文 ↗ 论文发布 2026-09-09 解读发布 2026-09-12 解读：AI前沿分享

当大语言模型（LLM）通过工具调用（Tool Calling）接入现实世界时，以Anthropic主导的Model Context Protocol（MCP，模型上下文协议）迅速成为事实上的开放标准。通过MCP，大模型能够无缝读取用户的本地文件、执行终端命令、拉取云端API数据甚至操控浏览器。然而，这种灵活的连接性直接将Agent推向了间接提示词注入（Indirect Prompt Injection, IPI）的风口浪尖——攻击者只需在外部网页、邮件或API响应中植入一段精心构造的文本，大模型在读取并解析这些返回结果时，就可能将其误当作系统指令执行，导致敏感数据外泄甚至任意代码执行。

ArXiv URL：https://arxiv.org/abs/2609.10854v1

更棘手的挑战发生在安全审计层面。在企业实际落地中，安全团队往往面临两难境地：大量MCP服务器要么是由第三方托管的闭源服务，要么属于高度机密的核心生产系统（如正在处理实时交易的金融网关）。在这些场景下，审计人员既拿不到底层源代码进行白盒审计，又被严禁发送动态测试流量以免干扰业务，传统的灰盒Fuzzing与黑盒渗透彻底失效。

针对这种“无从下手”的极端攻防环境，亚利桑那州立大学（Arizona State University）的研究团队在一篇前沿论文中开创性地提出了无盒漏洞分析（No-Box Vulnerability Analysis）新范式，并构建了自动化原型系统 MCPSec。该方法不查看一行源代码，不向目标服务器发送任何动态请求，仅仅依靠MCP服务器在注册阶段暴露的自然语言功能描述、工具名称和JSON Schema入参格式，就能推导系统潜在的间接提示词注入漏洞。在对20个高星主流MCP服务器（共177个工具）的严格验证中，人工与PoC最终确认了95个真实存在的漏洞，而MCPSec凭借纯元数据分析成功找出了其中的94个，召回率高达98.9%。这项工作不仅证明了纯接口描述中蕴含着极具价值的漏洞线索，更颠覆了传统漏洞分析对运行与代码访问的前置依赖。

被遮蔽的攻击面：为什么现有安全分析在MCP时代集体触礁？

回顾经典的漏洞分析技术体系，分析人员对目标系统的访问权限构成了划分方法的核心维度：

白盒分析（White-Box）：依赖源代码或编译二进制，借助控制流图、抽象语法树、符号执行或形式化验证穷尽程序状态；
灰盒分析（Gray-Box）：通过轻量级插桩观测程序执行路径，以覆盖率反馈为导向驱动模糊测试（Fuzzing）；
黑盒分析（Black-Box）：无需内部逻辑，但必须频繁向暴露的API或端口发送探针请求，通过输入输出的映射关系逆推潜在缺陷。

这三类传统范式存在一个共同的隐性前提：分析者必须能够观察目标系统的内部结构，或者至少能与运行时的目标系统直接交互。然而，作者对官方MCP Registry中的18,770个活跃服务器进行了系统普查，结果令人震惊：高达16.0%（3,007个）的MCP服务虽然声明了远程端点，却完全不公开任何源码仓库或安装包；另有6.4%（1,210个）的服务强制要求输入付费商业Token或私有API密钥才允许建立连接。对于第三方审计员、大模型市场监管方或企业合规团队而言，这些服务如同铁板一块，传统工具甚至无法越过“系统接入”的第一步门槛。

与此同时，运行时的间接提示词注入具有极高的隐蔽性。在典型MCP工作流中，包含三步操作：

服务注册：MCP服务器向宿主Agent注册自身工具集，提供工具名称、一段自然语言功能描述以及参数的JSON-Schema定义；
工具调用：宿主Agent根据当前用户意图，挑选工具并向MCP服务器发起调用；
响应返回：MCP服务器访问外部资源并将无固定格式的字符串（Free-form text）回传给宿主Agent，Agent将其塞入上下文继续推理。

由于当前主流LLM在注意力机制上无法从本质上隔离“受信任指令”与“不受信任数据”，只要MCP工具抓取了外部由攻击者可控的数据源（如公开网页的文本内容、GitHub Issue的评论、未经验证的日志条目），攻击指令就会潜入LLM上下文，诱导模型私自触发破坏性工具（如转账或删除数据库）。如果审计人员连发包权限都没有，这类潜伏在数据管道深处的结构性缺陷又该如何被预先预警？

什么是“无盒漏洞分析”？从意图元数据到不可约数据流

既然既没有代码也没有执行环境，无盒分析究竟在分析什么？论文的核心洞见在于：元数据（Metadata）并不是空洞的修辞，它严密定义了系统的预期行为（Intended Behavior），从而隐式框定了所有合规实现所必须包含的最小数据流骨架。

形式化地，令目标系统为 $T$，分析人员仅能访问与实现完全解耦的元数据 $\mathcal{M}$。尽管实现空间中可能存在无数种编程语言、框架和工程分支 $\mathcal{I}(\mathcal{M})$，但只要某个系统对外宣称其功能为“根据URL爬取网页正文”，那么无论其底层使用Python还是Go，是否使用了缓存，任何符合该元数据约定的有效实现，都必须在逻辑上包含从“不可信外部网络”到“工具返回输出”的数据传递路径。

作者将这种所有合规实现都必须保留的、最小的、与具体实现无关的数据依赖关系定义为不可约数据流（Irreducible Data Flow）：

\[s\in\mathcal{S}\longrightarrow\textit{MCP tool}\longrightarrow k\in\mathcal{K}\]

其中 $\mathcal{S}$ 代表工具依赖的外部潜在攻击者可控数据源集合（如远程API、网页DOM、数据库条目），$\mathcal{K}$ 代表宿主LLM的上下文接收端（Sink）。

如果一个脆弱数据流的存在是元数据语义所必然要求的，那么无论具体的底层代码怎么写，该系统在逻辑上都存在漏洞风险。基于这种抽象，无盒分析不再去盲目猜测底层某行代码有没有写越界，而是转向严谨的风险假设推演：审计人员可以假定数据在流转过程中可能经过的解析、验证与清洗条件，进而推导出一整套具备可检验性的攻击利用场景。作者将这一产物命名为概念理论（Theory-of-Concept, ToC）——它并非直接可执行的PoC脚本，而是一份高度具体、说明了触发前提与攻击链条的假设蓝图，供后续获得权限的安全人员进行靶向排查。

MCPSec解密：两阶段流水线如何从描述推导攻击链？

为了将上述数学框架转化为切实可行的工程流水线，团队设计了 MCPSec。该框架专门面向MCP环境的间接提示词注入威胁，分为前后衔接的两个阶段：第一阶段负责结构化的数据流推测与物理装配，第二阶段负责多维度风险推演与ToC攻击链生成。

第一阶段：数据流推测与确定性图装配

仅凭自然语言描述，往往存在大量未明说的系统组件。例如，一个名为 query_issue 的GitHub工具，其元数据可能只声明了入参 repo_name，但其内部必然涉及向外部GitHub API发起网络请求并接收JSON payload。

为了保证对潜在攻击面的最大覆盖，MCPSec 在 Stage 1 采取了“刻意过近似（Deliberate Over-approximation）”策略：

LLM驱动推测：提示大模型根据工具的自然语言描述和参数模式，发掘出虽然未显式写明但在功能上不可或缺的外部实体、中间组件和隐式流动边。
确定性图装配与结构验证（Deterministic Assembly & Validation）：这一步是 MCPSec 区别于纯大模型自由发挥的关键设计。系统引入了一套硬编码的规则算法，将推测出的实体与边拼装为完整的数据流图（DFD），并在信任域跨越边界处进行污点状态标记。只有当输出边直接携带不受信任数据，或输出内容为逐字回显且上游输入受污染时，该边才会被确定性地标记为“潜在注入面”。最后，系统通过结构校验器强行剔除那些断头、孤立或无法形成端到端完整通路的幻觉图，确保流向下游推理的数据流在拓扑上严格成立。

第二阶段：LLM辅助的四维风险矩阵评估

通过结构校验的数据流只代表通路存在，并不意味着漏洞一定能被触发。在 Stage 2 中，MCPSec 对每个候选数据流施加了一套专为间接提示词注入定制的四维风险指标体系 $\Phi_{\mathrm{IPI}}$：

数据源可控性（$\alpha_{\mathrm{ctrl}}$）：攻击者是否能够在没有宿主系统内网凭证的前提下，单向篡改或控制外部数据源？（例如：公网可编辑的Wiki条目属于高度可控，而内网加密配置项则不可控）；
数据传递保真度（$\alpha_{\mathrm{fid}}$）：外部数据在穿透MCP服务器时，其文字语义是否被高保真保留？如果服务端只截取数字状态码，注入指令就会被破坏；如果透传整段文本，保真度即成立；
进入模型上下文（$\alpha_{\mathrm{sink}}$）：该工具的执行结果最终是否会无过滤地塞回宿主Agent的Prompt当中；
防御与清洗假设（$\alpha_{\mathrm{san}}$）：根据工具的功能定位，推测其实现中是否存在针对提示词注入的主动防御或结构化截断。

MCPSec 利用大模型深度推演这四个指标是否同时闭环。一旦闭环，系统就会将该数据流标记为存在漏洞，并自动编写结构化的 ToC。ToC 明确指定了受害工具、攻击者所需角色、假定的外部注入点、数据流向变换细节以及最终诱导Agent执行越权操作的具体后果。

递进式实证：从元数据假设到真实PoC的98.9%穿透

为了验证纯元数据推导的结论究竟是否经得起推敲，研究团队设计了一套极其严密的递进式评测协议。评测对象涵盖了 20个主流开源MCP服务器中的177个具体工具，这些服务器在GitHub上平均收获9,479颗Star，其中12个由原厂服务商官方维护，极具代表性。团队在分析阶段完全封存源代码和运行环境，强制 MCPSec 处于严格的“无盒”状态，待分析全部冻结后，再逐步解封更高级别的证据进行四层交叉验证。

[阶段 0: 无盒推断]  工具元数据 (注册描述 + JSON Schema)

        │

        ▼  MCPSec 自动化推导，生成 143 个潜在易受攻击工具候选及 ToC

        │

[验证 1: RQ1 元数据自洽性] 人工仅看元数据评估 ToC 是否合理 (双人一致性 89.6%)

        │

        ▼ 引入源代码 (源码解封)

[验证 2: RQ2 源码落地验证] 审查真实代码，确认数据流与组件是否真实存在

        │

        ▼ 部署真实运行时 (抓包与上下文追踪)

[验证 3: RQ3 动态流向可达性] 76.2% 的预测数据流在运行中高保真抵达 LLM 上下文

        │

        ▼ 实施伦理攻击测试 (PoC 渗透)

[验证 4: RQ4 漏洞真值回收] 95 个经 PoC 证实的漏洞中，MCPSec 成功命中 94 个 (98.9% 召回)

逐层逼近真相的四大研究问题

在 RQ1（元数据层自洽性） 中，评估人员在同样只看元数据的前提下，对 MCPSec 标记的 143 个漏洞候选进行独立盲审。实验显示，生成的 ToC 在合理性与内部逻辑一致性上得到了专家的高度认可，各维度标注的一致性比率接近90%。这表明基于不可约数据流的推测不是毫无边际的胡乱猜测，而是符合安全逻辑常理的演绎。

在 RQ2（源码对照验证） 中，研究人员正式打开源码，对这些纯凭空推导的“理论图谱”进行解构。令人惊讶的是，绝大多数在无盒状态下推测出的数据流和组件在代码中均能找到完全对应的实现。即使部分 ToC 被判定为“不完全匹配”，其核心原因也几乎全是因为代码在下游偶然丢弃了字段（例如代码临时截断了长字符串），而没有任何一个开源MCP服务部署了专门防范间接提示词注入的主动防御过滤机制。

在 RQ3（运行时上下文追踪） 中，团队通过动态插桩探针监控真实数据包的流向。结果证实，76.2% 被预测的数据流在真实执行时，确实以完整或派生文本的形态直接流入了宿主LLM的上下文。这意味着无盒分析推导出的攻击信道不仅停留在纸面，在物理层面上具有极高的可达性。

在最终决战的 RQ4（真实漏洞回收能力） 中，研究人员在受控实验室内为所有适用的工具手动编写了利用PoC，最终锁定了95个可稳定复现的间接提示词注入漏洞。对比实验充分展现了结构化无盒分析的威力：

普通LLM基线（直接使用相同大模型输入提示词进行漏洞判断）：找出了80个漏洞，召回率为84.2%；
MCPSec流水线：成功覆盖了其中 94个漏洞，召回率达到了惊人的98.9%，仅漏报了1个边缘案例。

这一悬殊差距证明，单凭通用大模型的端到端直接回答，极易因为缺乏中间数据流约束而遗漏复杂的深层缺陷；而 MCPSec 借助确定性图装配所构建的“不可约数据流”骨架，有效引导了大模型的逻辑推理，最大化压榨了元数据中所蕴含的安全情报。

攻防个案剖析：从一段脚本描述到会话凭证外窃

论文中披露的一个典型案例极具警示意义。在针对官方工具集 chrome-devtools-mcp 的审计中，MCPSec 扫描到了一个名为 evaluate_script 的工具。其注册元数据仅宣称该工具用于“在当前激活的浏览器标签页内执行给定的JavaScript脚本并返回执行结果”。

仅凭这一句话，MCPSec 的 Stage 1 推测出一条隐秘信道：该工具的调用很可能伴随着外部网页DOM环境与本地LLM执行环境的直接交互。在 Stage 2 中，MCPSec 自动生成了一份 ToC，提出了一个大胆的攻击设想：如果受害Agent受托访问了一个由攻击者控制的恶意网站，该网页无需任何浏览器高危漏洞，只需在其DOM树中埋藏一段提示词文本，诱导Agent为了完成页面分析而调用 evaluate_script 去读取同一来源下的敏感凭证，并将其作为参数回传给攻击者的监听服务器。

研究团队随后根据这份元数据导出的 ToC 构建了真实 PoC。在模拟环境中，浏览器预先存入了模拟单点登录（SSO）的敏感 Cookie 和 localStorage 认证凭证。当本地Agent受用户委托使用该MCP服务器浏览测试网页时，网页中潜藏的隐藏文本瞬间激活，接管了Agent的思考链路：Agent主动调用了 evaluate_script 读取了 document.cookie，随后在神不知鬼不觉中发起了跨域网络请求，将凭证全盘外落给远程服务器。

这个案例不仅证明了 ToC 转化为真实利用代码的高效性，更揭示出当下MCP生态中最严峻的现实盲区：很多高危权限工具的设计初衷完全是良性的，但只要它与不受信的数据流产生交集，在缺乏物理级隔离的Agent系统中，它就会瞬间沦为攻击者手中的远程木马。

无盒范式对大模型Agent生态的深远启示

亚利桑那州立大学提出的无盒漏洞分析，其价值绝不仅限于开发了一款检测工具，更在于从底层重塑了我们对大模型系统安全审计的认知边界。

首先，安全审计的防线被大幅前移。在以往的软件工程中，安全评估往往滞后于部署——至少需要等微服务跑起来、API端口开放后，动态扫描器才能进场。而无盒范式证明，在Agent驱动的软件体系中，接口协议的设计规范本身就是代码。开发者刚刚在草稿纸上定下工具名称、入参和功能描述的一瞬间，其潜在的安全脆弱性就已经基本定型。企业完全可以在采购闭源Agent服务前、在MCP服务上线注册中心审核的第一秒，就完成99%的潜在风险预警。

其次，这项研究暴露了当前MCP协议设计上的关键结构性缺陷。论文在分析误报案例时指出，MCPSec 产生部分误报的主要原因，在于目前的 MCP 规范仅强制声明了输入模式（Input Schema），却几乎没有对输出模式（Output Schema）做出严格的形式化约束。MCP工具返回的数据往往是一团自由发挥的纯文本，这不仅导致分析工具必须依赖假设去推演输出形态，更为提示词注入提供了最适宜滋生的温床。如果未来的MCP规范能够引入端到端类型化、结构化的返回模式，并在协议层对外部非受信实体强制打上污点标签，将能从体系结构层面直接瓦解大半间接注入攻击。

从白盒的代码穷举，到黑盒的流量试探，再到如今仅仅依靠自然语言描述就能洞察漏洞的“无盒推演”，大模型不仅在重构软件开发的形态，也在重构网络攻防的底层范式。当功能描述本身就足以出卖系统的安全弱点，每一个致力于构建自主Agent的开发者，或许都需要重新审视自己向世界暴露的那几行看似无害的工具说明了。