VIPER-MCP Shows Agent Tools Need Taint Scanning
VIPER-MCP scanned 39,884 MCP server repos and confirmed 106 zero-days, 67 with CVE IDs. Agent tools need code-level taint analysis, not trust prompts.
VIPER-MCP, published May 20, 2026, scanned 39,884 open-source MCP server repositories and confirmed 106 exploitable zero-days, 67 of them already carrying CVE IDs. The bugs are ordinary command injection, SSRF and path traversal — reachable because a model fills in the tool arguments. MCP servers need taint analysis, not trust prompts.
Updated September 2026: the paper was revised (v2) on August 12, 2026. The CVE count stood at 67 at publication, and the defensive guidance below is unchanged as of September 2026.
The paper is by Pengyu Sun, Zifeng Kang, Qishu Jin, Enhao Huang, Xin Liu, Dakun Shen and Song Li. Its own framing of the risk is the clearest summary of why this matters:
Because MCP servers expose privileged operations such as shell execution, network access, and file-system manipulation to agent-driven invocation, implementation flaws in tool handlers can create a direct path from natural-language input to security-sensitive sinks, potentially granting attackers remote code execution or full system compromise.
— VIPER-MCP, arXiv:2605.21392
That research landed in the middle of a busy month for MCP exposure data. Adversa AI’s June MCP security roundup collected VIPER-MCP alongside Censys scan results, unauthenticated remote MCP servers, Akamai’s database-MCP findings and the NSA’s MCP design guidance — which we covered separately in the NSA MCP guidance post.
Key Figures
| Figure | What it measures | Source |
|---|---|---|
| 39,884 | Open-source MCP server repositories audited | VIPER-MCP (arXiv:2605.21392) |
| 106 | Zero-days confirmed with an end-to-end exploit trace | VIPER-MCP |
| 67 | CVE IDs assigned at publication | VIPER-MCP |
| 130 | Vulnerable servers in the ground-truth evaluation set | VIPER-MCP |
| 0% | False-positive rate on the 130 benign servers | VIPER-MCP |
| 7.7% | False-negative rate (10 of 130 missed) | VIPER-MCP |
| 43.1% / 63.8% | MCPSafetyScanner false positives / false negatives | VIPER-MCP baselines |
| 24.6% / 73.1% | Cisco AI Defense false positives / false negatives | VIPER-MCP baselines |
| 926 s | Mean end-to-end audit time per server (90% under 30 min) | VIPER-MCP |
| 12,520 | Internet-reachable MCP services found by Censys, most unauthenticated | Adversa AI roundup |
| ~40% | Servers exposing tools with no authentication at all | Adversa AI roundup |
| 9 | CVEs traced to broken OAuth flows in that same work | Adversa AI roundup |
| 1,467 | Exposed MCP servers counted by Trend Micro | Adversa AI roundup |
| CVSS 9.8 | Command-injection severity in unofficial cloud MCP servers | Adversa AI roundup |
Two numbers are worth pausing on. A 0% false-positive rate against baselines at 43.1% and 24.6% is the difference between a report a team acts on and a report a team ignores. And 12,520 reachable services, most of them unauthenticated, means the exploitable code VIPER-MCP describes is frequently sitting behind no front door at all.
What VIPER-MCP Found
VIPER-MCP focuses on taint-style vulnerabilities. In normal application security terms, that means untrusted input reaches a dangerous sink without enough validation in between.
For MCP servers, the source is often a tool argument filled in by the model. The sink might be a shell command, filesystem call, HTTP request, database query, template renderer, or dynamic evaluation path. If the server treats the model-selected argument as trusted, then an attacker does not need direct access to the server. They only need a way to influence what the agent reads or decides.
That is the agent-specific twist.
In a web app, tainted input may come from a request parameter. In an MCP workflow, tainted input may come from a README, issue comment, web page, Slack message, ticket body, email, prompt injection, poisoned skill, or another tool’s output. The model becomes the routing layer between attacker-controlled text and privileged server code.
Figure: the source is text an attacker can plant; the sink is a privileged operation. The model is the routing layer in between, which is why validation has to happen at the tool handler.
The paper argues existing approaches were not enough because static scans often produce unconfirmed alerts, while template-based dynamic testing misses vulnerabilities that require a particular tool choice, parameter shape, or multi-step path. VIPER-MCP combines two ideas:
- an anchor-query pass in a two-pass static analysis that resolves file-level taint alerts back to specific MCP tool handlers, producing vulnerability-anchored call chains
- a feedback-driven prompt evolution loop that mutates natural-language prompts — correcting tool-selection drift and deepening parameter penetration — until the vulnerable path is actually reached
That matters because the reported findings are not just “this code looks suspicious.” The researchers confirmed exploitability with end-to-end traces and coordinated disclosure for the affected projects, and measured the result against a ground truth of 130 vulnerable and 130 benign servers.
The three classes VIPER-MCP models are command injection (CWE-78), SSRF (CWE-918) and path traversal (CWE-22). The paper is explicit that its remaining 7.7% false negatives are largely classes it does not model yet, including SQL injection and code injection — so 106 is a floor, not a ceiling.
For defenders, the headline is simple: MCP servers are now a large software supply chain, and many of them contain the same injection and validation mistakes that security teams have spent decades finding in normal applications.
The difference is privilege.
Why This Is Different From Package Scanning
Traditional dependency scanning asks whether a package contains a known vulnerable version, malicious code, leaked secrets, or risky behavior at install time. That is still necessary for MCP servers, but it is not enough.
An MCP server has two security surfaces at once.
The first is the artifact surface: the code, manifest, package metadata, dependencies, install scripts, and repository history. This is the part normal supply-chain tooling can inspect.
The second is the tool surface: the names, descriptions, schemas, argument validators, handlers, return values, and credentials exposed to the agent at runtime. This is the part that decides what the model can do.
VIPER-MCP is important because it crosses those layers. It does not just ask whether a repository has dangerous code. It asks whether an MCP tool handler can be driven, through model-facing inputs, into that dangerous code.
That is exactly the kind of analysis agent tooling needs, and it is what the OWASP MCP Security Cheat Sheet asks for in one line:
Validate all inputs to MCP server tools — treat them as untrusted (they originate from LLM output influenced by potentially malicious context).
— OWASP Cheat Sheet Series, MCP Security
Consider a file-search MCP server. A normal package scanner might see filesystem reads and treat them as expected functionality. A tool-aware scanner asks harder questions:
- Is the path argument confined to an allowlisted root?
- Are symlinks resolved before access decisions?
- Can the model pass
../paths or absolute paths? - Does the server expose hidden files, environment files, SSH keys, or agent memory?
- Does tool output flow into another tool without filtering?
Or consider a deployment MCP server. Shell execution may be part of its purpose. The question is not whether it ever launches a process. The question is whether a model-controlled string can become a command line, environment variable, script body, or unescaped argument.
This is why agent tool security cannot stop at “is the package popular?” or “does the README look legitimate?” The dangerous boundary is often inside the handler.
How This Connects To Tool Poisoning
We recently covered MCP tool poisoning, where malicious tool metadata can steer an agent in ways the user never sees — the attack class Invariant Labs first documented. VIPER-MCP covers a different but compatible failure mode.
Tool poisoning manipulates what the model chooses.
Taint-style handler bugs make the chosen call dangerous.
An attacker can combine them. A poisoned tool description, malicious issue, compromised page, or hostile document can nudge the agent toward a legitimate MCP server. If that server accepts model-supplied arguments and passes them into a shell, database, URL fetcher, or filesystem operation without validation, the exploit does not need a malicious MCP server at all.
That is the uncomfortable lesson. The agent ecosystem has talked a lot about untrusted third-party tools. VIPER-MCP shows that trusted tools can be exploitable too.
This is also why the NSA framing still matters. The NSA MCP guidance treats MCP as operational infrastructure: inventory it, define trust boundaries, validate parameters, constrain execution, log decisions, and scan for exposed or vulnerable servers. The MCP specification’s own security best practices say much the same about token handling and confused-deputy risks. VIPER-MCP provides a concrete code-level reason for those controls.
If an MCP server can run commands, touch files, query databases, or call internal APIs, then a validation bug is not a small defect. It is a way for prompt injection to become action.
Marketplaces Need More Than Listings
The public MCP ecosystem is moving toward marketplaces, registries, curated lists, and one-click installs. That is good for adoption. It also creates the same trust shortcuts that package registries, browser extension stores, IDE marketplaces, and AI skill registries have all had to confront.
A listing can tell you what a server claims to do. It cannot prove that every handler validates untrusted input. It cannot prove that a model-controlled field never reaches subprocess, eval, fs.readFile, requests.get, SQL string concatenation, or a cloud-admin API. It cannot prove that the server you installed last month still exposes the same tool surface today.
That does not mean marketplaces are bad. It means marketplaces need admission controls.
Figure: package scanning covers the left half of this chain. The taint-analysis and dynamic-confirmation checkpoints are the ones VIPER-MCP shows are missing.
For MCP servers and plugin-like agent tools, useful admission should include:
- Source provenance and publisher identity
- Dependency and secret scanning
- Tool metadata review for prompt-injection patterns
- Schema and permission review
- Taint analysis from tool arguments to dangerous sinks
- Dynamic confirmation for high-risk paths
- Version pinning, hashes, and re-review when tool surfaces change
The last two matter because agent tools drift. A server can add a new tool. A description can become longer and more directive. A handler can change how it builds commands. A dependency update can introduce a new sink. An OAuth scope can widen after the original approval.
Install-time trust is only a snapshot. Our own MCP security overview covers what that means for teams already running servers in production.
Practical Defenses For Teams
Start with inventory. List every MCP server, plugin, connector, skill, and custom tool your agents can reach. Include local developer machines, CI jobs, desktop agents, cloud agent runtimes, and project-level configs. With 12,520 MCP services reachable from the open internet, assume some of yours are among them until you have checked. Our 12-check MCP security checklist is the same sweep in order: before install, at the call, in flight, and continuously.
Separate tool categories by blast radius. Documentation lookup and read-only search are not the same as shell execution, filesystem writes, package publishing, repository administration, database mutation, Slack posting, cloud control-plane access, or customer-data export.
Treat model-filled tool arguments as untrusted input. Validate type, length, format, and allowed values at the handler boundary. For paths, resolve and confine them to an explicit root. For commands, pass argument arrays instead of shell-built strings. For URLs, use destination allowlists and block internal metadata services. For SQL, parameterize. For dynamic execution, remove the sink.
Run servers with least privilege. A compromised or exploitable MCP server should not inherit your whole laptop, cloud account, SSH agent, Kubernetes context, production database, or CI secret set. Use dedicated service accounts, short-lived tokens, containers or sandboxes, network egress controls, and workspace-scoped filesystem access.
Review high-risk tools before loading them into the same agent session. Cross-tool chains are where small mistakes become incidents. A low-risk tool that can influence context may become dangerous when it sits beside a privileged filesystem, cloud, or messaging server.
Log the chain. Useful records need more than “API call succeeded.” Capture the user request, selected tool, arguments or argument hash, server identity, tool version or hash, policy decision, approval path, and returned output. Without that sequence, it is hard to know whether the agent made a bad choice, a tool description steered it, or a handler bug turned a normal call into an exploit.
Finally, scan continuously. VIPER-MCP’s result is a reminder that this is not one CVE to patch. It is a class of bugs to sweep for whenever servers, schemas, handlers, dependencies, or permissions change. Community checklists such as SlowMist’s MCP Security Checklist are a reasonable starting inventory of what to sweep for.
Where SkillSafe Fits
SkillSafe’s core job is verifying AI skills and plugin-like artifacts before agents consume them. VIPER-MCP reinforces the same principle for MCP servers: agent-facing artifacts need security review that understands how agents actually use them.
For skills, that means scanning instruction files for malicious behavior, hidden prompt injection, credential access, persistence, exfiltration, config tampering, and dangerous command patterns — which is what our scanner does on every save and every install. For MCP servers, it means scanning tool metadata and handler code for the path from model-controlled inputs to privileged operations.
The shared model is supply-chain verification before trust:
- Know who published the capability.
- Know which exact version was reviewed.
- Scan the content the model will read.
- Scan the code the tool will run.
- Compare the artifact installed by the consumer with the artifact that was reviewed.
- Re-review when the capability changes.
That is why dual-side verification matters. Publisher-side scanning catches problems before sharing. Consumer-side re-scanning checks what actually arrives before install. Cryptographic comparison detects tampering between those points. The same pattern applies to every artifact class we track under supply chain.
Frequently Asked Questions
Are MCP servers a security risk?
Yes, and the risk is measurable rather than theoretical. VIPER-MCP confirmed 106 exploitable zero-days across 39,884 open-source MCP server repositories, 67 of which now have CVE IDs. Censys separately found 12,520 internet-reachable MCP services, most unauthenticated. The risk is not MCP as a protocol — it is that MCP servers expose privileged operations to model-selected arguments.
How do you secure an MCP server?
Validate every tool argument at the handler boundary as untrusted input, per the OWASP MCP Security Cheat Sheet: confine paths to an allowlisted root, pass argument arrays instead of shell strings, parameterize SQL, and allowlist outbound URLs. Then run the server with least privilege — dedicated service accounts, short-lived tokens, and workspace-scoped filesystem access — so a missed bug has a small blast radius.
What is the difference between MCP tool poisoning and a taint-style bug?
Tool poisoning manipulates which tool the model chooses, usually through malicious metadata the user never sees. A taint-style bug makes the chosen call dangerous: the handler passes a model-supplied argument straight into a shell, SQL query, file path or HTTP fetch. They compose — a poisoned description steers the agent toward a legitimate server whose handler does the damage.
How do you scan an MCP server for vulnerabilities?
Combine artifact scanning with tool-surface analysis. Dependency and secret scanning covers the package; taint analysis from tool arguments to sinks covers the handlers. VIPER-MCP’s approach — static anchoring to specific handlers, then dynamic confirmation with evolved prompts — reported a 0% false-positive rate against baselines at 43.1% and 24.6%, which is why confirmation matters as much as detection.
Does version pinning protect against this?
Pinning protects against silent drift, not against a flaw present in the pinned version. It is still necessary: a server can add a tool, widen an OAuth scope, or change how a handler builds a command in any release. Pin the version, record the hash, and re-review whenever the tool surface changes — points 6 and 7 of the admission list above.
Conclusion
VIPER-MCP does not make every MCP server suspect. It makes every MCP server ordinary software with extraordinary reach — 39,884 repositories audited, 106 exploitable, 67 CVEs, all from bugs a decade-old taint analyzer would recognize. That is enough reason to treat MCP servers, skills, plugins, and connectors as one agent supply chain.
The practical lesson is not “stop using agent tools.” The lesson is to stop granting them trust just because they sit behind an agent. Validate the handler. Verify the artifact. Scope the permission. Watch the runtime path.
Agent tools are becoming infrastructure. Infrastructure needs scanning.