PaperlayerView exact revision on arXiv

Source-linked AI summary

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

Zehua Zhang, Jie Hu, Pratham Hegde, Aditya Maheshbhai Gabani, Souradip Nath, Yibo Liu, Siyu Liu, Hongkai Chen, Hulin Wang, Zhuoer Lyu, Chang Zhu, Divij Handa, Yan Shoshitaishvili, Tiffany Bao, Ruoyu Wang, Adam Doupe

arXiv:2609.10854v1cs.CRcs.AI

TL;DR

The paper addresses vulnerability analysis when source code, deployment details, or runtime interaction are unavailable or unsafe. It proposes no-box analysis, which uses functionality metadata to infer vulnerability-relevant flows and generate Theory-of-Concepts, and evaluates MCPSEC on MCP servers. MCPSEC recovered 94 of 95 confirmed vulnerabilities with 98.9% recall, compared with 84.2% recall for an LLM baseline.

  • Problem

    Conventional vulnerability analysis requires system access or dynamic interaction, which may be unavailable or unsafe for closed-source, remotely hosted, critical, or proprietary systems.

  • Method

    No-box vulnerability analysis uses metadata to infer irreducible data flows, enrich them with plausible implementation details, and produce Theory-of-Concepts for later validation.

  • Results

    MCPSEC recovered 94 of 95 confirmed vulnerabilities with 98.9% recall, compared with 80 vulnerabilities and 84.2% recall for the LLM baseline.

  • Takeaways & Limitations

    The results demonstrate that metadata alone can support practical vulnerability analysis and can serve as a low-overhead triage layer before white-box or runtime validation.

  • Takeaways & Limitations

    The evaluation targets high-profile MCP servers with external-content-bearing tools, and the method may produce more false positives or fewer useful hypotheses in ecosystems with poorer specifications.

Abstract

from arXiv · show

Conventional vulnerability analysis relies on either system access or dynamic interaction, all of which may be unavailable to third-party analysts auditing closed-source, remotely hosted, critical in situ systems, or commercially gated software. Therefore, we propose a new paradigm of no-box vulnerability analysis in which neither access nor runtime interaction is available, and only functionality metadata is available. Such metadata defines the intended behavior of the system, including its inputs, outputs, and side effects, while constraining the space of implementations consistent with that behavior. We propose hypothesizing about vulnerabilities that exist across all possible implementations of a given system metadata, without observing or interacting with the target system. An analyst can later validate these hypotheses when additional access is available. We showcase the feasibility of no-box vulnerability analysis through implementing a prototype called MCPSEC, which audits Model Context Protocol (MCP) servers for indirect prompt injection vulnerabilities using only the tool metadata exposed at server registration time. We evaluate MCPSEC on 20 widely deployed MCP servers comprising 177 tools, among which human evaluators confirm 95 vulnerable tools. MCPSEC identified 143 tools as vulnerable, and for each vulnerable tool, it produced a hypothesized vulnerability along with exploitation technique. Using metadata alone, MCPSEC predicted 94 (98.9% recall) real verified vulnerabilities, compared against an LLM baseline with 80 (84.2% recall). Overall, our results introduce no-box vulnerability analysis as a new analysis paradigm and demonstrate its practical feasibility in realistic systems.

I. INTRODUCTION

The paper introduces no-box vulnerability analysis for settings where source code, deployment access, or safe runtime interaction is unavailable. It instantiates the paradigm as MCPSEC, which uses MCP tool metadata to hypothesize indirect prompt injection vulnerabilities and achieves high recall against human-confirmed cases.

  • Motivation: No-box vulnerability analysis uses system metadata to reason about potential vulnerabilities without source-code access or runtime interaction.It is intended for proprietary, remotely hosted, critical, or ethically unsafe systems.
  • Artifacts: A Theory-of-Concept describes a plausible exploitation scenario but requires later testing against the concrete implementation for verification.Developers or analysts can use it to construct a proof of concept or reason about mitigations.
  • Approach: MCPSEC infers attacker-controlled data flows from MCP tool metadata, enriches them with plausible operations, and outputs Theory-of-Concepts for later validation.The framework considers attacker capabilities and vulnerability preconditions when synthesizing exploitation scenarios.
  • Evaluation: 94 of 95 human-confirmed vulnerabilities were recovered with 98.9% recall, compared with 80 vulnerabilities and 84.2% recall for the LLM baseline.The evaluation covered 177 tools from 20 widely deployed MCP servers.
  • Ecosystem finding: 132 tools, or 92.3% of those examined, lacked sanitization for external data reaching the LLM context.The finding concerns public web, browser, SaaS, infrastructure, and cloud-oriented MCP tools.

