MCP security in 2026

The Model Context Protocol lets an AI assistant call tools on other systems: read a database, open a ticket, run a command. That's the point of it, and it's also the problem. Every MCP server is a piece of software that an agent can be talked into using, often with the user's credentials and sometimes with a shell. Two years in, MCP has the security record you'd expect from a protocol that went from launch to every major AI client in about six months: ordinary bugs in thousands of small servers, a new class of attacks on the model itself, malicious packages, and a response that is real but uneven.

Most writing about MCP security is either a vendor's scan or a single scary demo. We wanted the whole picture in numbers. So we counted every MCP vulnerability advisory we could find in the public databases, pulled the official MCP Registry and probed a sample of its remote servers, and collected the academic benchmarks, internet scans and incident reports, then checked them. Security-vendor figures are the vendor's own claims, with the vendor's method, and are labelled that way. Every number links to its source.

From zero to 145 advisories a month#

No one maintains a current count of MCP vulnerabilities, so we made one. At the start of October we pulled every reviewed advisory in the GitHub Advisory Database published since November 2024, every NVD record that mentions MCP, and the published security advisories of all 42 repositories in the official modelcontextprotocol GitHub organization. We kept an advisory if the affected product is MCP software (a server, client, SDK, gateway or inspector) or if the bug sits in another product's MCP feature, such as an /mcp endpoint. We dropped the many false hits (Linux drivers for Microchip's MCP2221 chip, plugins with "MCP" in their marketing name but bugs elsewhere) and deduplicated by CVE. The full rules are in the methodology.

The result: 776 advisories made public between November 2024 and September 2026. There were none at all for the first six months. The first five arrived in May 2025, including a critical bug in the 5ire desktop client. 2025 ended with 90. Then the curve bent: 72 in the first quarter of 2026, 244 in the second, 370 in the third.

Two things explain the shape, and only one of them is "more bugs". The ecosystem did grow: the number of distinct products with an advisory stayed between 56 and 81 every month from April 2026, so this isn't one vendor's bad quarter. But more people are also looking. The jump in April coincides with VulDB starting to assign CVEs in bulk to small GitHub MCP repositories, and with OX Security's disclosure that the stdio transport runs whatever command a configuration gives it. Of the CVEs in our set, VulDB assigned 110 and VulnCheck 85. Batches matter too: the September peak includes 29 advisories for mcp-atlassian on a single day, 36 for that one server in total.

The severity mix is heavy. Of the 776, 138 are rated critical (17.8%) and 328 high (42.3%), so 60% are critical or high, using GitHub's label where there is one and NVD's CVSS score otherwise. 2025 was slightly worse, with 26.7% critical, because so many of its bugs were command injection.

What breaks#

The bugs changed character between the two years. In 2025, MCP mostly meant small servers running on a developer's machine over stdio, and the typical advisory was a tool that passed its input to a shell or eval: 53 of the 90 advisories (59%) were command or code execution. In 2026 MCP went over HTTP, into gateways, IDEs and agent builders, and the bugs followed. Command execution fell to 22% of advisories, while missing or broken authentication rose to 26% and SSRF and cross-origin bugs (DNS rebinding, CORS, CSRF) to 21%.

That shift lines up with what researchers found when they looked at code directly. A census of the official registry (21,643 servers, source code for 14,353, August 2026) found unauthenticated network exposure was the most common problem, in 9.57% of scanned servers, and estimated about 7.6% have a high-severity finding once scanner false positives are corrected for. Another study ran eight MCP scanners over 37,288 runnable servers: together they flagged 96.89% as risky, at an average precision of 45.53%. Scanner output is mostly noise. The confirmed numbers are smaller and sharper: VIPER-MCP found 106 zero-days with working exploits across 39,884 repositories, and 67 got CVEs.

Servers, clients, gateways and SDKs#

About six in ten advisories are against servers, including MCP endpoints built into other products. About one in five hits a client or host app: IDEs, chat apps and agent builders that launch or connect to servers. Gateways, proxies and registries take about a tenth, and SDKs and frameworks slightly less.

