MCPSEC：仅凭工具元数据检测 MCP 服务器间接提示注入漏洞

当源码、二进制和运行时交互都不可用时，能否只凭功能元数据提出可检验的漏洞假设。

• 场景：作者认为传统分析依赖白盒（源码或二进制）、黑盒（与目标交互）或灰盒（交互加部分内部信息）。闭源、远程托管或商业门槛后的系统，第三方可能既看不到实现，也不宜在部署环境里探测——例如唯一的信用卡处理服务器，或无法离线的医院 MRI。
• 现有不足：作者称 AgentFuzz 用动态灰盒模糊测试，AgentArmor 分析运行时智能体轨迹，两者都需要执行目标，因此不适用于闭源或远程托管的 MCP 服务器。公开 MCP 服务器超过 10,000 个，许多是专有的；在线写入注入载荷还可能被良性用户读到。
• 核心观察：作者假设元数据若如实描述预期行为，就蕴含所有符合实现都共有的不可约数据流（irreducible data flow）。对这类流做风险分析，可以在不观察、不交互的情况下形成漏洞假设，即 Theory-of-Concept（ToC）；待获得更多访问后再做成 Proof-of-Concept（PoC）。
• 本文做法：作者把该范式实例化为原型 MCPS EC，只用服务器注册时公开的工具元数据，审计 Model Context Protocol（MCP）服务器的间接提示注入（indirect prompt injection, IPI）。
• 威胁模型：
  • 受害系统：MCP 服务器及其工具集，连同使用它的 LLM 智能体。相关实体为人类用户、LLM 智能体、MCP 服务器、外部数据源（Table I）。
  • 知识（no-box）：分析者只有注册时公开的元数据 M：工具名、自然语言描述、JSON-Schema 输入说明；不检查实现、不与目标交互。作者假设 M 如实描述预期功能，但不含实现细节。
  • 攻击者能力：远程第三方可在工具随后会读取的外部源中放置指令内容（公开内容、合法账号贡献、或事先影响的上游制品）。外部来源决定内容是否受控，而不是物理位置。攻击者不能修改 MCP 服务器、客户端或 LLM；直接提示注入、恶意 MCP 服务器、传输层攻陷和本地攻陷不在范围内。
  • 目标与判定：使智能体偏离用户的良性意图，转向攻击者指定的推理或动作。安全属性是 context integrity：远程攻击者控制的内容必须被中介，不能被当成改变智能体行为的指令。一次合法工具调用把攻击者指令引入 LLM 上下文并影响智能体，即构成 IPI 违规。

论文在引言、Background 和形式化部分按分析范式、IPI 与 MCP 来组织相关工作。

漏洞分析范式

• 白盒方法（静态分析、符号执行、形式化验证，引用 [4]–[7]）——在源码或二进制上推理程序行为。
• 灰盒方法如覆盖引导模糊测试 [8], [9]——不需要完整源码或行为规约，但需要执行目标并观察覆盖反馈。
• 黑盒方法 [10], [11]——只与暴露接口交互并观察响应。作者认为这三类都以能够观察或交互目标为前提，并用观察来排除错误的漏洞假设。

间接提示注入与防御

• IPI [1]——攻击者把载荷放在网页、邮件或文档等外部源，LLM 把指令与外部数据放在同一上下文中，难以分开可信指令与不可信内容 [12], [13]。作者称 IPI 在网页、文档和工具输出上都仍然有效 [14]；在智能体场景中，成功注入可以级联成工具调用链和数据外泄 [15], [16]。
• 防御 [17]–[23]——作者称现有防御对自适应对手或人工红队仍然不够。AgentFuzz [24] 做部署前的动态灰盒模糊测试，AgentArmor [25] 对运行时生成的智能体轨迹做程序分析；作者指出两者都需要执行访问，因此不适用于闭源或远程托管服务器。
• 风险条件：作者认为 IPI 与一般数据流漏洞不同，仅有 source-to-sink 流不够，因为注入载荷在句法上与合法内容无法区分，还要求流保留载荷的指令保真度和语义。

MCP 与支撑概念