II. BACKGROUND

The background contrasts access-dependent vulnerability-analysis paradigms with indirect prompt injection risks in LLM applications. It then describes MCP as a standardized interface whose tools retrieve external data and return free-form results to LLM hosts.

  • Analysis paradigms: White-box, gray-box, and black-box analysis all require implementation evidence or the ability to interact with the target system.No-box analysis addresses settings where such access is unavailable or unsafe.
  • Indirect Prompt Injection: Indirect prompt injection occurs when attacker-controlled instructions enter an LLM context through external content and influence subsequent model actions.Possible consequences include unauthorized tool invocation and credential exfiltration.
  • Indirect Prompt Injection: A source-to-sink data flow alone does not establish IPI vulnerability because the payload must retain instructional fidelity and semantic meaning.External-data consumption therefore does not necessarily imply exploitability.
  • Indirect Prompt Injection: IPI can persist across web pages, documents, and tool outputs, while agentic attacks may cascade into tool-call chains and data exfiltration.Existing defenses remain inadequate against adaptive adversaries or human red teaming.
  • Model Context Protocol: MCP standardizes access to external data sources and tools through servers that expose tool names, natural-language descriptions, and typed parameters.A typical interaction registers metadata, invokes a selected tool, and returns its free-form response to the LLM host.

III. NO-BOX VULNERABILITY ANALYSIS

No-box vulnerability analysis treats metadata as a partial description of possible implementations and focuses on vulnerability-relevant properties rather than reconstructing deployed code. It derives irreducible data flows, enriches them with speculative conditions, and produces Theory-of-Concepts for later validation.

  • Analytical framework: The framework distinguishes necessary vulnerabilities, present in every implementation consistent with available evidence, from plausible vulnerabilities, present in at least one.No-box analysis therefore evaluates what vulnerabilities could arise under explicit implementation assumptions.
  • The No-Box Setting: The no-box setting uses only metadata to identify vulnerabilities that could arise across implementations consistent with the target’s described functionality.The resulting hypotheses include implementation assumptions and can later be synthesized into concrete exploitation scenarios.
  • Data Flow Speculation and Risk Analysis: Metadata may imply an irreducible data flow: the minimal implementation-agnostic relationship preserved by every conforming implementation.This abstraction captures essential entities and transformations without specifying the exact implementation.
  • Data Flow Speculation and Risk Analysis: No-box analysis annotates irreducible flows with hypothesized parsers, transformations, validation, and sanitization before evaluating vulnerability preconditions.These annotations generate alternative speculated data flows for risk analysis.
  • Theory-of-Concepts: A Theory-of-Concept synthesizes a speculated flow and risk analysis into an attack scenario covering affected functionality, attacker capabilities, implementation assumptions, and security impact.Unlike a proof of concept, it does not execute or verify the scenario against a concrete implementation.

IV. FINDING IPI VULNERABILITIES IN MCP SERVERS

The paper models MCP servers as no-box targets using published tool metadata, while defining attacker-controlled sources, LLM-context sinks, and threat assumptions for indirect prompt injection analysis.

  • A. MCP Servers as No-box Targets: 3,007 of 18,770 active MCP servers (16.0%) lacked publicly available implementations under the paper’s definition.The estimate concerns servers declaring remote endpoints without a released package or source repository URL.
  • A. MCP Servers as No-box Targets: MCP no-box analysis uses tool names, descriptions, and JSON-Schema inputs as metadata describing intended functionality without implementation details.The model treats attacker-controlled external data as vulnerability sources and LLM contexts as sinks.
  • B. Threat Model: The threat model allows remote attackers to control source content consumed by tools, but excludes compromise of MCP servers, clients, or LLMs.Control is assigned to provenance of external content rather than compromise of its hosting medium.
  • B. Threat Model: Indirect prompt injection occurs when a legitimate tool introduces attacker-controlled instructions into the LLM context, diverting the agent from benign user intent.The corresponding security property is context integrity.

