Attack scenario 4: Exposed Remote MCP Servers with no authentication

Attack scenario 4: Exposed Remote MCP Servers with no authentication

The previous three scenarios assume the attacker needs some form of access, whether a malicious package, a stolen credential, or crafted input data. This scenario requires none of those. The MCP server is simply open to the internet.

How the attack works

A team deploys an MCP server as a remote HTTP service so that multiple developers can share it. During development, they bind the server to 0.0.0.0:3000 without authentication, intending to add auth before production:

The server goes to production with this configuration still in place. An attacker discovers the exposed endpoint through port scanning or Shodan, connects as an MCP client, and begins invoking tools such as listing database tables, reading files, and querying internal APIs. There is no authentication challenge, no rate limiting, and no audit trail. A related risk was demonstrated in CVE-2025-49596, where a developer tool exposed a local MCP interface over HTTP without proper origin validation. Researchers showed that a malicious website could send requests to the local MCP port through the user's browser, effectively bridging the public internet to an MCP server that ought to be local-only.

Why the attack succeeds

Local MCP servers running over stdio do not require authentication by design because they rely on OS-level process isolation. When teams transition to remote MCP servers over HTTP, they sometimes carry this assumption forward, deploying the server without authentication because it worked fine locally without it. The MCP specification includes optional OAuth 2.1 support for remote servers, but it is not required and is not enabled by default.
Trend Micro's research confirmed the scale of this problem. The 492 exposed MCP servers they discovered lacked client authentication and traffic encryption, collectively exposing 1,402 tools. Over 90% offered direct read access to connected data sources, including databases, cloud storage, and internal APIs.

What to look for

• MCP server processes listening on public-facing ports or bound to 0.0.0.0
• Unexpected inbound connections to MCP server endpoints from external IP addresses
• Tool invocations from clients that did not go through your standard authentication flow
• MCP servers appearing in Shodan, Censys, or similar internet scanning databases

How to defend against it

• Never expose MCP servers to the public internet: Deploy remote MCP servers in private subnets, behind VPNs, or within service meshes that enforce mutual TLS.
• Require authentication for all remote deployments: Enable OAuth 2.1 or another authentication mechanism for every MCP server that communicates over HTTP. Treat any unauthenticated remote MCP server as a critical security vulnerability.
• Monitor for exposure continuously: Run periodic scans of your external attack surface to verify that no MCP servers are accidentally exposed. Include MCP-specific checks in your security review process for infrastructure changes.

An exposed MCP server can fail simply because it is reachable. When a credentialed execution layer is open to the internet without authentication, compromise becomes a matter of time.