• Model Context Protocol [2], [26]——让 LLM 智能体调用外部数据源和工具的标准接口。服务器发布工具名、自然语言描述和类型化参数。交互分注册、调用、返回三阶段。作者引用官方 MCP Registry [27]：收集时有 18,770 个服务器，其中 3,007 个（16.0%）声明了远程端点但既无发布包也无源码仓库，另有 1,210 个（6.4%）配置前需要用户提供密钥。
• 四轴的来源：payload fidelity 对应信息流理论 [28] 与污点分析 [29]；attacker controllability 把 CVSS 4.0 的 Attack Vector 与 Privileges Required [30] 收成一个序数尺度，并故意不用 Attack Complexity。

基线方法与基准

• 基线：trivial LLM baseline。对每个目标工具，用一次 API 调用处理该服务器抽样后的注册元数据；系统提示保留 MCPS EC 的威胁模型、四轴风险量规和 ToC 要求，但去掉实体发现、数据流图重建、确定性图组装和图条件推理。推理模型同为 GPT-5.4。
• 基准：从 MCP Market top-100 榜（按 GitHub stars [31]）整理出 86 个去重后的已验证服务器，去掉 3 个已删除和 1 个已归档仓库后随机抽取 20 台、177 个工具（Table III）。

作者把本文定位为元数据-only 的 no-box 情形：不重建精确实现，只针对与漏洞相关的性质（数据流、变换、校验、信任边界穿越）生成 ToC，供以后有更多访问时验证。

MCPS EC 把 no-box 分析做成两阶段 LLM 推理：Stage 1 从工具元数据组装候选 source-to-sink 流，Stage 2 按 IPI 四轴打标并输出 ToC（Figure 1）。全部 LLM 调用使用 GPT-5.4，high reasoning effort，经 OpenAI API。

问题设定与形式化

• 实现空间：目标系统为 T，元数据为 M。I(M) 是实现 M 所述功能的实现集合，真实实现 I⋆ 在其中。漏洞在“每一种与现有证据一致的实现都包含它”时为 necessary，在“至少一种一致实现包含它”时为 plausible。
• 不可约数据流：M 蕴含的、所有符合实现都保留的最小 source-to-sink 骨架。SQL 例子中，用户可控过滤器到数据库查询的关系使 SQL 注入成为相关假设，但是否真存在取决于查询是否被不安全地构造。
• ToC：在推测数据流和已满足的利用前提上，加上攻击者角色等假设，合成攻击场景。ToC 不针对具体实现执行或验证；与 PoC 的差别是后者要在实现上验证。

IPI 的数据流与四轴

• 源与汇：源集合 S 是工具可能消费的外部来源（远程 API、网页、仓库对象、消息、文档、包注册表）；汇集合 K 是纳入工具响应的 LLM 上下文。元数据 entail 外部内容进入响应时，不可约流为 s ∈ S → MCP tool → k ∈ K。元数据只是 suggest 而非 entail 时，这条关系本身当作一条 plausible 推测路径。
• 推测：为不可约流补上实现相关的实体与操作，包括具体源、中间存储、解析与变换、字段选择、校验和清洗。每条路径 π 表示实现这些假设的 I(M) 子集。
• 风险前提：Φ_IPI = {α_ctrl, α_fid, α_sink, α_san}。一条推测路径连贯满足这些前提，就得到有元数据依据的 plausible 漏洞假设。

Stage 1：数据流推测

• 有意过度近似：元数据写不出全部实体和边，因此提示 LLM 纳入未明说但就功能与威胁模型而言仍合理的实体和边，以扩大可分析流的覆盖。
• LLM 推测：先对整台服务器的工具元数据做一次高置信实体发现（外部 API、存储、数据管道）；再按工具提出低置信但合理的实体（中间缓存、认证组件、后台服务），即使信号弱或只是类比也保留。跨工具合并去重后形成 data flow context。工具画像则为每个工具生成边：流向、污点、沿途变换。
• 确定性组装与校验：规则算法把 context 和画像接成流，并在信任区穿越处标污点。输出边进入 LLM 上下文时，若输出携带不可信数据，或输出是逐字且至少一条入边不可信，则标为注入面。结构校验要求注入边连接合法节点，且存在从攻击者可控源到工具输出汇的路径；失败的流被删除。作者称这一步是结构防护，避免畸形流在没有 oracle 时进入下游。

Stage 2：风险评估与 ToC