The official software isn't exempt. We counted 51 advisories against the project's own modelcontextprotocol repositories through September, 38 of them in its eight SDKs. Only one was critical: the MCP Inspector bug of June 2025 (CVSS 9.4), where missing authentication between the Inspector's browser client and its proxy let a web page launch commands. The rest are a pattern. DNS rebinding protection was off by default in the Python and TypeScript SDKs (December 2025), then in Go, Java, Rust and Ruby through July 2026. Several SDKs had unbounded memory use. And in the last week of September, the Python and TypeScript SDKs both disclosed a high-severity flaw that let a malicious server choose where a client sent its OAuth credentials, fixed in Python 1.30.0 and 2.2.0.

The client side has its own history of bugs in exactly the place MCP is trusted: the configuration that says which commands to run. Cursor's "MCPoison" (CVE-2025-54136) let an approved MCP entry in a shared repository be swapped for a malicious command with no new prompt. mcp-remote, a widely used bridge to remote servers, had a CVSS 9.6 command injection triggered by connecting to a malicious server in July 2025, and five more CVEs in September 2026.

Exploited in the wild#

Most of these bugs have no public exploitation record. Two do, officially. CISA's Known Exploited Vulnerabilities catalog has two MCP-related entries, both in LiteLLM, a popular gateway: CVE-2026-42271, where endpoints for previewing an MCP server ran a command from the request body, added on 8 June 2026, and CVE-2026-59822, an authentication bypass on LiteLLM's MCP endpoint, added on 2 September. Others have exploitation reports from security vendors but no CISA listing.

The common thread is a network-reachable MCP endpoint that trusted its caller. nginx-ui's /mcp_message endpoint skipped authentication, and Pluto Security counted over 2,600 publicly exposed nginx-ui instances. LiteLLM's two entries were a "test connection" feature that ran a supplied command and a bearer-token fallback that accepted a fabricated token. None of them needed the model to be fooled.

Exposed servers#

How many MCP servers sit on the internet without authentication? Several groups have scanned for them, and each used its own discovery method and its own definition of "exposed". The counts can't be lined up into a trend, so here they are side by side with their methods.

The Fudan study is the one with a full split. Of the 7,973 live remote servers it found, 3,233 (40.55%) exposed their tools with no authentication, 30.45% used OAuth and 29.00% a static token or API key. OAuth didn't mean safe: the researchers tested 119 OAuth servers and every one had at least one flaw, 325 in all, with dynamic client registration flaws in 96.6% of them.

What's behind those servers matters more than the count. Censys, which listed each service's tools but never executed any of them, sorted the 12,520 services it saw in late April 2026 into categories by their tool names. Data and knowledge tools (database queries, vector search) were the largest group, then infrastructure, and 687 services fell into its "system control" subcategory: tools that advertise command execution or process control.

The more recent studies tested what those tools actually do. Wiz says MCP shows up in 80% of the cloud environments it sees, about 1 in 6 of those expose at least one MCP server to the internet, about 70% of exposed servers hand their full tool list to an anonymous caller, and about 42% return real data when a tool is called. In September, Pluto Security reported 147 servers that were genuinely unauthenticated once it called their tools, including several where an exec tool ran as root.

Attacks on the model#

Everything above is classic application security. MCP adds a second attack surface: the model reads tool names, descriptions and results as text, and text can carry instructions. Invariant Labs named tool poisoning in April 2025: hidden instructions in a tool's description that the user never sees. Since then researchers have built benchmarks to measure how often it works.

The largest is MCPTox (AAAI 2026): 45 live MCP servers, 353 real tools and over 1,300 poisoned test cases across 20 model settings. The average attack success rate was 36.5%, o1-mini was fooled 72.8% of the time, and the model that refused most often, Claude 3.7 Sonnet, refused under 3% of attacks. The authors' explanation is uncomfortable: more capable models are often more susceptible, because the attack exploits their better instruction-following. Turning on reasoning in the Qwen3 models raised attack success at every size.

