200,000 MCP Servers Are Exposed. Here's Why Serverless Is Safer.

serverlesslambdamcpsecurityaws

I’ve spent a lot of time thinking about where MCP servers should live. I work with remote MCP servers constantly and do a lot of the architecture work around them. But I also use plenty of local ones. There’s a simplicity to npx @modelcontextprotocol/server-whatever that’s hard to argue with.

Then MCP crossed 300 million SDK downloads a month in April 2026, and a few days later, OX Security published a disclosure that put a number on what I’d been turning over in my head: the most popular MCP transport has no authentication, and 200,000 servers are running it in production.

That got me to finally put my thoughts together. The short version: the subprocess-spawn vulnerability that OX Security disclosed is specific to STDIO, the local transport. Remote MCP servers avoid that specific attack path, though they introduce different web and API security considerations. And if you’re going to run remote MCP servers, I think serverless is the best place to do it.

Let’s walk through it.

What OX Security found in MCP’s STDIO transport

The root cause is in MCP’s STDIO transport, the mechanism designed for local MCP server communication. When an MCP client connects to a server via STDIO, it passes a StdioServerParameters object to the SDK. That object contains a command field and an args array that tell the SDK which process to spawn.

Here’s the thing: the official MCP SDKs across Python, TypeScript, Java, and Rust do not sanitize those fields before passing them to the operating system. Whatever strings arrive get executed as shell commands on the host machine.

The execution sequence makes it worse. The command runs first. Then the MCP handshake tries to validate it as a legitimate server. Then the handshake fails, and the error gets caught. But the payload already ran. OX Security described this as “execute first, validate never,” and that’s accurate.

Applications where user input can influence MCP server configuration are at risk. That includes AI frameworks that let users configure custom STDIO servers, coding IDEs that process prompt injections targeting MCP configs, and MCP marketplaces distributing server packages. OX researchers demonstrated it with a single 300ms request that executed commands on six commercial services with real paying customers.

CVE-2025-49596: Browser to backdoor

The specific CVE that got the most attention was CVE-2025-49596, a CVSS 9.4 critical vulnerability in MCP Inspector, Anthropic’s official debugging tool. The Inspector runs a proxy on localhost that accepts commands from its browser UI. There’s zero authentication between the two components.

The attack chain goes like this. On macOS and Linux, browsers allow websites to make requests to 0.0.0.0, which the OS silently redirects to 127.0.0.1 (Windows blocks this at the OS level and isn’t affected). A developer visits a malicious website. The site’s JavaScript reaches MCP Inspector through the 0.0.0.0 bypass and sends unauthenticated commands to the proxy. Arbitrary code runs on the developer’s machine. No phishing, no suspicious downloads. Just a website visit.

How many MCP servers are affected

The numbers from the OX disclosure are hard to ignore:

Anthropic has described the behavior as “expected” and positions input sanitization as a developer responsibility. That’s a reasonable stance for a protocol spec, but it means the security model depends entirely on every developer getting it right.

Why serverless reduces the MCP risk surface

The STDIO model is essentially “download this script, run it as a local server, trust it.” If you’ve spent any time building SaaS, that feels like a step backward. In a hosted model, the server updates transparently on the next call. Security patches land without anyone reinstalling anything. With STDIO, every developer’s machine is its own attack surface, and security depends on every individual getting it right on every machine they run. That’s the same lesson SaaS learned years ago, and MCP is learning it again.

The vulnerability exists because of three assumptions baked into the STDIO transport: there’s a persistent process running on the host, that process has shell access, and there’s no authentication layer between the client and the process.

Serverless compute inverts all three.

No persistent process to hijack. Lambda functions run in Firecracker microVMs, isolated execution environments that the Lambda service manages. Environments may be reused for performance, but there’s no customer-managed long-running daemon process exposed to clients. The function runs your handler, returns a response, and the environment freezes or gets destroyed.

No client-controlled process spawning. When Lambda serves as an MCP server, communication happens over HTTPS, either through Lambda Function URLs or API Gateway. The MCP Streamable HTTP transport replaces the STDIO subprocess model entirely. There’s no path for a client to trigger arbitrary process execution on the host. The function receives a structured HTTP request and returns a structured HTTP response.

Auth is infrastructure, not application code. This is the part I keep coming back to. STDIO local transports rely on local process trust rather than explicit per-request authentication. With Lambda, you get IAM auth on Function URLs and IAM or Cognito authorizers on API Gateway. You can still create open endpoints if you choose to, but auth is a configuration toggle, not something you need to build yourself. That’s a meaningful difference.

MCP tools are stateless, request-response operations. The agent calls a tool, gets a result, moves on. The agent maintains conversational state, not the server. Lambda is a stateless, request-response runtime. For most tool calls, you don’t need sessions or long-lived streaming connections. You need auth, isolation, and ephemeral execution, which is exactly what serverless gives you.

