Unsafe by Flow：揭示 MCP 生态中的双向数据流风险

核心问题：MCP 服务器中跨信任边界的双向不安全数据流（请求侧传播与返回侧传播）难以被现有静态分析工具检测。

• 场景与重要性：MCP（Model Context Protocol）由 Anthropic 于 2024 年末提出，16 个月内服务器数量增至近 60k（§1）。作者认为工具输入可能触发特权操作、工具输出可能重新进入 LLM 推理，两个方向都与安全相关。
• 现有方法的不足：作者称，已有 MCP 安全研究主要刻画生态风险、攻击模式与防御；CodeQL、Semgrep 等通用分析器并非为端到端恢复 MCP 交互结构而设计（§1）。
• 三个具体困难（§1、§2.4）：工具注册与分发模式多样，入口点难识别；通用污点模板与 MCP 信任边界不匹配；漏洞往往只在完整的工具级执行路径上显现。
• 论文提出：MCP-BiFlow，一个围绕 MCP 感知入口点恢复、协议特异污点建模和双向过程间传播的静态分析框架，并在 32 个已确认漏洞和 15,452 个真实仓库上评估。
• 威胁模型（§2.3）：
  • 目标：检测请求侧传播（请求方控制数据到达敏感操作）与返回侧传播（外部或内部敏感数据经 MCP 可见输出流出）。
  • 攻击者知识/能力：不控制服务器内部、源码、主机或部署流水线；通过正常交互通道提供构造输入，或控制被服务器消费的外部内容源（第三方 API、公开仓库、网页、远程数据库）。
  • 受害系统：由非恶意方实现、运行环境未被攻陷的 MCP host、client、server。
  • 排除项：依赖代码库、供应链或部署基础设施被攻陷的攻击，以及不表现为跨边界数据流的认证、授权和业务逻辑问题。

MCP 安全研究

• Hasan et al. (2025)：测量开源 MCP 服务器，识别常见漏洞类别与维护弱点。Hou et al. (2025)：综述 MCP 生态、威胁模型与开放研究方向。
• Zhao et al. (2025)：给出恶意 MCP 服务器行为分类并演示概念验证利用；Radosevich and Halloran (2025)：展示当前 MCP 工作流仍易受代码执行与权限提升攻击。
• 其他工作涉及 MCP 市场偏好操纵（MPMA）、寄生工具链攻击、MCPSecBench 基准评测，以及 OAuth 增强工具定义、协议加固、安全网关等防御。论文指出这些工作主要刻画攻击面，而非静态恢复服务器实现中的漏洞数据流。

工具型 LLM 智能体安全

• 综述类：Deng et al. (2024)、He et al. (2024) 等综述工具型智能体的安全风险；作者认为工具使用扩大了 LLM 应用的攻击面。
• 间接提示注入：Abdelnabi et al. (2023)、Liu et al. (2023) 研究攻击者控制的外部内容重新进入模型上下文。论文指出这类工作与本文返回侧威胁模型相关，但通常在系统层面分析攻击、基准或智能体级分类，不对 MCP 服务器代码做静态推理。

基线与基准

• 基线工具：CodeQL（查询式静态分析）、Semgrep（轻量规则分析）、Snyk Code（商业语义 SAST，已宣布支持 MCP 输入源，主要针对 FastMCP 实现）、MCPScan（MCP 定向工具，结合规则匹配与 LLM 辅助分诊）。
• 评测基准：作者自建的 32 个已确认 MCP 漏洞案例（来自 GitHub Security Advisories、GitLab Advisory Database、NVD、OSV 等），以及 15,452 个真实 MCP 服务器仓库。

作者定位：与上述工作不同，本文用静态分析直接在 MCP 服务器代码中恢复请求侧与返回侧的跨信任边界违规（§6）。

整体思路：MCP-BiFlow 把 MCP 服务器安全建模为双向信任边界数据流问题，先恢复每个工具可达的入口点，再按 MCP 信任边界定义污点源与汇，最后做双向过程间传播并取交集、求精路径（Figure 3）。流程大体确定化，仅在局部语法不足以判断源可控性或防护有效性时使用 LLM 辅助。

MCP 入口点恢复（§3.1）

• 注册解析：从 10 种发布变体（Python 与 JS/TS）中恢复发布事实 P = {⟨t, n_p, h_p, σ_p⟩}，覆盖直接声明、显式注册 API、协议级发布等模式（Table 1）。
• 分发解析：从 16 种分发变体中恢复分发事实 D，覆盖协议分发、分支分发、注册表分发、反射分发四类，解析出工具名到具体处理器的映射。
• 入口点特化：把发布与分发事实组合成工具级分析单元 e = ⟨t, h, r⟩，使污点只沿该工具可达路径播种，而非整个分发器；无分发事实时回退到发布侧处理器。