Other benchmarks point the same way. MSB (ICLR 2026) ran 2,000 attack instances of 12 types and found an average success rate of 40.35%, with asking for an out-of-scope parameter the most effective at 76.5%; its authors also found stronger models more vulnerable. On real servers, MCP-SafetyBench compromised every one of 13 models in 29.8% to 48.2% of cases. Off-the-shelf defences helped little: in MCPSecBench, two published protections blocked 17.9% and 28.9% of attacks on average.

The 2026 frontier models are harder to fool with a crude injection. In a public red-teaming competition with 272,000 attack attempts against 13 frontier models, success rates ranged from 0.5% (Claude Opus 4.5) to 8.5% (Gemini 2.5 Pro). But MCP gives attackers more than one channel into the context. A September 2026 paper split a payload across a tool's description, its result and a sampling message, so that no single channel carried a complete injection. Over more than 15,000 trials, models that never complied with a single-channel attack exfiltrated credentials at up to 100%, and all seven third-party MCP security tools the authors tried missed the fragments.

How often does this happen outside a lab? Nobody knows, and the counts depend on the detector. The registry census found no poisoned tool descriptions among 14,353 servers; an earlier study using one scanner on a subset of repositories reported 5.5%. The attacks seen in the wild so far are malicious code, not clever descriptions, which brings us to the supply chain.

The supply chain#

On 25 September 2025 Postmark warned that a package called postmark-mcp, impersonating its official server, had "built trust over 15 versions" before version 1.0.16 quietly BCC'd every email to an attacker. It's usually described as a long con. npm's own metadata says otherwise: all 18 versions were published between 15 and 17 September, so the "trusted" period lasted about two days. The package had 1,643 downloads, and Postmark said it knew of one affected customer. It was the first malicious MCP server found in the wild. It wasn't the last.

We searched OSV, the open-source vulnerability database that collects malicious-package reports from GitHub, Amazon, Google and others, for npm and PyPI packages with "mcp" in the name. As of early October it held 163 such advisories, with a spike in the second quarter of 2026.

The attacks come in three shapes. Some packages are built to be malicious, like postmark-mcp or the three PyPI "run command" servers that opened a reverse shell. Some are legitimate MCP packages hijacked by worms that steal maintainer tokens: Shai-Hulud 2.0 hit Postman's MCP server and others in November 2025. And some use MCP as the payload: the SANDWORM_MODE worm, spread through Claude Code typosquats, wrote a rogue MCP server into the configs of Claude Code, Claude Desktop, Cursor, Continue and Windsurf, with tool descriptions that told the agent to read SSH and cloud credentials.

V.A.P.E. shows how the official registry's model works. The registry verifies who published an entry, but relies on npm, PyPI and Docker to scan the code. Here the PyPI package was clean; the payload sat in the settings files of the GitHub repository the entry linked to. The entry was listed on 8 August, OX Security reported it the next day, a community member filed a takedown request on 21 August noting it was still active, and it was removed on 5 September. That's consistent with the registry's own moderation policy, which removes malware and spam but says consumers "should assume minimal-to-no moderation" and that it won't remove servers with security vulnerabilities. Malware is also not the only way a listing can change under you: the August census found that 4.2% of multi-version servers had moved their remote endpoint to a different host while keeping the same registry identity, a change clients are never told about.

The response#

The spec#

The specification has tightened authorization in every revision since March 2025: OAuth 2.1 with PKCE, then servers as OAuth resource servers with tokens bound to one server, then client ID metadata documents, and in July 2026 issuer validation and the deprecation of dynamic client registration. What it hasn't changed is whether authorization is required. Every revision's authorization page says "Authorization is OPTIONAL for MCP implementations", and stdio servers, 96.6% of the installable packages in the registry by our count, are told to take credentials from the environment instead.

The spec's security best practices page grew faster. Counting from the page's git history, it had three attack sections when it was introduced with 2025-06-18 (confused deputy, token passthrough, session hijacking), five with 2025-11-25 and ten with 2026-07-28, adding SSRF, mix-up attacks and localhost redirect impersonation among others.

What servers actually do#

To see how much of that reaches deployed servers, we pulled the whole official registry in early October: about 40,000 servers, 25,224 of them with a remote endpoint. The registry's schema has no field for OAuth, which a client is meant to discover at runtime, so metadata can't tell you who uses it. What it does show: 81.7% of remote servers declare no credential at all, and where publishers do declare one, it is almost always a static API key or bearer header (17.1%).