C. Instantiating No-box Analysis for IPI

MCPSEC instantiates no-box analysis by speculating about MCP data flows from metadata, validating over-approximated paths, and assessing them against four IPI risk axes to produce ToCs.

  • C. Instantiating No-box Analysis for IPI: Data-flow speculation hypothesizes implementation-dependent sources, storage, parsing, transformations, field selection, validation, and sanitization when metadata leaves them uncertain.A source-to-context relationship may itself be treated as a plausible path when metadata suggests but does not entail external-content contribution.
  • C. Instantiating No-box Analysis for IPI: The risk rubric evaluates payload fidelity, attacker controllability, semantic executability, and sanitization as independent IPI preconditions.These axes distinguish direct propagation, attacker access, instruction interpretability by the LLM, and defensive processing.
  • C. Instantiating No-box Analysis for IPI: A coherent path satisfying all four preconditions yields a metadata-grounded vulnerability hypothesis whose ToC records the tool, attacker source, path, defenses, and potential agent effect.The explicit conditions make the hypothesis suitable for later validation against source code or runtime instrumentation.
  • C. Instantiating No-box Analysis for IPI: MCPSEC’s two-stage pipeline first assembles metadata-admitted data flows, then evaluates each flow against four risk axes and outputs a ToC for vulnerable flows.Each ToC describes a concrete attack scenario with per-axis risk labels.
  • C. Instantiating No-box Analysis for IPI: Stage 1 deliberately over-approximates candidate flows, combining LLM entity discovery and tool profiling with deterministic assembly and structural validation.The over-approximation is intended to maximize coverage of analyzable flows when metadata omits implementation entities and edges.

B. Stage 2: LLM-Assisted Risk Assessment

Stage 2 evaluates validated speculative flows with an LLM risk rubric and produces risk labels and ToCs, using a metadata-only baseline comparison before human evaluation.

  • B. Stage 2: LLM-Assisted Risk Assessment: MCPSEC’s rubric distinguishes risk across payload fidelity, attacker controllability, semantic executability, and sanitization rather than treating all speculative flows equally.For example, verbatim issue comments pose a different threat from a numeric account balance.
  • B. Stage 2: LLM-Assisted Risk Assessment: The Stage 2 LLM evaluates each validated flow against the four-axis rubric and emits risk labels plus a ToC when one flow satisfies all four preconditions.The ToC narrates a concrete indirect prompt-injection scenario for downstream checking.
  • B. Stage 2: LLM-Assisted Risk Assessment: The generated ToC serves as an illustrative attack scenario that downstream analysts can test against source code or runtime instrumentation.Per-axis labels provide an audit scaffold for independently cross-checking the narrative.
  • B. Stage 2: LLM-Assisted Risk Assessment: MCPSEC identified 143 plausible vulnerability candidates among 177 tools, while the prompting-based LLM baseline identified 97 candidates.The baseline preserved the threat model, rubric, and ToC requirements but omitted MCPSEC’s staged flow reconstruction and graph-conditioned reasoning.

VII. EVALUATION

The evaluation progressively validates metadata-derived MCPSEC hypotheses with metadata, source-code, and benign runtime evidence, then compares detection against controlled PoC labels.

  • A. Evaluation Design and Annotation Protocol: The staged protocol moves from metadata-only judgments to source-code analysis and then benign dynamic execution to test predicted flows, transformations, sanitization, and runtime manifestation.RQ1 assesses metadata-based plausibility; RQ2 adds white-box static evidence; RQ3 adds white-box dynamic evidence.
  • VII. EVALUATION: 95 of 177 sampled tools were confirmed vulnerable through ethically controlled prompt-injection PoCs, while unsuitable tools were filtered from PoC construction.The confirmed-vulnerability subset is used to score MCPSEC and the baseline.
  • A. Evaluation Design and Annotation Protocol: Human annotation agreement was 89.6% for ToC judgments, 80.1% for rubric and data-path labels, and 82.5% for runtime-derived observations.These are pre-discussion agreement values before disagreements were adjudicated.

B. RQ1: Are MCPSEC-Generated ToCs and Risk Labels Plausible from Metadata Alone?