The AWS Security blog reinforces this approach, recommending short-lived credentials, least-privilege IAM roles, scoped tokens, and network controls for any MCP-connected agent.

Lambda as an MCP server: build it yourself

If you want full control over your MCP server, Lambda with a Function URL is the most direct path.

IAM auth with SigV4

Set your Function URL’s AuthType to AWS_IAM and every request requires Signature Version 4 signing. The request body is included in the cryptographic signature, providing both caller identity verification and payload integrity. The calling agent needs lambda:InvokeFunctionUrl permission on the function’s ARN. No tokens to manage, no OAuth dance, no plaintext API keys sitting in environment variables.

The function URL’s resource-based policy adds another layer. You can restrict invocation to specific IAM principals, AWS accounts, or organizations. Combined with IAM condition keys, you can require that requests come from specific VPCs or IP ranges.

This pattern works well when both the calling agent and the MCP server live in the same AWS account or organization. It’s the tightest option with the least overhead.

OAuth 2.1 for external agents

When third-party agents or external applications need to call your MCP server, the MCP specification calls for OAuth 2.1 for remote HTTP servers in production. Front the Lambda function with API Gateway, attach a Cognito authorizer, and the calling agent presents a scoped access token. API Gateway validates the token before the request ever reaches your function.

AWS publishes a CDK construct that wires Cognito, API Gateway, and Lambda together with security defaults applied. You also get rate limiting, request throttling, and WAF integration at the API Gateway layer.

The awslabs STDIO adapter

Already have MCP servers built on STDIO? The awslabs/run-model-context-protocol-servers-with-aws-lambda project wraps existing STDIO-based MCP servers so they run inside Lambda. The STDIO surface stays internal to the Lambda sandbox and is never exposed to the network. Incoming HTTP requests get translated to STDIO messages, piped to the server process, and responses come back as HTTP.

It’s the lift-and-shift option: take an existing local MCP server and deploy it without rewriting it. The key security difference is that the STDIO transport is contained inside a Firecracker microVM rather than running on your workstation or a shared server.

Working examples

You don’t need to build from scratch. These AWS-backed repos are deployable today:

AgentCore: let AWS manage your MCP servers

Lambda handles the compute side well. But once you have a dozen MCP servers across teams, the challenge isn’t keeping them running. It’s keeping auth and access policies consistent across all of them. Configuring IAM on each function individually works at small scale. It doesn’t work when different teams, agents, and external consumers all need different levels of access to different tools.

Amazon Bedrock AgentCore is AWS’s answer to that problem. The Gateway sits in front of all your MCP servers and centralizes auth, policy enforcement, and observability into a single endpoint. Instead of configuring authentication on each server, agents discover tools through the gateway. The interceptors let you filter which tools an agent can see based on caller identity and context, so you can expose one MCP server to multiple consumers without deploying separate instances for each.

If you want to deploy your own MCP servers but skip the infrastructure work, AgentCore Runtime handles containerization, scaling, and session isolation. You write the server code, and AgentCore runs each session in a dedicated microVM with isolated resources. This is the hosted model I was talking about earlier: updates land on the next call, security patches don’t depend on every developer reinstalling something locally.

AgentCore also recently shipped a Managed Harness that lets you define an agent as configuration (model, prompt, tools) without writing orchestration code. The samples repo has a tutorial if you want to try it.

AWS also publishes a reference architecture for deploying MCP servers on AWS with OAuth 2.0, WAF, and CloudFront if your compliance team needs the full stack.

But what about local file access?

Everything above assumes your MCP tools talk to remote services: APIs, databases, cloud resources. That’s where serverless shines. But not every MCP tool fits that model.

STDIO MCP servers run as a local process with the developer’s full filesystem permissions. That’s a security risk. A path traversal vulnerability in an MCP server running in your IDE gives the attacker access to SSH keys, AWS credentials, and environment files. But it’s also what makes tools like the filesystem MCP server and the Git MCP server useful. They need to read your local project files. Lambda can’t do that.

If your MCP tools need local file access, they still need to run locally, with proper path allowlisting and directory restrictions. That’s a real limitation of any remote MCP server, not just serverless, and I don’t want to paper over it. For tools that work with shared files or project artifacts, S3 Files is an interesting middle ground. It mounts an S3 bucket as a local filesystem on your Lambda function, so your tools can read and write files without touching anyone’s local machine. I wrote about building AI agents that share a workspace through S3 Files if you’re curious how that works in practice.

Run your MCP servers somewhere secure

Of those 200,000 exposed STDIO servers, every one that could be redeployed as a remote MCP server behind authenticated infrastructure would remove itself from that count. The protocol spec leaves security to the developer. Serverless gives you a different starting point.

Serverless doesn’t patch the protocol. It removes the conditions the vulnerability depends on. No persistent process, no STDIO surface, and auth on every request by default.

Lambda if you want control. AgentCore if you want managed.

You’ve got options. Use them.

← Back to blog

Comments