So we asked the servers. We took one remote endpoint per hostname, 300 in all, and sent each a single unauthenticated initialize request, the first message of an MCP session. We never listed or called a tool.

About half completed the handshake with no credentials. About a quarter answered with a 401 pointing to OAuth protected-resource metadata, exactly as the spec describes, and of the servers that refused us at all, 80% did it that way. The direction is right where servers do authenticate. Most still don't, at least not at the front door.

Clients, registries and guidance#

The clients have done the most visible work, in three waves. First came re-approval: after MCPoison, Cursor began requiring approval every time an MCP config entry changed (July 2025), and VS Code added a trust dialog for changed servers. Then sandboxes: Claude Code's bash sandbox, which Anthropic says cut permission prompts by 84% internally (October 2025), Cursor's sandbox by default on macOS, and in March 2026 an opt-in sandbox for local MCP servers in VS Code. Then organisation control: GitHub's internal registry and "registry only" policy, managed allowlists in Claude Code and GitHub Copilot, and an Enterprise-Managed Authorization extension that lets an identity provider decide which servers people can use (June 2026). The gap is in what clients inspect: in a source audit of four clients, the cross-channel paper found that none scanned tool results or descriptions for injected instructions.

Curated catalogs went further than the official registry: Docker builds and signs every local server in its catalog, and JFrog's MCP registry scans public packages before a project can use them. Guidance arrived too: the OWASP MCP Top 10 (still in beta), a CoSAI taxonomy of nearly forty threats, and an NSA information sheet in May 2026 that says tool and model outputs should never be implicitly trusted, and that MCP-aware security proxies "remain limited and are still maturing".

The market answered with gateways and acquisitions. By our tally, 13 acquisitions between June 2025 and August 2026 named MCP in the announcement, from Snyk buying Invariant Labs, the team that named tool poisoning, to Snowflake's deal for Natoma and Arcade's for Smithery. None disclosed a price. Twelve funding rounds that name MCP add up to about $389M by our arithmetic, most of it going to broader agent-identity platforms rather than MCP-only tools.

What this means if you build with AI#

If your agent uses MCP, every server you connect is code you're trusting with whatever the agent can reach. The data points to a short list of habits, depending on which side you're on.

If you build MCP servers#

1. Require authentication on anything network-reachable, and use the spec's OAuth flow. The spec won't make you, but 40.55% of live remote servers had none, and both CISA-listed MCP bugs were an endpoint that trusted its caller. Answer unauthenticated requests with a 401 and protected-resource metadata, as 26% of the servers we probed already do.
2. Bind local servers to localhost and turn on DNS rebinding protection. The official SDKs shipped with it off by default for months. Upgrade the SDK: the Python fix for OAuth credential routing is in 1.30.0 and 2.2.0.
3. Never pass tool input to a shell, eval or a file path without validation. Command execution was 59% of 2025's advisories and path traversal is still 14%.
4. Treat a preview or "test connection" feature as production. That's how LiteLLM ended up on CISA's list.

If you connect MCP servers#

1. Install from the publisher, by exact name and pinned version. Squats of official server names collected thousands of downloads, and postmark-mcp turned malicious on its sixteenth version. A registry listing is not a review.
2. Don't give one agent private data, untrusted content and a way out at the same time. That's the lethal trifecta, and the cross-channel results show a model that resists one injection can still be walked into exfiltration.
3. Re-approve when a server changes, and read what you approve. Clients now prompt on config changes; the prompt only helps if someone looks. Run local servers in a sandbox where your client offers one.
4. Patch clients and bridges fast. mcp-remote has had six CVEs, Cursor several, and the shortest gap we found from fix to a criminal proof of concept was 20 days.

If you run a platform team#

