Key takeaways
- OX Security analysed 11 public MCP registries and reported nine as compromisable or already compromised, carrying packages impersonating legitimate servers.
- Independent scans put the share of public MCP servers with exploitable flaws at 30% to 82% depending on the scan. Only about 8.5% use OAuth.
- Adoption ran ahead of the trust model: 41% of surveyed software organisations report MCP servers in limited or broad production, against roughly 10,000 records in the official registry as of 24 May 2026.
- The 2026-07-28 release candidate requires clients to validate the
issparameter per RFC 9207, closing a mix-up attack that MCP's one-client-many-servers pattern makes unusually easy. - Treat MCP servers as dependencies, not as configuration. Pin versions, allowlist by name, and review what each one can write to.
Does ChatGPT recommend your competitor instead of you?
Check how AI assistants describe your company, and whose name they give when someone asks for a recommendation in your category. Run an audit today, from $19.
OX Security examined eleven public registries where teams go to find MCP servers. It reported nine of them as compromisable or already compromised, some carrying packages that impersonated legitimate servers.
That is a supply chain finding, not a protocol finding. And it arrived after 41% of surveyed software organisations had already put MCP servers into production.
How did the connector layer become infrastructure this fast?
Because it solved a problem everybody had, and it solved it without asking anyone’s permission.
Before MCP, every integration between a model and a tool was bespoke code inside one application. After it, a connector written once is reachable from any client that speaks the protocol. That is a genuine improvement and it explains the adoption curve. The official registry passed roughly 10,000 server records by late May 2026.
What did not arrive at the same speed was a way to decide which of those ten thousand you should trust.
| Measure | Reported figure | What it tells you |
|---|---|---|
| Organisations running MCP in production | 41% | The dependency is already load-bearing |
| Records in the official registry | ~10,000 | Curated population, as of 24 May 2026 |
| Servers exposed on the internet | ~200,000 | The uncurated population is 20x larger |
| Public servers with exploitable flaws | 30% to 82% | Range varies by scan and by definition of flaw |
| Public servers using OAuth | ~8.5% | Most authorise by something weaker |
| Registries found compromisable, of 11 | 9 | The discovery layer is part of the attack surface |
The 20x gap between the curated registry and the exposed population is the part worth sitting with. Most MCP servers your agents could reach were never in a registry at all.
What actually changed in the specification?
The 2026-07-28 release candidate added a requirement that clients validate the iss parameter on authorization responses, following RFC 9207.
In plain terms: when a client is redirected back after authorising, it must check which authorization server actually issued the response rather than assuming. Skipping that check enables a mix-up attack, where a malicious server persuades a client to send it a token minted for somebody else.
This class of attack is old. What makes it sharper in MCP is the deployment shape. One client typically holds relationships with many servers at once, which is precisely the condition mix-up attacks need.
The Server Cards proposal
The roadmap also carries Server Cards: metadata exposed at a well-known URL so registries and clients can read what a server claims to do without connecting to it first. It does not verify anything on its own. It does make the claims machine-readable, which is the precondition for anyone verifying them later.
Why is this a dependency problem and not a security problem?
Because framing it as security sends it to the wrong team and the wrong process.
Your organisation almost certainly already has a way to decide which npm packages may enter a build, who reviews a new dependency, and how versions are pinned. It probably has none of that for MCP servers, because MCP servers arrive through configuration files rather than through package manifests, and configuration does not get reviewed.
That is the whole gap. Not a missing control, a missing category.
What should you do this week?
Four changes, none of which requires a new tool.
| Control | What it prevents | Effort |
|---|---|---|
| Explicit allowlist of servers by name and origin | An agent reaching a server nobody approved | Hours |
| Pin exact versions, never track latest | A trusted server changing under you | Hours |
| Review write scopes per server | A read-only integration quietly gaining write access | A day |
| Require OAuth for anything touching private data | Credentials in configuration files | Varies by server |
Version pinning carries more weight here than it does for ordinary packages. An MCP server is not just code you call. It is code that describes its own capabilities to your agent, which means a changed tool description silently changes what your agent believes it can do.
The question for your next architecture review
Not “is MCP secure”. Ask: can anyone in this room list every MCP server our agents can reach, and who reviewed each one? If the answer takes longer than a minute, you have a dependency inventory problem wearing a protocol costume.
Frequently asked questions
Are public MCP servers safe to use in production?
Not by default. Independent scans report between 30% and 82% of public servers carrying exploitable flaws, and OX Security reported that nine of eleven public registries it examined were compromisable or already compromised. Treat a public server as untrusted third-party code, because that is what it is.
How many MCP servers are there?
The official registry held roughly 10,000 server records as of 24 May 2026. Separate 2026 reporting puts the number of exposed servers reachable on the internet at around 200,000, which is a different and much larger population than the curated registry.
What is the iss parameter validation in the MCP specification?
A mitigation added in the 2026-07-28 release candidate. Clients must validate the issuer identifier returned on an authorization response, as specified in RFC 9207. It closes an authorization server mix-up attack that is more exploitable in MCP because one client typically talks to many servers.
How should a platform team decide which MCP servers to allow?
The same way it decides which packages to allow. Maintain an explicit allowlist, pin exact versions rather than tracking latest, review the write scopes each server requests, and require OAuth where the server touches anything you would not publish.
Method and sources
- OX Security analysis of 11 public MCP registries, reported in 2026. Source for the finding that nine were compromisable or already compromised.
- National Security Agency, Model Context Protocol (MCP): Security Design, Cybersecurity Information Sheet, June 2026. Consulted for the description of MCP's underspecified areas.
- Model Context Protocol blog, The 2026-07-28 MCP Specification Release Candidate. Source for the RFC 9207 issuer validation requirement and the Server Cards proposal.
- Stacklok 2026 software report, cited for the figure of 41% of surveyed organisations running MCP servers in limited or broad production, and registry counts of roughly 10,000 records as of 24 May 2026.
- Scan figures of 30% to 82% flawed servers, 8.5% OAuth adoption and approximately 200,000 exposed servers come from 2026 security write-ups aggregating multiple independent scans. We have not reproduced these scans and cite them as reported.