Unsafe by Flow: Revealing bidirectional data flow risks in the MCP ecosystem

Core problem: bidirectional unsafe data flows across trust boundaries in MCP servers (request-side propagation and return-side propagation) are difficult for existing static analysis tools to detect.

• Scenario and importance: MCP (Model Context Protocol) was proposed by Anthropic in late 2024, and the number of servers grew to nearly 60k within 16 months (§1). The authors argue that tool inputs may trigger privileged operations and tool outputs may re-enter LLM reasoning, and that both directions are security-relevant.
• Shortcomings of existing methods: The authors state that existing MCP security research mainly characterizes ecosystem risks, attack patterns, and defenses; general-purpose analyzers such as CodeQL and Semgrep were not designed to recover MCP interaction structures end to end (§1).
• Three specific difficulties (§1, §2.4): tool registration and distribution patterns are diverse, making entry points hard to identify; general taint templates do not match MCP trust boundaries; and vulnerabilities often manifest only on complete tool-level execution paths.
• Proposed in the paper: MCP-BiFlow, a static analysis framework built around MCP-aware entry point recovery, protocol-specific taint modeling, and bidirectional interprocedural propagation, evaluated on 32 confirmed vulnerabilities and 15,452 real repositories.
• Threat model (§2.3):
  • Target: detect request-side propagation (requester-controlled data reaching sensitive operations) and return-side propagation (external or internal sensitive data flowing out through MCP-visible outputs).
  • Attacker knowledge/capability: does not control the server internals, source code, host, or deployment pipeline; provides crafted inputs through normal interaction channels, or controls external content sources consumed by the server (third-party APIs, public repositories, web pages, remote databases).
  • Victim system: MCP host, client, and server implemented by non-malicious parties, with an uncompromised runtime environment.
  • Exclusions: attacks that rely on compromise of the codebase, supply chain, or deployment infrastructure, and authentication, authorization, and business logic issues that do not manifest as cross-boundary data flows.

MCP security research

• Hasan et al. (2025): measured open-source MCP servers and identified common vulnerability categories and maintenance weaknesses. Hou et al. (2025): surveyed the MCP ecosystem, threat models, and open research directions.
• Zhao et al. (2025): provided a taxonomy of malicious MCP server behaviors and demonstrated proof-of-concept exploits; Radosevich and Halloran (2025): showed that current MCP workflows remain vulnerable to code execution and privilege escalation attacks.
• Other work involves MCP marketplace preference manipulation (MPMA), parasitic toolchain attacks, the MCPSecBench benchmark evaluation, and defenses such as OAuth-enhanced tool definitions, protocol hardening, and security gateways. The paper notes that these works mainly characterize the attack surface rather than statically recovering vulnerable data flows in server implementations.

Tool-based LLM agent security

• Surveys: Deng et al. (2024), He et al. (2024), and others survey the security risks of tool-based agents; the authors argue that tool use expands the attack surface of LLM applications.
• Indirect prompt injection: Abdelnabi et al. (2023) and Liu et al. (2023) study attacker-controlled external content re-entering the model context. The paper notes that this line of work is related to the return-side threat model in this paper, but typically analyzes attacks, benchmarks, or agent-level taxonomies at the system level and does not perform static reasoning over MCP server code.

Baselines and benchmarks

• Baseline tools: CodeQL (query-based static analysis), Semgrep (lightweight rule analysis), Snyk Code (commercial semantic SAST, which has announced support for MCP input sources, mainly targeting FastMCP implementations), and MCPScan (an MCP-targeted tool combining rule matching with LLM-assisted triage).
• Evaluation benchmarks: the authors' self-built 32 confirmed MCP vulnerability cases (from sources such as GitHub Security Advisories, GitLab Advisory Database, NVD, and OSV), and 15,452 real MCP server repositories.

Authors' positioning: unlike the above work, this paper uses static analysis to directly recover cross-trust-boundary violations on the request side and return side in MCP server code (§6).

Overall approach: MCP-BiFlow models MCP server security as a bidirectional trust-boundary data flow problem: first recover the entry points reachable by each tool, then define taint sources and sinks according to MCP trust boundaries, and finally perform bidirectional interprocedural propagation and take the intersection and refine paths (Figure 3). The pipeline is largely deterministic, using LLM assistance only when local syntax is insufficient to judge source controllability or defense effectiveness.

MCP entry point recovery (§3.1)

• Registration resolution: recover publication facts P = {⟨t, n_p, h_p, σ_p⟩} from 10 publication variants (Python and JS/TS), covering patterns such as direct declaration, explicit registration APIs, and protocol-level publication (Table 1).
• Dispatch resolution: recover dispatch facts D from 16 dispatch variants, covering four categories—protocol dispatch, branch dispatch, registry dispatch, and reflective dispatch—and resolve the mapping from tool names to concrete handlers.
• Entry point specialization: combine publication and dispatch facts into tool-level analysis units e = ⟨t, h, r⟩, so that taint is seeded only along paths reachable by that tool rather than the entire dispatcher; fall back to the publication-side handler when no dispatch facts exist.