1. Keep an allowlist. Claude Code, GitHub Copilot, Cursor and VS Code all support org-managed MCP allowlists or a registry-only policy now. Prefer remote servers you can put behind your identity provider over stdio commands on every laptop.
2. Scan your own network for MCP endpoints. Wiz found MCP in 80% of the cloud environments it sees, with about 1 in 6 of those exposing one to the internet. The NSA recommends the same.
3. Don't rely on a scanner or a prompt guard alone. Scanners flagged 96.89% of servers at under 50% precision, and published defences blocked under 30% of benchmark attacks. Least privilege and isolation do more.

host0's own MCP server is control-only: it lists, renames, shares and deletes apps but never deploys code, and it signs people in with OAuth 2.1 and PKCE. Apps deployed to host0 are private by default.

Methodology#

This post draws on five research passes run at the start of October 2026: vulnerabilities and CVEs, attacks and benchmarks, code studies and malicious servers, exposure and incidents, and the response (spec, clients, registries, guidance and market). Each was limited to primary sources: advisory databases, NVD records, the specification and its git history, arXiv papers (dated by their first version), security-vendor reports and company announcements. Aggregator and "statistics" sites were used only as leads. Every fact is dated on or before 2 October 2026. Before publishing we re-opened the single-source pages behind the headline claims (the Fudan, MCPTox, census, cross-channel and competition papers, Censys, Wiz, Pluto Security, OX Security, Postmark, the registry's moderation policy and its takedown issue) and confirmed the quoted figures were still there.

Three numbers are our own computations:

• The advisory count. We pulled GitHub's reviewed advisories published since 1 November 2024 (15,319), NVD records matching "MCP", "Model Context Protocol" or "mcp-server" (730 since November 2024), and the published advisories of all 42 modelcontextprotocol repositories (57). We kept a record if any text matched MCP and either the product is MCP software or the vulnerable code is the product's MCP feature; we excluded 126 false or mention-only hits and 16 borderline cases. We deduplicated by CVE (else GHSA id), dated each advisory by its earliest public date, took severity from GitHub's label or NVD's CVSS score, the class from CWE ids, and the component from rules on package names and descriptions. 776 were public by 30 September (788 by 2 October); the charts and shares use the 776. CISA's catalog was checked for entries added on or before 2 October.
• The registry pull. We paged through the official registry's public API (/v0/servers?limit=100&version=latest) and deduplicated by server name: about 40,000 servers, 25,224 with a remote endpoint and 16,398 with an installable package. Credential shares come from each entry's declared headers, secrets and URLs.
• The probe. From registry servers with a fixed https:// remote URL, we kept one per hostname, shuffled them with a fixed seed and took 300. Each got one unauthenticated JSON-RPC initialize (or, for SSE, one GET), a 5-second timeout and no retries, with a user agent naming host0. We never called a tool.

The malicious-package count is also ours: OSV's npm and PyPI malicious-package records for package names containing "mcp", dated by OSV publication, as of early October.

Limitations:

• Advisory counts are a floor and a moving one. GitHub's global database lags repository advisories, NVD records count only if their text says MCP, and recent months will rise as late CVEs are published. Some of the 2026 rise reflects more CVE authorities looking, not only more bugs.
• Class and component labels are rule-based. Expect a few percent mislabelled; read the shares as rounded.
• Exposure scans aren't comparable. Each used its own method and definition; vendor scans are the vendor's claim.
• Benchmarks measure a lab. Attack success rates depend on the benchmark's setup and can't be compared across benchmarks or read as real-world rates.
• Our probe is a sample of listed servers on one day. 300 hosts, about ±6 points on the 52%. A completed handshake isn't proof of open tools.

Open questions#

1. More bugs, or more people looking? How much of the 2026 rise in advisories comes from new CVE authorities assigning in bulk rather than from more vulnerable code?
2. How often tool poisoning happens in the wild. Lab attacks work, but measured prevalence ranges from zero to 5.5% depending on the detector.
3. When exploitation of the KEV-listed bugs began. Only the listing dates are public.
4. Whether exposure is growing. No group has repeated a large internet scan with the same published method.
5. How the newest models fare on the main benchmarks. MCPTox and MSB haven't been rerun on the 2026 frontier models.
6. Whether the 2026-07-28 authorization changes have shipped. How many clients validate the issuer, and how many servers have dropped dynamic client registration?