Dora NodaIn April 2026, Censys pointed its scanners at the public internet and counted 12,520 MCP services listening for anyone who cared to knock. Most of them answered without asking who was there. A week later the count had blown past 21,000. Somewhere in that crowd of open doors are servers that can read files, run shell commands, and query production databases — on behalf of whatever agent connects first.
If you are building a platform where AI agents deploy and operate apps, this is your threat model wearing a name tag. A deploy-capable MCP server is remote code execution offered as a product feature. The difference between a feature and an incident is the auth default you ship. This post turns the 2026 measurement studies and CVE catalog into a concrete ship checklist, so your server lands in the minority that did auth right instead of in Censys's next scan.
The checklist, up front
Here is the whole artifact — seven defaults, each paired with the failure it prevents. The rest of the post is the evidence and the implementation notes.
- OAuth 2.1 + PKCE required on every remote endpoint. Kills the 40%-no-auth outcome outright.
- No unauthenticated side paths — registration, metadata, and consent-denial handlers authenticate or don't exist. (MountDev CVE-2026-15015.)
- Dynamic Client Registration locked to a redirect allowlist with ownership and state binding. (n8n CVE-2026-42230, better-auth CVE-2026-67333.)
- Resource-bound tokens (RFC 8707) plus protected-resource metadata (RFC 9728) so a stolen token doesn't redeem anywhere else.
- Per-invocation authorization and logging — identity plus parameters on every tool call, not just at session start. (NSA CSI, May 2026.)
- Tool-definition pinning with re-consent on change, so a server can't go benign-then-malicious. (Invariant Labs rug-pull demo.)
- Pre-deployment vetting of any registry server you bundle or recommend — registry installs are supply chain. (MCPoison CVE-2025-54136.)
If any of these reads as optional to your team, keep reading: each one below has a CVE number, a measurement, or both attached.
12,520 servers, most with the door open
Start with the numbers, because "MCP security is bad" is a vibe and the studies are much more specific than that.
Censys's May 2026 write-up of its April 28 snapshot found 12,520 internet-accessible MCP services on 8,758 IPs, with the count growing past 21,000 by May 6 — and most identified services reachable without authentication. That is the exposure surface: not theoretical, not a honeypot, just production MCP servers answering the public internet.
Then Fudan University did the careful version. Their measurement study of 7,973 live remote MCP servers (arXiv 2605.22333, May 2026) found 40.55% exposing tools with no authentication at all, 29% on static tokens, and only 30.45% on anything OAuth-based. A separate BlueRock scan of roughly 7,000 public servers put it even more starkly: 41% no auth, 8.5% on OAuth.
However you slice the population, a clear majority ships without the spec's required auth — roughly 70% in the Fudan sample once you count static tokens as what they are: not spec-compliant remote authentication.
And the minority that tried? Fudan end-to-end tested 119 OAuth deployments and found at least one authentication flaw in every single one — 325 flaw instances total, with 96.6% carrying Dynamic Client Registration vulnerabilities. Trying and failing beats not trying, but only barely: a broken OAuth handshake still hands tokens to whoever asks.
The CVE ledger matches the measurements. More than 30 CVEs hit MCP infrastructure in the first two months of 2026 alone, 43% of them exec or shell injection. A survey of 2,614 MCP implementations found 82% with file operations vulnerable to path traversal, two-thirds with code-injection risk, and over a third open to command injection. BlueRock's scan separately flagged 36.7% of servers as SSRF-vulnerable. These are not exotic protocol bugs. They are the boring bugs — injection, traversal, missing auth — wearing an agent-shaped hat.
The spec said OAuth. The median deployment said nothing.
Here's the uncomfortable part: the protocol told everyone what to do. The MCP authorization spec has mandated OAuth 2.1 with PKCE for remote servers since the March 2025 revisions, layered with Dynamic Client Registration (RFC 7591), authorization-server metadata (RFC 8414), resource indicators (RFC 8707, required mid-2025), protected-resource metadata (RFC 9728, mandatory as of the March 2026 spec turn), and a further auth-hardening pass in the July 28, 2026 spec. The paper trail is thorough. Client ecosystems enforce it: ChatGPT's custom connectors, for example, won't accept a pasted static token and demand the full OAuth 2.1 + PKCE handshake.
So why does the median deployment look nothing like the spec? Because most MCP servers started life as local stdio processes — a subprocess your IDE spawns, where the OS process boundary is the entire security model and "no auth" is arguably correct. Then Streamable HTTP made them remote, and the habits came along for the ride: the same server code, the same missing auth, now answering TCP.
API keys filled part of the gap, but API keys are not spec-compliant authentication for multi-user remote servers in 2026 — they're a local-development habit stretched past its design limits.
This is the gap your platform has to internalize: "MCP the spec" is an OAuth-hardened remote protocol, and "MCP the median deployment" is an unauthenticated JSON endpoint that runs tools. Every default you ship decides which of those two things your server is. There is no neutral option — an auth field left blank doesn't stay blank, it becomes Censys's next data point.
The attack catalog, with receipts
Abstract warnings don't change defaults. Named incidents do. Here is what the unauthenticated majority actually caught in 2026, organized by the door the attacker walked through.
The open front door: no auth at all. Ruflo's MCP bridge shipped a default docker-compose that exposed POST /mcp with no authentication. Before version 3.16.3, any network attacker could invoke tools/call against terminal_execute, take a shell in the bridge container, read provider API keys, and poison the AgentDB learning store — unauthenticated RCE plus credential theft plus persistent memory corruption from one missing auth check. That July 2026 disclosure reads like a checklist of everything a deploy-capable server must never allow, and it started with the exact default 40% of the internet still ships.
The registration desk: Dynamic Client Registration abuse. DCR exists so clients can onboard without manual provisioning, but every CVE in this family is the same sentence: the registration endpoint trusted the registrant. n8n's CVE-2026-42230 accepted unauthenticated OAuth client registrations with arbitrary redirect_uri values — and when a user denied the consent dialog, the denial handler redirected their browser to the attacker-controlled URI, turning a "no" into a token handoff. MountDev's WordPress MCP connector (CVE-2026-15015) paired a public DCR endpoint with an unprotected authorization endpoint, letting unauthenticated attackers mint administrator-bound tokens with zero admin interaction. And better-auth (CVE-2026-67333) failed to validate redirect URI schemes, so an attacker could register a javascript: redirect URI the server would later return verbatim. Three vendors, one lesson: registration and consent are the auth boundary, not the lobby outside it.
The poisoned menu: tool descriptions as injection payloads. MCP clients feed tool schemas to the model as natural language, which means a malicious server's tool description is an indirect prompt-injection payload with a trusted UI around it. Cyata showed this against Anthropic's own official git MCP server: flaws in every version before December 2025 let an attacker who merely influenced what the assistant read — a README, an issue, a webpage — steer it into unintended actions. MCPoison (CVE-2025-54136) went further: persistent code execution inside developer IDEs via poisoned tool definitions. And Invariant Labs demonstrated the rug-pull variant: a server that behaves, earns trust, then silently changes its tool definitions — exfiltrating SSH keys through Cursor while the confirmation dialog hid the malicious payload entirely. Users are never re-prompted. The menu you approved at install time is not the menu you're eating from.
The open registry: malicious servers one install away. The poisoned-menu attacks need distribution, and open registries provide it. A survey of 8,060 servers across six MCP registries found fewer than half of listed projects valid or non-trivial, with 21.9% untouched for over a year — a long tail of unmaintained install candidates one typo or careless recommendation away from your agent's tool list. The postmark-mcp backdoor showed the shape of the worst case: registry presence laundering a malicious server into trusted tooling. Any platform that bundles, recommends, or one-click-installs third-party MCP servers is operating a software supply chain whether it admits it or not.
Unpacking the checklist: each default, justified
Now the seven items from the top, with implementation teeth.
1. OAuth 2.1 + PKCE on every remote endpoint. Follow the authorization spec as written: authorization-code flow with PKCE on every client, no static-token fallback for remote access, no "internal tool, auth later" carve-outs that survive to production. The Fudan numbers say the ecosystem's failure mode is the missing handshake, not the exotic bypass — so the highest-value line item is the boring one. Note the loopback trap from the 2026 deployment reports: desktop clients registering http://localhost:port/callback but authorizing against http://127.0.0.1:port/callback fail strict string matching, so normalize loopback handling deliberately instead of discovering it from support tickets.
2. No unauthenticated side paths. MountDev's lesson is that attackers don't knock on the front door when the DCR endpoint, the .well-known metadata, and the consent-denial handler are standing open. Inventory every route your server exposes — /register, /authorize, metadata documents, health checks that leak version or config — and default each to authenticated unless you can write down why it must be public. The denial path deserves the same review as the grant path; n8n's bug lived in the handler for "user said no."
3. DCR locked to a redirect allowlist. If you offer Dynamic Client Registration on a remote server, treat it as the privileged operation it is: redirect_uris restricted to an allowlist (https-only, plus strict loopback rules), scheme validation that rejects javascript: and friends, ownership checks on the redirect target, and state/PKCE binding so codes can't be replayed across clients. The Fudan finding that 96.6% of testable OAuth deployments had DCR flaws means "we support standard DCR" is a claim that needs a test suite behind it, not a checkbox.
4. Resource-bound tokens. Implement RFC 8707 resource indicators and RFC 9728 protected-resource metadata so access tokens are audience-bound to your server. A token your server mints should be useless anywhere else — this is what stops one compromised integration from becoming every integration. Clients following the current spec already send the resource parameter; servers that ignore it are accepting bearer tokens as ambient authority.
5. Per-invocation authorization and logging. The NSA's AI Security Center guidance from May 2026 ("Security Design Considerations for AI-Driven Automation," CSI U/OO/6030316-26) names token-lifecycle handling and weak approval workflows as core failure modes and calls for logging parameters and identities on every invocation. Take that literally: authorize each tools/call, not just the session handshake, and log who called what with which parameters. When — not if — a tool gets abused, that log is the difference between a contained incident and a forensics project.
6. Tool-definition pinning with re-consent. Hash the tool schemas your client approved at install or connect time; if a server's definitions change, treat it as a new trust decision and re-prompt with a diff the user can actually read. This directly kills the Invariant Labs rug-pull: the attack depends on definitions changing silently after consent. Pinning turns "silently" into "loudly or not at all."
7. Vet registry servers like dependencies. The NSA guidance says it plainly: pre-deployment server vetting with scanner tooling, component zoning, and filtering egress proxies. Before your platform bundles or recommends a third-party MCP server, scan it, pin it, zone its network reach, and proxy its egress. The registry survey's long tail of stale, half-valid listings means "it's in the registry" carries no more assurance than "it's on the internet" — which, per Censys, is exactly where the 12,520 unauthenticated servers are too.
The OWASP MCP Top 10 gives this checklist a second spine: tool poisoning and rug-pull dynamics sit at the top of the risk taxonomy, so items 5–7 aren't hardening extras — they're the ranked threats, addressed in ranked order.
What this means for a PaaS that ships agent tooling
Step back and the 2026 story is simple. MCP grew from "handy IDE plugin protocol" to "how agents touch production systems" in about eighteen months, and the auth posture didn't make the trip: 40% no authentication, a third on static tokens, and an OAuth minority where independent testers found flaws in all 119 deployments they could probe. The protocol authors did their part — OAuth 2.1, PKCE, resource binding, metadata discovery, three rounds of hardening. The deployments didn't follow. Adoption outpaced safeguards, exactly as the NSA's guidance warns, and the result is twenty thousand open doors that answer in JSON.
For a self-hosted PaaS, that's both a warning and a wedge. The warning: the moment your platform offers agents a deploy tool, a rollback tool, or a logs tool over MCP, you own every item on the attack catalog above — your server is the high-value target the unauthenticated 40% trained attackers to look for. The wedge: almost nobody in the current fleet did the boring work, so doing it is differentiating. OAuth 2.1 required, no silent side paths, pinned tool definitions, per-call audit logs — none of this is novel, and that's the point. In a fleet where the median server authenticates nobody, spec-compliant auth is a competitive feature.
Ship the checklist. Stay out of the next scan.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with agent-operable deploys over an API your tooling can drive. Star the repo on GitHub or deploy your first app today.
