VIPER-MCP's automated vulnerability research
VIPER-MCP combines static analysis with generated attack prompts to test MCP servers. Its findings make a case for testing the tools and permissions exposed by each deployed server.
The VIPER-MCP paper, first submitted in May 2026, reports a scan of 39,884 open-source MCP server repositories, 106 confirmed zero-days, and 67 assigned CVEs. These figures are the authors' reported results, not an estimate of compromise across deployed servers.
If your security posture depends on "we will patch quickly when a CVE drops", this should change your priorities.
What changed
The bottleneck is no longer "can an attacker find a bug in your MCP server". The bottleneck is "how fast can they turn a bug into an agent compromise chain". VIPER-MCP makes that cycle cheap.
VIPER-MCP in one paragraph
VIPER-MCP takes an MCP server codebase, identifies tool handlers and data flows, and uses a two-pass approach to anchor taint analysis results to specific handlers. Then it iteratively evolves natural language prompts that drive an MCP client to hit the vulnerable sink, producing end-to-end exploit traces. This matters because the payload is not only a traditional exploit string. It can be a tool call shaped by the model that reaches a sensitive execution path.
The new kill chain: from repo to runtime in one loop
If you want the OWASP mapping, this chain is not a single category. It is a multi-risk cascade:
- ASI04 (Supply Chain): importing a third-party MCP server is importing code that can execute with agent-adjacent trust.
- ASI05 (Unexpected Code Execution): vulnerable servers turn untrusted inputs into execution paths.
- ASI02 (Tool Misuse): the agent is the delivery mechanism. The tool call is the exploit surface.
- ASI01 (Agent Goal Hijack): the attacker does not need to jailbreak your model if they can steer the agent's tool invocation semantics.
Testing the exposed server tools
Traditional AppSec assumes the attacker sends bytes to an endpoint. Agentic systems add two accelerants:
- The model is a programmable router. If a server exposes a tool, the model will try to satisfy the objective using that tool, including by retrying and iterating.
- Natural language is now part of the exploit surface. Not as "prompt injection" in the abstract, but as a high-level interface that can systematically discover parameter shapes that reach sinks.
| Dimension | Traditional vuln discovery | VIPER-style MCP discovery |
|---|---|---|
| Payload format | HTTP requests and exploit strings | Tool calls plus natural language prompts that shape parameters |
| Search strategy | Fuzzing and heuristics with limited semantics | Feedback loop that corrects tool selection drift and deepens parameter penetration |
| Blast radius | Single service compromise | Service compromise plus agent access paths and downstream tool graph |
| Defensive ownership | AppSec team plus engineering | AppSec plus identity, platform security, and SOC (tool call logs are telemetry) |
What security teams should do this quarter
Here is the defensive framing we recommend: treat MCP servers as privileged plugins, not as "just integrations".
Control checklist (practical and auditable)
- Inventory every MCP server in use and pin versions like you pin production dependencies.
- Capability allowlist: explicitly permit tool names and argument schemas, then reject everything else.
- Process sandboxing: run MCP servers in isolated containers with minimal filesystem and network access.
- Network egress control: default deny outbound, then allow only required destinations.
- Strong auth: require authentication between agent client and MCP server, even on "internal" networks.
- Code scanning: run SAST and dependency scanning on MCP servers the same way you do for services.
- Telemetry: log tool calls, tool inputs, and tool outputs with correlation IDs, then alert on abuse patterns.
The question to ask vendors
"If a researcher can find an exploit chain in your MCP server with an automated prompt loop, what stops a real attacker from doing the same against our deployment, and how will we know?"
Limit the permissions available after exploitation
You do not need to predict which specific MCP server will be the next CVE. You need to assume that some server you depend on will be exploitable, then engineer the system so that exploitability does not automatically become compromise.
Limit each server's credentials and reachable systems so an exploited process has less access.