MCP-specific taint specification (§3.2)

• Four analysis object types (Table 2): request boundary sources S_req (e.g., request.params.arguments), sensitive operation sinks K_op (e.g., fetch(url, ...)), external content sources S_ext (e.g., response.text()), and protocol return sinks K_ret (the protocol-visible return value of a handler).
• Request side: formal parameters of directly exposed tools are treated as sources; for dispatcher-style handlers, only non-routing parameters are seeded; source semantics are lifted for structured accessors (arguments["path"], destructuring, schema-validation aliases); semantically ambiguous candidates use an LLM to judge whether they are still substantively controlled by the requester (Figure 4 gives a simplified prompt template).
• Return side: deterministic recognizers cover external content carriers such as network response bodies, remote JSON, file contents, subprocess output, git logs, and pod logs; when syntactic evidence is insufficient, slice the producer-side code and use an LLM to classify whether the value is an untrusted external content carrier; report a return sink only when the return value still depends on an external source.

Bidirectional interprocedural taint analysis (§3.3)

• Taint labels: τ(v) ⊆ {req, ext}; intraprocedurally propagated according to rules for assignment, fields/containers, return assembly, etc. (Rules 1, 2, 5 in Figure 5).
• Forward propagation: propagate from S_req along the call graph toward K_op (Rules 3–4), computing the request-reachable region R^f_op = ReachForward(S_req, CG), i.e., the set of procedures and symbolic values that may be influenced by requester data.
• Backward propagation: trace backward from K_ret the symbolic contributors to the return value, compute the return-reachable region, and determine whether the return value depends on S_ext rather than fixed literals or self-constructed state objects.
• Intersection and path refinement: operation flows require I_op = R^f(S_req) ∩ R^b(K_op) to form a valid data flow path; the same applies to return flows. Path refinement uses deterministic rules to suppress candidates invalidated by effective defenses (strict allowlists, path normalization plus root directory checks, parameterized queries, fixed base URLs), leaving only semantically ambiguous defenses to LLM adjudication; equivalent paths are merged by handler, sink, and root cause.

Implementation

• A prototype is implemented on the open-source static analysis framework YASA; LLM assistance is driven by the gpt-5.3-codex-medium API (§4.1).

Experimental Setup

• Subjects under test: MCP-BiFlow and 4 baseline tools, CodeQL, Semgrep, Snyk Code, and MCPScan (all static analysis tools, not models).
• RQ1 benchmark: 32 confirmed MCP vulnerability cases, from public security advisories, manually screened to require clear MCP relevance, credible security evidence, and Python/JavaScript/TypeScript implementations; covering command and code execution, filesystem access, database and query execution, and SSRF.
• RQ2 corpus: collected from three registries, mcp.so, PulseMCP, and MCPWorld; 75,380 GitHub links were normalized and deduplicated to 63,639 repositories, and after rule-based filtering 15,452 were retained: Python 8,047 (52.1%), TypeScript 4,977 (32.2%), JavaScript 2,428 (15.7%).
• Metrics: because the RQ1 benchmark contains only vulnerability cases, RQ1 reports case-level detection counts and recall rather than precision; RQ2 reports the number of candidate clusters and the number of vulnerability paths confirmed by manual review.
• Review method: RQ2 was reviewed manually with a disclosure-oriented review, merging near-duplicate traces to nearby sinks on the same server; the paper does not report the number of reviewers or agreement.
• Environment: Ubuntu 22.04, two 64-core AMD EPYC 9954, 1024 GB memory, 6 A100 80GB; LLM assistance used gpt-5.3-codex-medium.

Main Results

RQ1 case-level comparison (per Table 3, total detections across the 32 cases):

Tool	Detections (of 32)
CodeQL	1
Semgrep	8
Snyk Code	10
MCPScan	11
MCP-BiFlow	30

• The authors state that MCP-BiFlow achieves 93.8% recall, outperforming all baselines; and argue that MCP-specific rules such as those in MCPScan are still insufficient without end-to-end bidirectional recovery.
• Both misses are in JavaScript: CVE-2025-65513 requires rebinding decoded MCP parameters to object destructuring parameters with default values, and CVE-2025-61685 requires propagating taint across higher-order iteration and closure boundaries; the authors attribute these to existing gaps in parameter rebinding and cross-closure propagation.
• In Table 3, 5 mcp-server-git/mcp-atlassian cases are marked "-" for MCP-BiFlow, indicating they are beyond the capability boundary for which the tool was evaluated (table note).

RQ2: Large-Scale Study of Real Repositories

