Table of Contents

1. Why MCP servers are unusually exposed to this
2. The inventory (2026-07-02 to 07-22, all verified)
3. Class 1: No authentication at all
4. Class 2: Confused deputy and credential reuse
5. Class 3: Missing origin, session, and rebinding validation
6. Class 4: SSRF and egress bypass
7. Class 5: Path traversal and cross-tenant authorization
8. Why this is structural, not unlucky
9. Check these before you connect any MCP server
10. Honestly: what static scanning catches, and what it doesn't
11. The one-line takeaway

#The July 2026 MCP Server Auth Epidemic: 12 Projects, 19 Advisories, and the Reference SDK Itself

If you are wiring an MCP server (Model Context Protocol server) into an AI agent, this is the piece to read before you hit connect.

In three weeks of July 2026, we counted at least 12 distinct MCP projects and 19 security advisories between them. From a severity-9.8 unauthenticated read/write on a memory service, to projects the size of Grafana, n8n, and LiteLLM, and, most tellingly, the official MCP Python SDK reference implementation itself, which accounts for 3 of those advisories in a single month.

Laid side by side, these are not independent accidents. The same class of mistake keeps recurring: authentication, origin validation, and tenant isolation all treated as "later" rather than default. This post skips the theory. First the source-verified inventory, then why it keeps happening, then a checklist you can run against any MCP server before you connect it.

Every entry below was checked against the GitHub Advisory Database firsthand. Severity scores appear only where the advisory publishes one; we don't invent the missing ones.

---

#Why MCP servers are unusually exposed to this

Start with the context, because it shapes every vulnerability that follows.

MCP's original mental model was "a local tool running on your own machine." stdio transport, localhost, a single user. In that model, "only I can reach it anyway" holds, so a lot of implementations simply never wrote authentication, because it looked unnecessary.

The trouble is that the ecosystem quickly grew HTTP, SSE, and WebSocket network transports, letting servers be reached remotely, shared across clients, and deployed to the cloud. And "only I can reach it" collapses the moment you're on a network transport:

• A server bound to 0.0.0.0 is reachable from the whole subnet, sometimes the whole internet.
• An HTTP/WebSocket endpoint that doesn't validate the Host or Origin header can be driven by a malicious web page in the victim's browser via DNS rebinding.
• A server holding downstream API credentials that doesn't check who a request came from becomes a confused deputy: the attacker doesn't need to steal your key, just get the server to use it on their behalf.

Nearly every advisory in July maps back to one of these broken assumptions.

---

#The inventory (2026-07-02 to 07-22, all verified)

#Class 1: No authentication at all

The endpoint serves whoever asks, no questions. The most direct and the most severe.

Project	ID	Severity	Issue
mcp-memory-service	CVE-2026-50027	Critical 9.8	Document API endpoints lack auth; unauthenticated read/write/delete of the whole memory store
mem0	CVE-2026-59706	Critical 9.3	Unauthenticated config API returns LLM API keys in plaintext
netlicensing-mcp	CVE-2026-54446	High 8.1	Unauthenticated use of the server-side NetLicensing API key
MCP Python SDK	CVE-2026-52869	High 7.1	HTTP transports serve session requests without verifying the session
PraisonAI (< 4.6.78)	CVE-2026-61427	Medium	MCP HTTP-stream transport exposed without authentication by default

The mem0 one is worth pausing on: a memory-layer product whose unauthenticated endpoint hands out the OpenAI key. Your AI's memory layer becomes someone else's key vending machine.

#Class 2: Confused deputy and credential reuse

The server has legitimate credentials; the attacker doesn't steal them, they make the server act for them.

Project	ID	Severity	Issue
Grafana MCP Server	CVE-2026-15583	High 8.6	Confused-deputy flaw lets an unauthenticated remote attacker exfiltrate data
meta-ads-mcp	CVE-2026-54547	High 7.4	X-Pipeboard-Token header auth bypass reuses the operator's Meta token
LiteLLM	CVE-2026-59822	High	MCP auth bypass: the OAuth2 passthrough fallback path uses an empty auth object, so any Bearer token reaches the MCP tool chain

LiteLLM is one of the most widely deployed open-source LLM gateways, run by many organizations as a unified LLM control plane. When it breaks, it doesn't break alone; it breaks the entire chain of downstream MCP services behind it.

#Class 3: Missing origin, session, and rebinding validation

The endpoint doesn't check where a connection came from or which session it belongs to.

Project	ID	Severity	Issue
MCP Python SDK	CVE-2026-52870	High 7.6	Experimental task handlers allow any client to access another's task
MCP Python SDK	CVE-2026-59950	High	WebSocket transport does not validate Host / Origin
mcp-atlassian	GHSA-489g-7rxv-6c8q	Medium 6.5	DNS-rebinding TOCTOU that bypasses the earlier SSRF fix (CVE-2026-27826)

The mcp-atlassian entry is a good lesson: they had already patched an SSRF once, and this vulnerability uses DNS rebinding in the gap between check and use (TOCTOU) to get around that patch. The patch wasn't wrong; the timing of the validation was.

