Skip to content

Back to the catalog

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

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

This paper proposes no-box vulnerability analysis, a new paradigm for auditing systems using only functionality metadata when neither system access nor runtime interaction is available. The authors build MCPSEC, a prototype that audits Model Context Protocol servers for indirect prompt injection vulnerabilities purely from tool metadata exposed at server registration, evaluating it against 20 widely-deployed MCP servers with 177 tools where human evaluators confirmed 95 vulnerable tools; MCPSEC achieved 98.9% recall versus 84.2% for an LLM baseline, also producing hypothesized exploitation techniques per finding.

TL;DR A metadata-only auditing prototype called MCPSEC finds indirect prompt injection vulnerabilities in MCP server tool descriptions with 98.9% recall, no runtime access needed.
Open original ↗
Document

What it is

A paper (arXiv:2609.10854, Arizona State University) proposing no-box vulnerability analysis and its prototype MCPSEC, which audits MCP servers for indirect prompt injection (IPI) using only the tool metadata exposed at registration — no source, no binary, no runtime interaction. The summary gives the headline recall numbers; what it omits is the methodology and the ecosystem finding, both of which are what an engineer would actually act on.

How it works

The core mechanism is the irreducible data flow: the minimal source-to-sink skeleton that every implementation conforming to the metadata must contain. From metadata, MCPSEC infers flows from attacker-controllable sources into the LLM context, then annotates each with hypothesized security conditions (parsers, transformations, sanitization) to produce speculated data flows. Each speculated flow is checked against exploitation preconditions; if at least one metadata-consistent flow satisfies them all, MCPSEC emits a Theory-of-Concept (ToC) — an explicit attack scenario (affected function, attacker role, implementation assumptions, impact) meant to be validated into a PoC once access is available. Implemented as a multi-stage LLM reasoning pipeline.

A key distinction the paper draws: for IPI, a source-to-sink flow alone is not sufficient. A payload is syntactically indistinguishable from legitimate content, so the flow must additionally preserve the payload's instructional fidelity and semantic meaning. This is why generic dataflow reasoning under-detects and why their precondition modeling matters.

Findings worth acting on

  • 92.3% (132 of 177 tools) apply no sanitization to external data on the path to the LLM context — safeguards against IPI remain rare even in widely deployed commercial MCP servers.
  • MCPSEC flagged 143 tools as vulnerable; humans confirmed 95, of which MCPSEC recovered 94 (98.9% recall) vs 80 for the LLM baseline (84.2%). Note the gap between 143 flagged and 94 true confirmed: precision is not the strong suit — this is a hypothesis generator, not a verdict.
  • Cost is $1.65 per MCP server on average.
  • Servers spanned four categories: public web retrieval, browser automation, authenticated SaaS collaboration, and infrastructure/cloud.
  • Of 18,770 servers in the official MCP Registry, a substantial share expose a remote endpoint with no package or source repo — i.e., are unauditable by conventional means, which is the gap this paradigm targets.

Caveats

Output is ToCs, not confirmed vulnerabilities — validation still requires access the no-box setting lacks. The high flag count (143 vs 95 confirmed) implies false positives an analyst must triage. Data and code are promised only on acceptance, and generated ToCs/PoCs only after vendors fix reported bugs.

Technologies named here

Techniques named here

  • No-box vulnerability analysis

Related in AI Security