MCP 特异污点规范（§3.2）

• 四类分析对象（Table 2）：请求边界源 S_req（如 request.params.arguments）、敏感操作汇 K_op（如 fetch(url, ...)）、外部内容源 S_ext（如 response.text()）、协议返回汇 K_ret（处理器的协议可见返回值）。
• 请求侧：直接暴露工具的形式参数视为源；分发式处理器只对非路由参数播种；对结构化访问器（arguments["path"]、解构、schema 校验别名）提升源语义；语义模糊的候选用 LLM 判断是否仍实质受请求方控制（Figure 4 给出简化提示词模板）。
• 返回侧：确定性识别器覆盖网络响应体、远程 JSON、文件内容、子进程输出、git 日志、pod 日志等外部内容载体；语法证据不足时切片生产者侧代码，用 LLM 分类该值是否为不可信外部内容载体；仅当返回值仍依赖外部源时才报告返回汇。

双向过程间污点分析（§3.3）

• 污点标签：τ(v) ⊆ {req, ext}；过程内按赋值、字段/容器、返回组装等规则传播（Figure 5 的 Rules 1、2、5）。
• 前向传播：从 S_req 出发沿调用图向 K_op 传播（Rules 3–4），计算请求可达区域 R^f_op = ReachForward(S_req, CG)，即可能被请求方数据影响的过程与符号值集合。
• 后向传播：从 K_ret 反向追踪返回值的符号贡献者，计算返回可达区域，判断返回值是否依赖 S_ext 而非固定字面量或自构造状态对象。
• 交集与路径求精：操作流要求 I_op = R^f(S_req) ∩ R^b(K_op) 构成有效数据流路径；返回流同理。路径求精用确定性规则抑制被有效防护（严格白名单、路径规范化加根目录检查、参数化查询、固定基 URL）失效的候选，仅语义模糊的防护交给 LLM 裁决；等价路径按处理器、汇点和根因合并。

实现

• 基于开源静态分析框架 YASA 实现原型；LLM 辅助由 gpt-5.3-codex-medium API 驱动（§4.1）。

实验设置

• 被测对象：MCP-BiFlow 及 4 个基线工具 CodeQL、Semgrep、Snyk Code、MCPScan（均为静态分析工具，非模型）。
• RQ1 基准：32 个已确认 MCP 漏洞案例，来自公开安全公告，人工筛选要求 MCP 相关性明确、安全证据可信、实现为 Python/JavaScript/TypeScript；覆盖命令与代码执行、文件系统访问、数据库与查询执行、SSRF。
• RQ2 语料：从 mcp.so、PulseMCP、MCPWorld 三个注册表收集，75,380 个 GitHub 链接经规范化与去重得 63,639 个仓库，规则过滤后保留 15,452 个：Python 8,047（52.1%）、TypeScript 4,977（32.2%）、JavaScript 2,428（15.7%）。
• 指标：RQ1 因基准只含漏洞案例，报告案例级检出数与召回率而非精确率；RQ2 报告候选簇数与人工评审确认的漏洞路径数。
• 评审方式：RQ2 由人工进行面向披露的评审，合并同一服务器相近汇点的近似重复轨迹；论文未报告评审人数与一致性。
• 环境：Ubuntu 22.04，两颗 64 核 AMD EPYC 9954、1024 GB 内存、6 张 A100 80GB；LLM 辅助用 gpt-5.3-codex-medium。

主结果

RQ1 案例级对比（据 Table 3，32 个案例的总检出数）：

工具	检出数（共 32）
CodeQL	1
Semgrep	8
Snyk Code	10
MCPScan	11
MCP-BiFlow	30

• 作者称 MCP-BiFlow 召回 93.8%，优于全部基线；并认为 MCPScan 这类 MCP 特异规则在缺少端到端双向恢复时仍不够。
• 两个漏报均在 JavaScript：CVE-2025-65513 需要把解码后的 MCP 参数重绑定到带默认值的对象解构参数，CVE-2025-61685 需要跨高阶迭代与闭包边界传播污点；作者归因于参数重绑定与跨闭包传播的现有缺口。
• Table 3 中 5 个 mcp-server-git/mcp-atlassian 案例对 MCP-BiFlow 标"-"，表示超出该工具被评估的能力边界（表注）。

RQ2：真实仓库大规模研究