#Class 4: SSRF and egress bypass

Project	ID	Severity	Issue
meta-ads-mcp	CVE-2026-54549	High 8.3	SSRF in upload_ad_image
n8n	CVE-2026-59207	High	"Allowed HTTP Request Domains" restriction bypass via AI Agents MCP
n8n	GHSA-vhf8-cg2h-cg3p	Medium	SSRF protection bypass via the MCP Client Node

#Class 5: Path traversal and cross-tenant authorization

Project	ID	Severity	Issue
mcp-atlassian	GHSA-wm45-qh3g-v83f	High 7.7	Arbitrary server-side file read via attachment upload
mcp-atlassian	GHSA-g5r6-gv6m-f5jv	High 7.7	Arbitrary file read via missing path validation in confluence
phantom-audio	GHSA-52vm-mxx8-f227	High 7.7	Arbitrary file write and decode-bomb DoS via an unconfined MCP tool
n8n	CVE-2026-65594	Medium	Member-level users can execute other users' MCP trigger workflows
langbot	CVE-2026-54449	High 8.8	Authenticated RCE via MCP configuration

---

#Why this is structural, not unlucky

One or two projects shipping a bug, you can call individual. Twelve projects making the same class of mistake in three weeks is a pattern. And what elevates this from "a batch of careless downstream projects" to "a structural gap" is the three advisories that belong to the official MCP Python SDK.

The reference implementation is what the ecosystem copies from. When even the reference implementation doesn't verify the session on an HTTP transport and doesn't check Host/Origin on WebSocket, a crowd of downstream projects making the same mistake is not surprising at all. This isn't one careless engineer; it's that across the way MCP servers are built, the security default sits on the wrong side: open by default and remember to close it, instead of closed by default with explicit opt-in.

To be precise: two of the 19 (langbot's RCE, n8n's cross-tenant execution) are really "missing authorization isolation after authentication," not authentication being skipped. But they reflect the same mindset, boundary checks treated as non-essential. The dozen-plus others keep tripping over four things:

1. Carrying the "local, single-user" assumption onto a network transport, so endpoints have no auth at all.
2. Holding downstream credentials without checking request origin, so the server becomes a confused deputy.
3. Not validating Host / Origin / session, so DNS rebinding and cross-client access get in.
4. Making auth an optional setting rather than an enforced default, so most deployments run with it off.

---

#Check these before you connect any MCP server

This checklist is deliberately in a form you can hold up against a server today. You can walk it by hand, but it's exactly where static, pre-deployment scanning helps most, because every item here is visible at the config and code level, before anything gets attacked.

Authentication

• Does the network transport (HTTP / SSE / WebSocket) enforce authentication? Is it on by default, or something you have to enable?
• Is there any endpoint that returns data without a token? Watch the "helper" endpoints in particular: config, health, debug, document.
• On an auth failure, does the fallback path reject, or silently allow? (LiteLLM's was allow-on-fallback.)

Origin and session

• Do the WebSocket / HTTP endpoints validate Host and Origin? (If not, DNS rebinding is waiting.)
• Are sessions bound, or can any client present someone else's session id?
• Is it bound to 127.0.0.1 or 0.0.0.0? The latter means the whole subnet can reach it.

Credentials and delegation

• Can the downstream API keys the server holds be used without checking who made the request? (That's the confused deputy.)
• In multi-tenant setups, can a member-level user reach another tenant's resources?

Egress

• Do tools fetch URLs based on user input? Is there SSRF protection, and does it also hold up against DNS rebinding and direct internal-IP access?

Shared transport

• Do path-related tools (read, write, attachments) validate paths against ../ traversal?

---

#Honestly: what static scanning catches, and what it doesn't

The large majority of that checklist is discoverable at the pre-deployment, static layer: whether an endpoint has auth, which side the default sits on, whether Host/Origin is validated, whether it's bound to 0.0.0.0. None of this requires an actual attack to see, which is exactly the direction UltraProbe has always argued: scanning before you connect is far cheaper than patching after you're hit. (To set expectations honestly: UltraProbe today scans system-prompt defense vectors and website SEO/AEO, not an MCP server's own auth configuration, which for now means walking the checklist above by hand.)

But static scanning is not everything. A TOCTOU rebinding like mcp-atlassian's turns on runtime timing; a poisoned tool response that steers an agent into doing harm is runtime behavior. Those need a runtime defense layer. The honest answer is that you want both: static pre-deployment audit and runtime protection. Drop either layer and something gets through. Anyone selling you a single tool that handles all of it is worth doubting.

For a more systematic view of an agent's whole attack surface, see our developer's guide to the OWASP Agentic Top 10, where MCP-style tool abuse has its own place in the list.

---

#The one-line takeaway

MCP is growing explosively, and that's good. But this one month of July 2026 tells us: the ecosystem's current default leaves security to whatever the implementer remembers to do. Until that default flips, run the checklist above against any MCP server before you connect it. If the reference SDK can ship this, your supply chain has no grounds to assume it won't.

All vulnerability information in this post was verified firsthand against the GitHub Advisory Database, current as of 2026-07-24.