• 量规（Table II）：四轴独立。Payload Fidelity 为 HIGH（verbatim，原文保留）或 LOW（derived，变成元数据或摘要）。Attacker Controllability 为 HIGH（公开或供应链，无需认证）、MED（需平台账号或角色）、LOW（需要本地访问，Rule 0，作者视为 implausible）。Semantic Executability 为 HIGH（自由自然语言或代码）或 LOW（结构化数据、ID、枚举）。Sanitization 为 HIGH（路径上无过滤）、MED（截断或长度限制）、LOW（转义、过滤或涂改）。
• 输出：每条已校验的流用一次 LLM 调用，输入为该流、工具元数据、量规，以及嵌在系统提示中的 §IV-B 威胁模型。若存在一条流满足全部四项前提，则同时给出各轴标签和一段 ToC 叙事：攻击者模型与其控制的外部面、放置载荷的步骤、工具输出在到达 LLM 上下文时保留载荷的保真度。标签与 ToC 放在同一次调用里，以共享推理轨迹。工具只要有一条这样的流，就被标为 vulnerable。
• ToC 的用途：作者称它给后续分析者一个可对照源码（§VII-C）或运行时插桩（§VII-D）检验量规的场景；各轴标签则是审计支架（§VII-B）。附录给出了流水线提示词，此处不复述其约束。

成功判定

• 分析阶段不执行场景。漏洞标签来自后续人工 PoC：外部源在威胁模型下攻击者可控、工具以现实参数调用时确实取到该源、且源内容以仍带指令语义的形式到达工具输出（LLM 上下文汇）。三者同时成立才标为 vulnerable。
• PoC 分两段（附录）：Stage A 在研究者自建账号中放置语义惰性的固定 token，检查它是否出现在工具输出；Stage B 只在本地 MCP 进程内把取回的占位内容换成注入字符串，使带攻击语义的字符串不写到远程第三方服务。不适合伦理或技术条件的工具被排除，而不是静默丢弃。

实验设置

• 数据：20 台 MCP 服务器、177 个抽样工具（Table III）。服务器从 MCP Market top-100 整理的 86 台去重已验证仓库中随机抽取；单台超过 100 个工具时每台随机抽 10 个，不足则全留。按外部数据交互分成四类：A 公开网页检索（47 个工具）、B 浏览器中介（117）、C 认证 SaaS 协作（388）、D 基础设施与云（60）；括号内是各类服务器的工具总数，抽样后进入评测的是 177。12/20 由服务方官方维护；star 均值 9,479、中位数 3,764（截至 2026 年 4 月）。选择开源是为了后续能对照源码和运行时，分析时不把源码和部署交给 MCPS EC。
• 模型与基线：MCPS EC 与 trivial LLM baseline 的 LLM 调用都用 GPT-5.4（high reasoning）。基线对每个工具一次调用，提示含同一威胁模型、四轴量规和 ToC 要求，但没有实体发现、数据流重建、确定性组装和图条件推理。基线标出 97 个候选，且是 MCPS EC 所标 143 个的子集。
• 指标：RQ1–RQ3 看外部源是否合理、ToC 是否连贯或在源码下仍成立、四轴与人工标签的一致率，以及运行时可达性与保真度。RQ4 用人工 PoC 标签算 precision、recall、假阳性和假阴性。
• 评审：作者子集做标注，每人三到四台服务器；都有数据流分析和安全研究经验。讨论前，全部成对分类判断的 exact agreement 为 83.3%；其中直接评 ToC 的为 89.6%，从元数据或源码独立打的量规与数据路径标签为 80.1%，运行时观察为 82.5%。分歧先由配对评审按指南调和，未决交第三方；报告的一致率来自讨论前标注。
• 阶段（Table IV）：RQ1 只有元数据；RQ2 加源码；RQ3 再加良性参数下的执行与插桩，测可达性而非端到端可利用性；RQ4 用人工构造的 PoC 给工具打漏洞标签。RQ1–RQ3 围绕 MCPS EC 的 143 个候选，它们是基线候选的超集。预测的流、标签和 ToC 在人工评估前冻结。
• 成本：作者称平均每台 MCP 服务器 1.65 美元。论文未报告重复次数或每次调用的 token 数。

主结果

RQ4 把两种方法的预测对到 PoC 标签。论文写明：95 个工具被标为对 IPI 脆弱；MCPS EC 从元数据找回 94 个（98.9% recall），LLM baseline 找回 80 个（84.2% recall）。MCPS EC 在 177 个工具中标出 143 个，基线标出 97 个。