• Output and confirmation: 15,452 repositories produced 549 overlapping compressed candidate clusters (involving 424 servers); in the first round of review, 278 clusters were reportable, 55 required further judgment, and 216 were rejected; ultimately 118 vulnerability paths were confirmed, involving 87 servers.
• Rejection reasons: in 122 cases user input did not actually control the request target, in 53 cases the target was fixed or only a configuration item, and in 21 cases local validation made shell interpolation unexploitable.
• Composition of confirmed paths: 111 involve code execution, 5 query execution, and 2 SSRF (Table 4; the main sinks are execAsync with 60 and execSync with 28). The authors state that the gap between candidate and confirmed counts reflects recall-oriented candidate generation plus conservative disclosure standards, rather than a direct precision estimate.
• Case studies: in mcp-server-text-editor, a request-side path causes a directory path parameter to flow into execSync (Figure 6); in search-solodit-mcp, content returned by an external API flows into eval (Figure 7), which the authors use to illustrate that external content can cross an MCP interaction and reach a dangerous operation after multiple steps.

RQ3: Ablation

Per Table 5, on 859 reviewed instances (424 confirmed, 302 undecided, 133 rejected):

Swipe horizontally to read the table

Variant	Confirmed	Undecided	Rejected	Retained	Total
Full (M1+M2+M3)	424	302	133	726	859
Without M1 (entry point recovery)	287	251	98	538	636
Without M2 (LLM source identification)	324	210	87	534	621
Without M3 (LLM guardrail validation)	424	368	67	792	859

• Authors' interpretation: M1 and M2 determine discovery coverage, and M3 determines triage reliability (turning ambiguous cases into defensible rejection decisions).

Other Ablations and Analyses

• The paper does not report other independent ablations or parameter analyses; there are no additional quantitative experiments beyond RQ1–RQ3.

Limitations and future directions noted by the authors

• Scope limitations (§5 Limitations): MCP-BiFlow targets cross-boundary unsafe data flows; authentication, authorization, business logic, and deployment flaws are out of scope unless they manifest as analyzable data flow violations.
• Metadata-level attacks (§5): metadata-level attacks such as tool description poisoning are not directly handled unless these artifacts propagate into executable code paths captured by the analysis.
• False positive challenges (§5): the authors state that false positives remain a major challenge—the pipeline may over-approximate attacker control capabilities, ignore effective local constraints, or flag flows with fixed targets or configuration-only items that have no substantive attacker impact.
• Completeness gaps (§5): completeness may suffer when servers rely on reflective dispatch, runtime-generated handlers, or framework-specific wrappers.
• LLM dependence (§5): the real-world evaluation is disclosure-oriented, and semantically ambiguous cases require LLM-assisted adjudication.
• Generality claim (§5 Discussion): the authors claim the core design is not tied to a specific SDK or language and can be extended to other languages and tool service frameworks by adding language-specific registration, dispatch, and sink support—this is the authors' claim rather than a completed extension.

Experimental coverage

• The subjects under test are static analysis tools: MCP-BiFlow plus CodeQL, Semgrep, Snyk Code, and MCPScan, 5 in total (§4.1).
• The RQ1 benchmark consists of 32 confirmed vulnerability cases and contains only vulnerability cases, so only detection counts and recall are reported, with no precision (§4.2).
• The RQ2 corpus consists of 15,452 repositories and contains only three languages: Python, JavaScript, and TypeScript (the authors state that together these account for nearly 80% of the collected MCP servers) (§4.1).
• The RQ2 review is a manual disclosure-oriented review; the paper does not report the number of reviewers, inter-reviewer agreement, or review time per path.
• LLM assistance in the pipeline uses gpt-5.3-codex-medium; the paper does not report the number of LLM adjudication calls, accuracy, or the proportion manually checked.

A static analysis paper on MCP ecosystem security: the authors model MCP server security as a bidirectional trust-boundary data flow problem—request side (requester input flowing to sensitive operations) and return side (external or sensitive data flowing back through MCP outputs)—and propose the MCP-BiFlow framework.

• Method: a three-stage pipeline—recovering tool-level entry points (10 publication variants, 16 distribution variants), binding MCP-specific taint semantics (request sources, external content sources, sensitive operation sinks, protocol return sinks), and bidirectional interprocedural propagation plus intersection and path refinement; semantically ambiguous sources and guards are adjudicated with LLM assistance (gpt-5.3-codex-medium).
• Benchmark results: detected 30 of 32 confirmed MCP vulnerabilities (93.8% recall); the baselines CodeQL, Semgrep, Snyk Code, and MCPScan detected 1, 8, 10, and 11 respectively (Table 3); both misses are in JavaScript and involve parameter rebinding and cross-closure propagation.
• Real-world study: 15,452 repositories produced 549 candidate clusters, and manual review confirmed 118 vulnerability paths in 87 servers, of which 111 involve code execution (Table 4).
• Ablation: removing entry point recovery (M1) or LLM source identification (M2) reduces the number of findings, while removing LLM guard validation (M3) weakens triage quality (Table 5).
• Authors' conclusion: unsafe data flows are not an edge case in the MCP ecosystem but a recurring structural weakness; the authors also acknowledge that the tool does not cover issues such as authentication and authorization or tool description poisoning, that false positives remain a major challenge, and that ambiguous cases depend on LLM adjudication.