RQ1 finds that metadata alone supports largely plausible MCPSEC vulnerability hypotheses, though agreement weakens for implementation-dependent properties such as sanitization. MCPSEC outperforms direct prompting on matched metadata-only evaluations.

  • Metadata-only plausibility: 96.5% of 143 candidates identify plausible external sources, while 85.3% yield coherent attack narratives and 82.9% mean agreement across risk axes.These judgments assess metadata-grounded plausibility before source-code or runtime validation.
  • RQ1 results: 86.9% mean agreement versus 74.5% for the LLM baseline shows MCPSEC’s metadata-only analysis improves matched-tool judgments by 12.4 percentage points.Both methods receive the same registration metadata, threat model, rubric, and ToC requirements.
  • Risk-axis agreement: Sanitization is the weakest risk axis at 79.0% agreement, largely because MCPSEC often labels transformations as partial filtering while evaluators judge them ineffective.Semantic_Executability and Attacker_Controllability each reach 84.6% agreement.
  • Source-code validation: Source-code validation leaves 75.5% of predicted ToCs plausible or partially plausible, with 24.5% judged implausible.The breakdown is 73.4% Plausible, 2.1% Partially Plausible, and 24.5% Implausible; incorrect source identification contributes strongly to implausibility.
  • Source-code validation: Implementation details reduce agreement most for Semantic_Executability, from 84.6% under metadata alone to 60.8% with source-code evidence.Payload_Fidelity also falls from 83.2% to 66.4%, while Sanitization remains relatively stable.
  • Failure modes: Data loss and output transformation explain many implausible ToCs, affecting 63.2% and 57.9% of the 38 examined flows, respectively.Other identified factors include effective sanitization in 15.8% and wrong-source identification in 23.7%.

D. RQ3: Do ToC-Identified Data Flows Reach the LLM Context at Runtime?

RQ3 tests whether metadata-derived flows reach the LLM context during execution, using source and sink instrumentation with benign parameters. Most flows reach the context in potentially instructional forms, although reachability does not always imply attack-capable fidelity.

  • Evaluation design: Runtime testing uses benign parameters to validate source-to-sink reachability and payload fidelity, while end-to-end exploitability is evaluated separately.Evaluators instrument a source immediately after remote retrieval and a sink at the tool’s return statement.
  • Evaluation design: RQ3 classifies each flow by reachability—complete, partial, metadata-only, or none—and output form, including verbatim, formatted, JSON-wrapped, or derived data.The cross-product of these properties determines the runtime verdict.
  • Runtime results: 76.2% of flows reach the LLM context with attacker-controllable data, either verbatim or through transformations preserving injection-capable content.The 143 flows comprise 22 Reachable-Verbatim, 87 Reachable-Modified, 18 Reachable-Metadata, and 16 Not Reachable.
  • Runtime validation: Among 105 source-code-plausible flows, 93.3% are runtime-reachable, whereas 77.1% of implausible flows are also reachable but often lack usable payload fidelity.Reachability alone therefore does not establish an exploitable injection channel.
  • Metadata cues: Output-shape cues appear in 46.2% of flows and correspond to higher plausibility judgments: 86.4% with cues versus 62.3% without them.Such cues help assess plausibility but are less informative about external-data fidelity.
  • RQ4 scope: The full 177-tool evaluation confirms 95 vulnerable tools, but the remaining 82 are not established negatives, so recall is exact while precision is only a lower bound.The confirmation subset is used to measure vulnerability recovery through ethically controlled PoC testing.

F. Case Studies

MCPSEC’s case studies show both the practical power and access limitations of metadata-derived vulnerability hypotheses. One ToC produced a reproducible exploit, while another required privileged access for validation.

  • A metadata-derived ToC for evaluate_script led to a reproducible exploit that exfiltrated browser credentials through attacker-controlled JavaScript.Injected page content induced JavaScript execution with Chromium’s network privileges, allowing localStorage and document.cookie to be sent remotely.
  • The evaluate_script case demonstrates that injected page content can induce JavaScript execution with Chromium’s network privileges, enabling private-data access and exfiltration.
  • The slack/usergroups_update ToC described a conditional injection flow whose validation required paid-workspace access, an OAuth scope, and an authorized workspace role.Without those privileges, black-box testing could not obtain a successful tool response, although metadata still exposed the assumptions for later testing.
  • No-box feasibility depends on whether exploitation conditions can be defined from metadata, making some vulnerability classes more suitable than others.SQL injection, XSS, SSRF, and path traversal are described as highly suitable, whereas memory corruption and race conditions depend more heavily on low-level implementation details.
  • No-box analysis can serve as a first-pass screening layer, producing ToCs for prioritizing later white-box, gray-box, or runtime validation.The approach is described as having minimal deployment or configuration overhead.

