BadHost (CVE-2026-48710): is your MCP server actually affected?

28 May 2026 · mcpsecuritystarlettefastapivulnerabilityclaude-code

The headlines this week say millions of AI agents are imperiled by a critical vulnerability in an open-source package. If you run MCP servers, the honest answer to “am I affected?” is: it depends entirely on your transport — and most of the panic-reading skips that part.

Here’s the precise version.

What BadHost is

BadHost (CVE-2026-48710) is a flaw in Starlette, the ASGI framework that sits under FastAPI and is pulled into roughly 325 million downloads a week. A single crafted character in the HTTP Host header bypasses path-based authorization — the “block /admin, allow /public” style of route protection a lot of apps lean on.

Because Starlette is the routing core of FastAPI, the blast radius includes FastAPI apps, vLLM, LiteLLM, and any MCP server that serves traffic over HTTP.

The official score is CVSS 6.5 (Moderate) — Starlette assessed it as a library-level issue. That number understates the risk for one specific class of target, which happens to be exactly the class MCP operators run. More on that below.

The fix shipped in Starlette 1.0.1.

The part the headlines skip: transport decides everything

MCP servers can talk to a client over different transports, and the transport is what determines whether BadHost can reach you:

• stdio — the server runs as a subprocess and communicates over stdin/stdout. This is the default for local Claude Desktop and Claude Code servers. There is no HTTP layer, no Host header, and nothing for BadHost to bypass. A pure-stdio server is not exposed to this bug.
• HTTP / SSE / streamable-HTTP — the server is an ASGI app (usually Starlette + uvicorn) listening on a port. This is the exposed configuration, and it’s typically how you run a shared MCP server that a whole team connects to.

Note the distinction that trips people up: it’s about transport, not local-vs-remote. An MCP server bound to localhost over HTTP still has the Starlette layer underneath it. “I only run it locally” is not the same as “I’m on stdio.”

And here’s the sting: the HTTP-transport servers are usually the team-shared ones — the servers most likely to hold the most credentials. Which is why 6.5 undersells it.

Why this is worse than “Moderate” for MCP

An MCP server’s whole job is to connect an AI agent to external systems: email, calendars, databases, third-party APIs. To do that, it stores credentials for each of them. An MCP server is, structurally, a credential aggregator with a model-friendly interface bolted on top.

So an auth bypass on an MCP server isn’t “someone reached an endpoint they shouldn’t have.” It’s “someone reached the box that holds the keys to your inbox, your database, and your SaaS tokens.” That’s why independent analysis (X41) rates the downstream impact closer to critical even though the library-level score is moderate — and it’s the same reason MCP has already collected 40-plus CVEs of its own in 2026.

Check in 30 seconds, then fix

1. What transport do your MCP servers use? If everything is stdio, BadHost doesn’t reach you — but keep reading, because the lesson still applies.
2. For anything serving HTTP (an MCP server, vLLM, LiteLLM, any FastAPI app): run pip show starlette. Anything below 1.0.1 is vulnerable.
3. Upgrade to Starlette ≥ 1.0.1. FastAPI pulls Starlette in transitively, so pin/bump it explicitly — don’t assume a FastAPI update already did it.
4. Don’t let path-based auth be your only gate. It’s the exact layer BadHost defeats. Put real authentication in front of the server and treat path rules as defense-in-depth, not the defense.
5. Scope every stored credential to the minimum. Read-only wherever the use case allows. If a server is compromised, the blast radius is whatever its credentials can do.

The durable lesson

Patching Starlette closes this hole. The principle that keeps the next one small is the one worth building every MCP server around: least privilege at the boundary.

• Prefer stdio for single-user, local servers — no listener, smaller attack surface.
• When you do expose HTTP, authenticate in front of it and never rely on a single layer.
• Scope credentials tightly and make servers read-only by default. The Gmail reader we ship can read and draft but cannot send — a leak of its credentials can’t email anyone.
• Assume the server holds keys, because it does, and design for the day it gets reached.

None of that is novel. It’s just unevenly applied — and BadHost is a reminder that “the framework handles auth” is an assumption worth checking.

We do MCP security reviews as part of our audit work, and we open-source the guardrails we build — lint hooks, test patterns — at github.com/Alienbushman/mcpdone-samples. But the most useful thing today is the Starlette bump above. Go do that first.