Remote MCP servers: 40% unauthenticated, OAuth broken on the rest

What is this?

A May 2026 arXiv paper, A First Measurement Study on Authentication Security in Real-World Remote MCP Servers (cs.CR, 2605.22333), is the first large-scale look at the authentication layer of remote Model Context Protocol servers — the network-reachable programs that expose tools (database queries, API calls, file access) to LLM agents. Most prior MCP research focused on prompt injection and tool poisoning; this work targets the protocol-layer question of who is allowed to connect at all.

The headline measurement is blunt. Out of 7,973 validated live remote MCP servers, 3,233 (40.55%) expose their tool interface with no authentication whatsoever — any client can invoke tools or trigger API requests without presenting a credential. Of the rest, OAuth is the dominant mechanism (2,428 servers), and when the authors manually tested a fully reproducible subset of 119 OAuth-enabled servers, every single one exhibited at least one authentication flaw — 325 flaws in total. Nine were serious enough to receive CVE IDs through responsible disclosure (the CVE-2026-26384 to CVE-2026-26390 series). This complements the VIPER-MCP code-quality scan and the broader exposure counts: the servers are not only buggy and over-exposed, their front door is frequently unlocked.

How it works

The MCP spec made OAuth 2.1 with PKCE mandatory for HTTP transports in its 2025-03-26 revision, and the 2025-11-25 release prioritised Client ID Metadata Documents while keeping Dynamic Client Registration (DCR) as a backward-compatibility fallback. In practice, remote servers lean on DCR because they must accept heterogeneous clients — IDEs, CLIs, desktop apps, cloud agents — that cannot be pre-registered by hand. The paper distils three recurring traits of these deployments and builds a taxonomy of nine flaw types across four categories around them. Described at the level of mechanism, not payload:

Category                          Representative flaw            Effect
--------------------------------  ----------------------------  ---------------------------
C1 Dynamic Client Registration    Malicious DCR binding         Anonymous registrant submits
   (96.6% of tested servers)      (F1, 95.8%)                   an attacker redirect_uri and
                                                                gets a valid client_id back.
C3 Open Client Environment        PKCE downgrade (F5, 68.1%)    Server accepts a missing or
   (85.7% of tested servers)                                    "plain" code_challenge,
                                                                nullifying PKCE binding.
C2 Delegated Authorization        Layer inconsistency (F3)      PKCE enforced on the first
   (15.1% of tested servers)      Nested context pollution (F4) hop but dropped on the
                                                                upstream hop; unvalidated
                                                                redirect_uri inside `state`.
C4 Common OAuth misconfig         Standard OAuth hygiene gaps   Reuse/replay of codes, weak
                                                                state/CSRF handling.

The dominant failure is the simplest: a DCR endpoint that accepts any redirect_uri from an unauthenticated registrant. An attacker registers a client pointing at a server they control, crafts an authorization URL with that callback, and social-engineers a victim into completing the consent flow. The authorization code is then delivered to the attacker, who exchanges it for an access token and takes over the victim’s MCP session — and, through delegated authorization, the upstream service accounts behind it. When a server also allows PKCE to be omitted, stealing the code is sufficient on its own. No malicious MCP client is required; the attacker only needs to send HTTP requests to public endpoints and host a page. No working exploit is reproduced here — the canonical reference is the paper and the assigned CVE records.

Why it matters

Remote MCP is becoming the connective tissue between agents and real systems, which makes its auth layer load-bearing. Two findings should change how teams treat it. First, 40% unauthenticated is a directly exploitable exposure, not a theoretical one: those servers hand tool execution to anyone who can reach them, and per Adversa’s June 2026 roundup, Censys counted 12,520 such services on the public Internet. Second, authentication being present is not the same as authentication being correct — every OAuth server the authors could test was flawed, and the most common flaw (open DCR binding) leads straight to account takeover. Because the MCP server frequently acts as both an OAuth resource server and an OAuth client to upstream services, a single broken hop becomes a confused-deputy problem spanning independently operated platforms.

Defenses

The fixes are standard OAuth hygiene that MCP server code routinely skips.

1. Lock down Dynamic Client Registration. Do not accept arbitrary redirect_uri values from anonymous registrants. Allowlist exact callback URIs, require authentication on the registration endpoint, and prefer Client ID Metadata Documents (the 2025-11-25 spec’s preferred mechanism) over open DCR.

2. Enforce PKCE, reject downgrades. Require S256; reject requests that omit code_challenge or use the plain method. PKCE is the primary binding in open-client environments where no client_secret can be protected.

3. Validate redirect URIs by exact match and bind the flow. Keep authorization codes single-use and short-lived, bound to the same client and PKCE verifier; preserve state for CSRF; integrity-protect any URI embedded in state.

4. Keep PKCE consistent across delegated hops. If the first hop enforces PKCE, the upstream request must too — layer inconsistency silently voids the guarantee.

5. Authenticate every remote server and de-expose the rest. The single highest-impact move: put auth in front of each remote MCP server and take unauthenticated ones off the public Internet. Pair with attested tool-server admission and the NSA’s MCP security design considerations as a baseline.

Status

Item	Reference	Date	Notes
Measurement paper	arXiv:2605.22333 (cs.CR)	2026-05	First auth-security study of remote MCP servers
Exposure	Paper	2026-05	7,973 live servers; 3,233 (40.55%) with no authentication
OAuth flaws	Paper	2026-05	119 testable servers, all flawed; 325 flaws total
Dominant flaw	Paper	2026-05	Open DCR binding in 95.8% → authorization-code hijack
Disclosure	Paper	2026-05	Responsibly disclosed; 9 CVE IDs assigned (CVE-2026-26384–26390)
Ecosystem context	Adversa / Censys roundup	2026-06-04	12,520 Internet-exposed MCP services

The right framing is not “OAuth is broken” — it is that remote MCP servers re-implement OAuth under deployment pressure and get the hard parts wrong, while a plurality skip authentication entirely. Treat your MCP auth layer like any other public OAuth surface: lock down registration, enforce PKCE, and put a credential in front of everything that can run a tool.