MCP Security in 2026: 30 CVEs in 60 Days - What Every Developer Should Know
A practical guide to MCP security, MCP server vulnerabilities, MCP tool poisoning, prompt injection, and how to audit your local MCP setup before it becomes a production risk.
Model Context Protocol moved fast because the idea is obviously useful: give AI agents a standard way to call tools, query data, read files, open tickets, and operate inside a developer workflow. The risk is just as obvious once you say it out loud. MCP gives natural-language systems a path to real capabilities.
That path is now a security boundary. In early 2026, public MCP security tracking and industry writeups began reporting roughly 30 CVEs in about 60 days across servers, SDKs, and host tooling. The exact count will keep changing, but the pattern is stable: MCP is no longer an experiment sitting on localhost. It is infrastructure.
The five MCP attack classes that matter
Most MCP server vulnerability discussions collapse into one vague warning: "do not run untrusted tools." That is true, but it is not operational. Developers need to know what to look for in a config, a server package, and an AI editor session.
1. Tool poisoning
Tool poisoning happens when the tool metadata lies. The visible name may say search_docs, while the description quietly instructs the model to exfiltrate files, prefer unsafe calls, or ignore user constraints. Because LLMs use descriptions to decide when and how to call tools, the description is not documentation. It is executable influence.
This is why MCP security is different from ordinary API security. An HTTP client does not read a route description and decide to leak your .env. An agent might.
2. Prompt injection through external data
MCP servers often connect agents to GitHub issues, Slack messages, tickets, docs, databases, browser pages, and files. Any one of those data sources can contain hostile instructions. The agent sees the content as context, not as code, but that distinction is thin when the agent is allowed to call tools.
A poisoned issue title can become a command. A README can become a policy override. A support ticket can become a request to query secrets. The defensive move is to treat external content as untrusted input even when it arrives as prose.
3. Trust bypass in local developer tools
CVE-2025-49596 showed why "it only listens on localhost" is not a complete defense. Researchers documented a critical MCP Inspector issue where missing authentication between the client and proxy could allow remote code execution through browser-driven requests against a local service. The patched version added session-token and origin protections.
Local tools feel safe because they run beside the developer. In practice, they sit beside SSH keys, cloud credentials, repo secrets, browser sessions, and production deploy access. That makes local MCP tooling high-value infrastructure.
4. Supply chain attacks
MCP servers are packages. Packages have maintainers, dependencies, install scripts, transitive risk, and update pressure. CVE-2025-6514 in mcp-remote was reported as a critical command-execution issue with a CVSS score of 9.6 and hundreds of thousands of downloads. That is the shape of a modern AI supply-chain incident: a small connector becomes a privileged bridge into many developer machines.
5. Cross-tenant and data exposure failures
Hosted MCP servers add a familiar cloud problem: tenant isolation. A tool that can read tickets, files, traces, or database rows must prove that one user's agent cannot reach another user's data. In AI workflows, this also includes indirect exposure: a model summarizing data it should never have seen, then passing it into another tool call.
Why MCP security breaks old assumptions
Classic scanners ask questions like: is a dependency vulnerable, is an endpoint authenticated, is a string concatenated into SQL? Those checks still matter. MCP adds questions that static scanners were not built to ask:
- Can this tool description manipulate the agent?
- Can external text cause an unsafe tool call?
- Does this server spawn shell commands from model-controlled input?
- Does this config grant filesystem, browser, or network access by default?
- Can a local bridge be reached from a browser or another process?
The shortest version: MCP combines package security, API security, prompt-injection defense, and local developer-machine hardening. You need all four.
A practical MCP security checklist
Before you add an MCP server to Cursor, Claude Code, Continue, Zed, or any local agent host, run through this checklist.
- Pin the package and version. Floating latest tags make incident response messy.
- Read the tool descriptions. Look for hidden instructions, suspicious routing, or commands unrelated to the tool's stated job.
- Check process execution. Any server that shells out needs strict allowlists and argument escaping.
- Limit filesystem scope. Do not give an agent your whole home directory when it needs one repo.
- Require authentication for HTTP transports. Localhost is not a security model by itself.
- Prefer read-only tools first. Add write capabilities only after you can explain why they are needed.
- Audit before onboarding a new server. The time to find a poisoned manifest is before the model can call it.
Where ekmire fits
ekmire is built around the reality that AI-assisted development has more than one security moment. The MCP server catches risks while you write. The git hook blocks unsafe code before commit. The Rust proxy inspects runtime traffic when a payload reaches production.
For MCP specifically, ekmire mcp audit checks local MCP configuration and tool metadata for risky patterns: hidden instructions, suspicious command execution, broad filesystem access, network exposure, and poisoned descriptions. It is designed to be fast enough to run before you trust a server.
ekmire mcp audit
# Output includes:
# - risky MCP server configs
# - suspicious tool descriptions
# - command execution paths
# - hidden instruction patterns
# - recommended fixesThe takeaway
MCP is not "bad." It is powerful. That is exactly why it needs security controls close to the developer workflow. If an MCP server can read files, run commands, open network connections, or call internal APIs, treat it like privileged software, not like a plugin you install between meetings.
Run the audit. Pin the versions. Read the tool descriptions. Keep write permissions narrow. The agent era rewards speed, but it punishes blind trust.