方法	标为有 ToC 的工具	对 95 个确认漏洞的召回
MCPS EC	143 / 177	94（98.9%）
LLM baseline	97 / 177	80（84.2%）

据摘要、引言与 §VI–VII。论文还称，被检查的工具中 132 个（92.3%）在外部数据通往 LLM 上下文的路径上没有施加任何清洗。

• 作者解读：仅用元数据即可恢复绝大多数经运行时确认的 IPI，说明 no-box 分析在这一设定下可行；相对直接提示，实体发现、数据流重建和确定性组装带来额外召回。
• 生态观察：作者把 92.3% 无清洗写成更广的生态发现，称即便在广泛使用的商业 MCP 服务器上，针对 IPI 的防护仍不常见。
• 成本：作者称 1.65 美元/服务器的成本下，可以指出后来被运行时确认的攻击面。

RQ1：仅元数据时 ToC 与标签是否合理

评的是 MCPS EC 的 143 条候选，六个维度：外部源是否合理、四轴是否得到工具描述支持、ToC 是否连贯。Table V：外部源合理 96.5%，ToC 连贯 85.3%，四轴平均一致 82.9%（Payload Fidelity 83.2%，Semantic Executability 84.6%，Sanitization 79.0%，Attacker Controllability 84.6%）。在两边都有预测的 97 个工具上，四轴平均一致 MCPS EC 为 86.9%，基线为 74.5%，差 12.4 个百分点；六维同时一致时 MCPS EC 为 60.8%。

• 分歧：Sanitization 上，MCPS EC 标 partial 而评估者标 none 的有 29 例。Attacker Controllability 上，MCPS EC 常标 authenticated_remote，评估者降为 implausible 的有 11 例，集中在评估者认为没有合理返回路径注入面的只写工具。
• 作者解读：注册元数据足以构造大体合理、内部一致的假设；依赖实现细节、尤其是清洗的属性一致率更低。从源合理性到 ToC 连贯性平均下降 8.6%，作者认为端到端攻击假设可能过度具体，或与工具行为错位。RQ1 不检验假设是否符合真实实现。

RQ2：有源码后是否仍成立

评估者看源码，判断预测的外部源是否出现在代码里，以及除 Attacker Controllability 外的三轴是否仍成立；该轴沿用 RQ1，因为源码不提供额外证据。ToC 总判为 Plausible、Partially Plausible 或 Implausible。Table VI：143 条中外部源在源码中合理的为 134（93.7%）；ToC Plausible 105（73.4%），Partially Plausible 3（2.1%），Implausible 35（24.5%）。三轴平均一致 66.2%（N=143）：Payload Fidelity 66.4%，Semantic Executability 60.8%，Sanitization 71.3%。同一 97 条上，MCPS EC 三轴平均 69.8%，基线 58.4%。

• 作者解读：75.5% 的预测 ToC 在真实实现中仍为 plausible 或 partially plausible。一致率低于 RQ1，作者把它联系到元数据没有直接暴露的实现细节。

其他消融与分析

• RQ3：在 RQ2 证据上增加良性参数的执行与插桩，检查 ToC 指出的 source-to-sink 是否在运行时出现以及载荷保真度；不测端到端可利用性。正文在所给文本中未给出 RQ3 的百分比表。
• PoC 覆盖：177 个工具里，只对伦理上和技术上可做受控试验的工具构造 PoC。排除原因包括：当前订阅档无法调用、调用会产生破坏性或第三方可见的副作用、源是非字符串结构化对象、工具本就不返回外部内容。按该协议标出 95 个 vulnerable；未满足三条义务的标为 not vulnerable，以便两边的假阴性仍可测。
• Registry 普查（非 MCPS EC 检测）：18,770 台中 3,007（16.0%）无公开实现，1,210（6.4%）需要用户密钥。
• 清洗：132/被检工具（92.3%）路径上无清洗；论文未在所给段落中按服务器列出分母是否等于 143。
• 负面与例外：RQ2 中 35/143（24.5%）ToC 在源码下被判 Implausible；Sanitization 是 RQ1 一致率最低的轴（79.0%）。论文未在所给文本中给出 RQ4 的 precision 或假阳性个数。

作者指出的局限与后续方向

