Clean MCP scans, malicious servers: what scanners miss

What is this?

On September 15, 2026, Yotam Perkal and Eitan Chassid of Pluto Security published “Malicious Servers, Clean Scans”. They built two deliberately harmful Model Context Protocol (MCP) servers and ran them through five MCP and agent-skill scanners: Cisco mcp-scanner, Snyk agent-scan, Ventrova sentinel-scan-cli, mcp-shield and NVIDIA SkillSpector. Each scanner returned a clean or zero-finding result in at least one tested configuration.

Both servers posed as a simple weather tool, and the user still received a normal weather answer. One read local credential files and sent them to a collector. The other fetched a command from a second server, ran it, and returned the output. The tests ran in an isolated environment with fake credentials. One caveat: Pluto sells MCP security products, which the article discloses only briefly at the end.

A second source points the same way. A September 16, 2026 arXiv paper by Murali Ediga and Sudipta Chattopadhyay reports that seven third-party MCP security tools failed to detect injection payloads split across several channels.

How it works

The servers did not hide anything clever in their metadata. Their tool names, descriptions and schemas looked benign. The harmful logic sat in the handler code, which many scanners never inspect. Pluto attributes the misses to several recurring gaps:

• Metadata-only checks. Some checks examine only names, descriptions, schemas or manifests, which contained nothing suspicious.
• Incomplete analysis. One Cisco analyzer’s prompt budget left too little room for server evidence. SkillSpector’s LLM review skipped an oversized file, so the same code behind a large block of harmless text returned “CAUTION / 0” with partial coverage.
• Brittle static rules. Keyword and syntax rules can be evaded by equivalent variations.
• Scattered clues. Related signals were scanned in separate fields, so no rule connected them.
• Runtime-supplied behavior. The command arrived after the scan, so no scan could have seen it.
• Out-of-scope content. Text returned by tool calls sits outside tool-list scans.

SkillSpector’s default LLM review was the only check that caught both servers at normal file size. Cisco’s behavioral analyzer returned clean results even for a positive-control server that openly described its own credential theft in its tool description.

Why it matters

Teams increasingly treat a scanner verdict as an install gate. This research shows that a gate which silently degrades (skipped files, truncated context, timeouts) still reports success. It also fits the earlier Trail of Bits finding on skill scanners: a scanner is a fixed target, and the attacker moves second. The risk is highest where an MCP server runs with access to SSH keys, cloud credentials or Kubernetes configuration on a developer machine.

Defenses

• Check what each scan covered. Treat skipped files, timeouts or degraded analysis as a failed gate, not a pass.
• Curate and pin. Use vetted sources, pin versions or commit hashes, and review changes before updating.
• Review all executable code, including code loaded at runtime.
• Test unknown servers in isolation with fake credentials, and observe their file and network activity.
• Apply least privilege to each server’s files, credentials and network egress.
• Monitor after installation for tool-definition changes and process-level behavior.
• Combine several kinds of analysis and treat a scan as evidence, never as a trust decision.

Status

Item	Detail
Research published	Pluto Security, September 15, 2026; arXiv paper, September 16, 2026
Scanners tested	Cisco mcp-scanner, Snyk agent-scan, Ventrova sentinel-scan-cli, mcp-shield, NVIDIA SkillSpector
Upstream fixes	Two SkillSpector pull requests approved with passing CI; two Cisco pull requests open. None merged or released at time of writing
Exploited in the wild	Not stated