B. A Conceptual Gap in MCP Security

The paper identifies a conceptual gap in conventional vulnerability analysis: existing paradigms require observing or interacting with targets, whereas no-box analysis reasons from externally observable metadata alone. It also discusses ecosystem conditions, practical screening uses, and important scope limitations.

  • The evaluation targets high-profile external-content-bearing servers rather than a neutral ecosystem sample, so it does not estimate vulnerability prevalence across MCP.
  • MCPSEC analyzes tools independently along single external-source-to-context paths, leaving multihop chains, host-side prompt construction, memory accumulation, and inter-server compositions out of scope.
  • The paper notes that no-box feasibility and performance may depend on vulnerability class and target-system metadata quality, with broader generalizability left for future work.
  • Traditional white-box, gray-box, and black-box approaches differ in access assumptions but all rely on observing or interacting with the target system.
  • No-box vulnerability analysis removes the requirement for source-code access, deployment access, or runtime interaction by reasoning solely from externally observable metadata.

B. Large Language Models and Indirect Prompt Injection

LLMs process instructions and external data in a shared context, enabling indirect prompt injection through retrieved content and tool outputs. The paper introduces MCPSEC as a metadata-only pre-deployment approach and reports high agreement with human evaluation, while noting ethical and evidentiary boundaries.

  • B. Large Language Models and Indirect Prompt Injection: LLMs’ shared processing of instructions and external data creates a pathway for indirect prompt injection through external sources.
  • B. Large Language Models and Indirect Prompt Injection: Indirect prompt injection can propagate through agentic tool chains, causing data exfiltration or unintended actions, while existing defenses remain vulnerable to adaptive attacks.
  • B. Large Language Models and Indirect Prompt Injection: Existing pre-deployment approaches such as AgentFuzz and AgentArmor require execution access, limiting use when the LLM or surrounding system is inaccessible.
  • X. CONCLUSION: MCPSEC implements no-box vulnerability analysis by inferring irreducible data flows from registration-time metadata and producing Theory-of-Concepts for downstream validation.
  • X. CONCLUSION: MCPSEC recovers 94 of 95 confirmed vulnerabilities, achieving 98.9% recall compared with 80 vulnerabilities and 84.2% recall for the LLM baseline.
  • X. CONCLUSION: Metadata-only analysis can identify vulnerable data flows when conventional access is unavailable and can triage targets for later white-box or runtime validation.
  • ETHICAL CONSIDERATIONS: The evaluation’s ethical protocol means many reachable flows are not treated as confirmed vulnerabilities because benign inputs do not prove exploitability.
  • ETHICAL CONSIDERATIONS: Experiments were conducted locally and in containers, with attack-semantic payloads kept out of remote third-party data sources.

APPENDIX A ADDITIONAL INFORMATION OF E V A L U A T E_S CRIPT CASE

The appendix details how MCPSEC derives an injection hypothesis from evaluate_script metadata and how the case study validates reachability and exploitability under an ethically controlled protocol. The results include nondeterministic agent behavior and explicit sampling exclusions.

  • The evaluate_script registration exposes a JavaScript function input executed in the selected page, with an example advertising outbound HTTP capability.
  • MCPSEC uses this metadata to infer an attacker-controlled page-content-to-tool-to-LLM-context flow for downstream reasoning.
  • Across three local-state-exfiltration runs, the agent followed the injection in two runs and refused in one.
  • A tool was labeled vulnerable only when the source was attacker-controllable, the tool retrieved it under realistic parameters, and the content reached the tool output.
  • The evaluation separated inert remote canaries from locally substituted attack payloads, preventing adversarial text from being written to live third-party services.
  • PoC construction excluded tools that were inaccessible, destructive, third-party-visible, structurally non-string, or lacking external content; 95 tools were labeled vulnerable under this protocol.
Loading 2609.10854v1…