• 发布计划：作者写明将在论文被接收后发布全部分析数据与源码；在有漏洞的 MCP 服务器开发者修复所报告问题之后，再发布生成的 ToC 以及可用的 PoC（引言末，Contributions 之后）。
• ToC 不是验证：作者在 §III-D 写明，ToC 不针对具体实现执行或验证场景；源码、二进制或运行时访问可用之后，分析者才能据此构造 PoC。
• 元数据是部分抽象：作者在 §III-A 写明 M 是底层实现的部分、高层抽象；因为元数据主要说明系统提供什么而不是如何实现，I(M) 的规模可能实际上无界。no-box 因此只针对与漏洞相关的性质，而不是重建已部署实现。
• IPI 的风险条件更强：作者在 §II-B 写明，仅有 source-to-sink 流不足以认定 IPI，还要求流保留载荷的指令保真度与语义；消费不可信外部数据并不必然意味着漏洞。
• 伦理约束测试方式：作者在引言和附录写明，把注入载荷持久化到活系统可能被良性用户读到，因此 PoC 把带攻击语义的字符串限制在本地进程内，远程只放惰性 token。
• 论文在所给文本中没有单独的 Limitations 节列出更多未做实验；上面各条是作者明确写出的边界与后续发布安排。

实验覆盖范围

• 服务器与工具：评测为 Table III 的 20 台服务器、177 个抽样工具，来自 MCP Market top-100 整理的 86 台开源仓库；每台工具很多时随机抽 10 个。12/20 为官方维护。
• 推理模型：MCPS EC 与基线的 LLM 调用均为 GPT-5.4，high reasoning effort。论文未报告其他评审模型。
• 证据阶梯：Table IV 的四级为元数据、加源码、加良性执行、以及人工 PoC。RQ1–RQ3 使用静态评估或仅良性参数的动态评估。
• 漏洞标签：按附录协议，95 个工具被标为 vulnerable；不满足可控源、真实取回、指令语义到达输出这三条的标为 not vulnerable。订阅档无法调用、有破坏性副作用、源非字符串或本不返回外部内容的工具被排除在 PoC 构造之外。
• 一致率与成本：讨论前 exact agreement 83.3%（ToC 89.6%，量规与数据路径 80.1%，运行时观察 82.5%）。作者报告平均每台服务器 1.65 美元。论文未报告 RQ4 的 precision 数值，也未报告实验重复次数。

MCPS EC 是一个只用 MCP 工具注册元数据、不看实现也不与服务器交互的 no-box IPI 分析原型。

• 问题：闭源、远程托管或不许在线探测时，白盒、黑盒和灰盒都缺少前提。作者用“所有符合元数据的实现共有的不可约数据流”来提出可检验假设，而不是重建真实实现。
• 方法：Stage 1 用 GPT-5.4 过度近似地发现实体和边，再用确定性算法组装并校验流向 LLM 上下文的流。Stage 2 按保真度、攻击者可控性、语义可执行性和清洗四轴评估；四项前提都满足时输出 ToC，并把该工具标为 vulnerable。基线是同模型、同量规的一次提示，但没有数据流组装。
• 设定：20 台来自 MCP Market 高星开源服务器的 177 个工具。攻击者是远程第三方，只能在工具会读取的外部源里放内容，不能改服务器、客户端或 LLM。
• 结果：MCPS EC 标出 143 个工具，基线标出 97 个。人工在受控 PoC（远程只放惰性 token，注入字符串留在本地进程）中确认 95 个漏洞；MCPS EC 找回 94 个（召回 98.9%），基线找回 80 个（84.2%）。仅元数据时，143 条上外部源合理率 96.5%、ToC 连贯率 85.3%、四轴平均一致 82.9%（Table V）。有源码后，73.4% 的 ToC 仍被判 Plausible，24.5% 为 Implausible（Table VI）。作者称 132 个被检工具（92.3%）在到 LLM 上下文的路径上没有清洗，平均成本为每台服务器 1.65 美元。
• 作者的结论：作者认为这些结果把 no-box 漏洞分析引入为一个新范式，并称 MCPS EC 在真实 MCP 服务器上说明了该范式的实际可行性。ToC 供以后有源码或运行时访问时构造 PoC；作者计划在接收后发布分析数据与源码，并在开发者修复后再发布 ToC 与可用的 PoC。