Exposed MCP Servers Nearly Triple as Cloud Takeover Risk Grows

The count went up, and so did the stakes

In mid-2025, Trend Micro warned that Model Context Protocol (MCP) servers left open on the network were acting as backdoors into private data. Its first scan found 492 instances that used neither client authentication nor traffic encryption.7 In its follow-up, the company says that number has grown to 1,467, close to three times the original. It also reframes the problem: the danger is no longer just leaked data but attackers taking control of the cloud environments these servers run in.11

The headline number matters, but the change in how the threat is described matters more. MCP was built as a universal connector that lets AI agents reach databases, internal APIs and cloud services. When one of these servers is exposed, the issue is bigger than one unprotected endpoint. Anyone who finds it can use it to reach whatever it was set up to connect to. Trend Micro now argues that this reach can extend to the cloud account itself.11

What the new research found

Trend Micro's updated scan points to rushed deployment. Of the 1,467 exposed servers, 1,227 still use the legacy Server-Sent Events (SSE) transport, which the company calls long deprecated.11 The researchers found a tool named "execute_sql" on 70 hosts and an agent-memory server called Graphiti on 39. They also found at least three servers exposing a "progress_note" feature that reaches patient medical records.11

The main new finding is a set of vulnerabilities in cloud-focused MCP servers. Trend Micro reported critical flaws through its Zero Day Initiative in two unofficial MCP servers, one for AWS and one for Azure. Each carries a CVSS score of 9.8, and two have CVE numbers: CVE-2026-5058 and CVE-2026-5059, both in aws-mcp-server.11 The write-up has one inconsistency. Its disclosure table names Microsoft as the vendor for the Azure-related bug, while the main text describes both servers as unofficial. Readers should take the vendor attribution with some caution until a formal advisory clears it up.11

According to the researchers, the flaws are command-injection bugs that let an attacker run arbitrary commands on the host machine.11 They walk through what that means in practice. Picture an aws-mcp-server running on an EC2 instance with a broadly scoped IAM role attached. An attacker who gets command execution could query the instance metadata service, take the role's temporary credentials, and use them to reach S3, DynamoDB or Lambda. From there they could create new IAM users to keep their access.11

Secret handling is the other half of the problem. Trend Micro examined more than 19,000 MCP server codebases and found that about 48% tell users to store secrets in .env files or plaintext JSON.11 Put that next to a server open to the internet, and the attacker may not need an exploit at all. Reading the configuration can be enough.

Independent research tells the same story

The strongest reason to take Trend Micro's update seriously is that other researchers, using different methods, keep finding the same pattern.

Wiz looked at the problem from inside cloud environments instead of scanning the internet. It found MCP in about 80% of the environments it observed, and about one in six of those exposed at least one MCP server.12 Among the exposed servers, about 70% gave their full tool list to anonymous callers, about 42% returned real data when a tool was called, and about 10% exposed a sensitive backend.12 Wiz also confirmed a smaller set of servers where server-side request forgery (SSRF) reached the cloud metadata endpoint and returned temporary credentials. This is the same path to credential theft that Trend Micro describes in theory.12 Wiz added that almost all of the exposed servers still use the original 2024-11-05 protocol version, which predates the addition of authentication to the spec in March 2025.12

An academic study using a tool called Corvus went further than counting, actively testing servers during July 2026. Researchers confirmed 640 production MCP servers and tested 414 of them in depth. Of those, 91.8% lacked OAuth. They also found 687 tool instances offering shell execution with no access control, plus 68 reportable vulnerabilities including SSRF against cloud metadata services.2 The authors argue that the gap is structural, not just careless developers. MCP was originally designed around local stdio transport, where the operating system provides isolation. HTTP transport came later, and the standard onboarding path still produces an unauthenticated server by default.2

There is also evidence that attackers are already looking. Reporting from July 2026 describes broad internet scans probing MCP endpoints such as POST /mcp and GET /sse, as well as Claude and Cursor MCP configuration files. Those scans came with SSRF attempts aimed at Google Cloud's metadata service and the 169.254.169.254 address.15 That pattern lines up with the cloud-pivot scenario that Trend Micro and Wiz both describe.

Where the numbers disagree

The size estimates vary widely, and readers should not treat any one figure as the true count. Trend Micro reports 1,467 exposed servers.11 Knostic found 1,862 through Shodan in 2025, and every one of the 119 it checked by hand would list its tools without authentication.4 Censys counted 12,520 MCP services reachable from the internet as of April 28, 2026, a figure later reported as passing 21,000 by early May.3 Measured authentication rates also differ. Several studies settle at roughly 38–40% of servers with no authentication at all5, while the Corvus study found that more than nine in ten lacked OAuth specifically.2

My reading is that these figures measure different things rather than contradict each other. Trend Micro counts servers with neither authentication nor encryption, which is a narrow definition. Censys counts every reachable MCP service. The Corvus authors separate "no OAuth" from "no credential of any kind."2 The Corvus team also found that 41.6% of confirmed servers disappeared within about three days, which makes any single snapshot unreliable.2 The figures disagree on how big the problem is, but they all show that it is growing and that it is concentrated in the cloud. Even Trend Micro's first study found about 74% of exposed servers hosted on major cloud providers.14

Why the vendors' own servers matter

It would be easy to blame hobbyist code for all of this, but the record does not support that. Dark Reading reported an exploit chain against Anthropic's own Git and filesystem MCP servers, plus an SSRF flaw in Microsoft's MarkItDown MCP server. Researchers estimated that a similar SSRF exposure could be present in about 36.7% of the more than 7,000 servers they analyzed.16 Microsoft's @azure-devops/mcp package was found to be missing authentication, tracked as CVE-2026-32211 with a CVSS score of 9.1.6 One security advisory counted more than 40 CVEs disclosed against MCP implementations between January and April 2026 alone.

This shows that the insecure default comes from the ecosystem as a whole, including its biggest vendors. When the companies that define and promote the protocol ship servers with the same weaknesses as weekend projects, organizations cannot assume that a well-known name means a server is safe to put on the internet.

Treating MCP as an identity problem

Several analysts now say the right framing is identity, not just networking. One identity-focused analysis argues that if a server answers tools/list without authentication, it is advertising what it can do to anyone, which crosses a privilege boundary before any tool is called.17 Ox Security, reporting this week, adds a governance concern. MCP has no concept of geographic region, so AI agents can connect to servers outside the residency and zero-trust controls a company applies to its own workloads. Some MCP hostnames referenced by agents no longer resolve and could be bought by an attacker.18

Trend Micro's recommendations follow from this. Treat MCP servers as critical cloud infrastructure, not experiments. Keep them on private subnets with no public IP. Replace hardcoded credentials with cloud-native secrets management. Require OAuth 2.0 for client access. Run servers in containers to limit the damage if one is compromised.11 The Corvus authors put more of the burden on the ecosystem. They call for SDKs to enable OAuth 2.1 by default on HTTP transport, for registries to display each server's authentication status, and for hosting platforms to flag unauthenticated servers that offer shell tools.2

The bottom line

Trend Micro's update matters because it ties together problems that are usually discussed separately: unauthenticated endpoints, plaintext secrets, command-injection flaws and cloud metadata services. Each is serious alone. Combined, they make an exposed MCP server a route to taking over a cloud account. Other researchers have confirmed each step of that route with data from cloud environments, active testing and observed attacker scanning.12215 The exposed-server counts will keep changing. What has not changed in a year of research is that the default MCP deployment is not safe to put on the internet. Until SDKs, registries and the specification require authentication instead of offering it as an option, these exposures will keep happening.