• 产出与确认：15,452 个仓库产出 549 个重叠压缩候选簇（涉及 424 个服务器）；第一轮评审 278 个簇可报告、55 个需进一步判断、216 个被拒；最终确认 118 条漏洞路径，涉及 87 个服务器。
• 拒绝原因：122 例用户输入实际不控制请求目标，53 例目标固定或仅配置项，21 例本地校验使 shell 插值不可利用。
• 确认路径构成：111 条涉及代码执行，5 条查询执行，2 条 SSRF（Table 4；主要汇点 execAsync 60 条、execSync 28 条）。作者称候选与确认数的差距反映面向召回的候选生成加保守披露标准，而非直接精确率估计。
• 案例研究：mcp-server-text-editor 中请求侧路径使目录路径参数流入 execSync（Figure 6）；search-solodit-mcp 中外部 API 返回内容流入 eval（Figure 7），作者用其说明外部内容可跨越 MCP 交互后在多步之后到达危险操作。

RQ3：消融

据 Table 5，在 859 个已评审实例（424 确认、302 未决、133 拒绝）上：

表格较宽，可左右滑动

变体	确认	未决	拒绝	保留	总数
完整（M1+M2+M3）	424	302	133	726	859
去 M1（入口点恢复）	287	251	98	538	636
去 M2（LLM 源识别）	324	210	87	534	621
去 M3（LLM 防护校验）	424	368	67	792	859

• 作者解读：M1 与 M2 决定发现覆盖面，M3 决定分诊可靠性（把模糊案例转为可辩护的拒绝决定）。

其他消融与分析

• 论文未报告其他独立消融或参数分析；RQ1–RQ3 之外无额外定量实验。

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

• 范围限制（§5 Limitations）：MCP-BiFlow 针对跨边界不安全数据流，认证、授权、业务逻辑与部署缺陷不在范围内，除非表现为可分析的数据流违规。
• 元数据级攻击（§5）：工具描述投毒等元数据级攻击未被直接处理，除非这些产物传播进分析捕获的可执行代码路径。
• 误报挑战（§5）：作者称误报仍是主要挑战——流程可能过度近似攻击者控制能力、忽略有效的本地约束，或标记目标固定、仅配置项等不具实质攻击者影响的流。
• 完备性缺口（§5）：服务器依赖反射分发、运行时生成处理器或框架特异包装器时，完备性可能受损。
• LLM 依赖（§5）：真实世界评估面向披露，语义模糊案例需要 LLM 辅助裁决。
• 通用性主张（§5 Discussion）：作者称核心设计不绑定特定 SDK 或语言，可通过补充语言特异的注册、分发与汇点支持扩展到其他语言与工具服务框架——这是作者的主张而非已完成的扩展。

实验覆盖范围

• 被测对象为静态分析工具：MCP-BiFlow 与 CodeQL、Semgrep、Snyk Code、MCPScan 共 5 个（§4.1）。
• RQ1 基准为 32 个已确认漏洞案例，只含漏洞案例，因此只报告检出数与召回率，无精确率（§4.2）。
• RQ2 语料为 15,452 个仓库，仅含 Python、JavaScript、TypeScript 三种语言（作者称三者合计占所收集 MCP 服务器的近 80%）（§4.1）。
• RQ2 评审为人工面向披露评审，论文未报告评审人数、评审间一致性或每条路径的评审耗时。
• 流程中 LLM 辅助使用 gpt-5.3-codex-medium；论文未报告 LLM 裁决的调用次数、准确率或人工核对比例。

一篇关于 MCP 生态安全的静态分析论文：作者把 MCP 服务器安全建模为双向信任边界数据流问题——请求侧（请求方输入流向敏感操作）与返回侧（外部或敏感数据经 MCP 输出回流），并提出 MCP-BiFlow 框架。

• 方法：三阶段流水线——恢复工具级入口点（10 种发布变体、16 种分发变体）、绑定 MCP 特异污点语义（请求源、外部内容源、敏感操作汇、协议返回汇）、双向过程间传播加交集与路径求精；语义模糊的源与防护由 LLM（gpt-5.3-codex-medium）辅助裁决。
• 基准结果：在 32 个已确认 MCP 漏洞上检出 30 个（93.8% 召回），基线 CodeQL、Semgrep、Snyk Code、MCPScan 分别检出 1、8、10、11 个（Table 3）；两个漏报均在 JavaScript，涉及参数重绑定与跨闭包传播。
• 真实世界研究：15,452 个仓库产出 549 个候选簇，人工评审确认 87 个服务器的 118 条漏洞路径，其中 111 条涉及代码执行（Table 4）。
• 消融：去掉入口点恢复（M1）或 LLM 源识别（M2）会减少发现数，去掉 LLM 防护校验（M3）则削弱分诊质量（Table 5）。
• 作者结论：不安全数据流在 MCP 生态中不是边缘个案而是反复出现的结构性弱点；作者同时承认工具不覆盖认证授权、工具描述投毒等问题，误报仍是主要挑战，且模糊案例依赖 LLM 裁决。