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. 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.

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. But the payload already ran. OX Security described this as "execute first, validate never," and that's accurate.

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 with zero authentication.

The attack chain: 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. A developer visits a malicious website. The site's JavaScript reaches MCP Inspector through the 0.0.0.0 bypass. 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:

• 200,000+ vulnerable server instances
• 150 million+ cumulative downloads across affected packages
• 7,000+ publicly accessible MCP servers
• 10+ high or critical CVEs
• 200+ affected open-source projects

Why serverless reduces the MCP risk surface

The STDIO model is essentially "download this script, run it as a local server, trust it." 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. There's no customer-managed long-running daemon process exposed to clients.

No client-controlled process spawning. When Lambda serves as an MCP server, communication happens over HTTPS. 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.

Auth is infrastructure, not application code. STDIO local transports rely on local process trust. With Lambda, you get IAM auth on Function URLs and IAM or Cognito authorizers on API Gateway. Auth is a configuration toggle, not something you need to build yourself.

Lambda as an MCP server: build it yourself

IAM auth with SigV4 — Set your Function URL's AuthType to AWS_IAM and every request requires Signature Version 4 signing. No tokens to manage, no OAuth dance, no plaintext API keys.

OAuth 2.1 for external agents — Front the Lambda function with API Gateway, attach a Cognito authorizer. API Gateway validates the token before the request ever reaches your function.

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.

Working examples

• mikegc-aws/Lambda-MCP-Server: Native Streamable HTTP on Lambda with IAM auth
• awslabs/run-model-context-protocol-servers-with-aws-lambda: Official wrapper for existing STDIO servers
• aws-samples/sample-serverless-mcp-servers: Collection of agent and server patterns

AgentCore: let AWS manage your MCP servers

Amazon Bedrock AgentCore centralizes auth, policy enforcement, and observability into a single endpoint. The Gateway sits in front of all your MCP servers. Interceptors let you filter which tools an agent can see based on caller identity and context. AgentCore Runtime handles containerization, scaling, and session isolation — you write the server code, AgentCore runs each session in a dedicated microVM.

But what about local file access?

If your MCP tools need local file access, they still need to run locally. That's a real limitation of any remote MCP server. 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.

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.

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.