MCP Server Authentication and Authorization Failures

MCP server authentication and authorization failures grew out of a basic mismatch. A protocol built for trusted local tools was put to work on the internet before its security rules caught up. SaaS teams now have to test and enforce trust at every step, from incoming requests to downstream credentials and agent instructions. Adding OAuth alone does not close the gap.

Why MCP was designed without authentication — and why that decision is still causing damage in 2026

Anthropic introduced it as a standard interface for LLMs to invoke external tools in local, developer-controlled environments. The initial specification, released on 2024-11-25, contained no mandatory authentication requirements for remote servers. OAuth support arrived in March 2025, after deployments had already spread under the weaker defaults.

Moving a locally trusted tool onto the internet changes who can reach it without necessarily changing what it can do. The CSA Agentic MCP Security Best Practices Guide describes adoption outpacing security governance and creating attack surfaces that traditional application security controls cannot fully address. Downstream developers inherited the work of enforcing boundaries that the original environment had supplied.

What the deployment landscape actually looks like today, and why the exposure is structural

Fudan University's measurement study of live remote MCP servers found that more than two-fifths exposed tools without authentication. Among the 119 OAuth-enabled servers it tested, every server had at least one authentication flaw. These findings describe different failures with the same consequence. Some deployments never established an identity check, while others installed one that did not work correctly. Neither group supports the assumption that a reachable MCP endpoint has a dependable access boundary.

The architecture adds another source of exposure. MCP merges reasoning and control flows within a shared semantic context, where retrieved content, metadata, and executable instructions coexist without strong isolation. That makes it different from a standard REST API, whose access checks do not have to decide whether fetched prose should become an instruction. In MCP, trusted execution can depend on how an agent interprets untrusted text.

This distinction connects the failures that follow. An attacker may reach a tool through an unprotected endpoint, exploit the OAuth flow, misuse delegated authority, or persuade an authenticated agent to act. Those routes cross different boundaries, so testing only the network entrance leaves much of the privileged surface untouched.

Missing authentication as a default: how unprotected MCP endpoints become privileged access paths

An MCP endpoint without authentication exposes more than its own process. A database tool uses database credentials, a file-system tool has host file-read access, and a third-party API tool has API keys. Without another access check, an incoming request can reach those integrations using the permissions the server already has. The attacker does not need to persuade the agent. Direct access to the tool can bypass the reasoning layer entirely.

The nginx-ui MCP endpoint demonstrated that path in March 2026. CVE-2026-33032, rated CVSS 9.8, allowed unauthenticated command execution, with more than 2,600 instances exposed before the fix. The Azure DevOps MCP authentication bypass followed in April 2026. CVE-2026-32211, rated CVSS 9.1, made API keys and tokens accessible without credentials. An official server was not immune to the missing boundary.

An unprotected server already possesses access that an attacker would otherwise have to obtain separately. The LiteLLM authentication bypass's KEV listing on September 2, 2026 moved that concern beyond potential exposure into known exploitation. Servers that authenticate callers must also enforce that protection correctly.

How OAuth misimplementation turns the authentication layer itself into an attack surface

A client has to validate the server's claims about where authorization happens and who issues credentials. Fudan's study identifies open client environments, dynamic client registration, and delegated authorization as characteristics that distinguish MCP deployments from conventional web OAuth flows. These are not harmless setup details. When discovery trusts hostile metadata, an attacker can use authentication itself as a way in.

In the Python MCP SDK, a malicious server returns a 404 to the client's discovery request, triggering a legacy fallback that skips issuer validation and sends credentials to the endpoint the server named. The September 28, 2026 advisory rated the flaw CVSS 7.5. It affected mcp versions 1.9.1 to 1.29.1 and 2.0.0 to 2.1.1, with fixes in 1.30.0 and 2.2.0.

The Rust SDK had a related validation failure. CVE-2026-63127 affected rmcp before version 2.0.0 because it did not verify that the resource in server metadata matched the connected server. The fix arrived in 2.0.0, and the flaw was rated CVSS 8.2.

OAuth flow handling could also lead to execution. CVE-2025-6514, rated CVSS 9.6, affected mcp-remote versions 0.0.5 to 0.1.15 and was fixed in 0.1.16. The vulnerable code passed an unsanitized authorization_endpoint URL to the OS open() function, allowing a malicious server to supply a crafted value and execute commands on the victim's machine. The package had more than 437,000 downloads before disclosure.

Token passthrough and confused deputy: how broken scope enforcement lets one user's credentials serve another's requests

Successful authentication does not settle whose authority a request uses. Token passthrough occurs when an MCP server forwards a client's OAuth token to a downstream API instead of obtaining a separate, appropriately scoped token. The June 2025 specification explicitly prohibits this behavior. The server must act as an OAuth client to the downstream service, rather than treating the incoming credential as permission to act everywhere.

A server that holds tokens for multiple users fails to keep each request tied to the right user's credentials. An attacker who manipulates a proxied request can then make the server invoke another user's authority. No credential theft is required for that escalation. Token passthrough concerns how authority is delegated, while confused deputy concerns whose authority the server invokes.

The CSA guide describes cross-tenant data exposure at Asana in 2025 as a case where scope isolation failed in production. Grafana's MCP session-spoofing case illustrates another weak identity boundary, where session IDs were validated only by format. Both show why accepting a credential or session value is not enough to bind a request to the right principal. Overbroad permissions multiply the damage because the wrongly invoked authority may reach far beyond the resource a single tool needs.

Prompt injection as an authentication bypass: how attacker-controlled content reaches privileged execution

In mid-2025, Supabase's Cursor agent read support ticket content that users supplied while it had privileged service-role access. Researchers demonstrated that natural-language instructions embedded in a ticket caused the agent to generate and execute SQL that exposed sensitive integration tokens in a public support thread. The ticket supplied data. Yet its text reached execution through an agent that already had permission to act.

Authentication can correctly identify the agent while failing to stop an attacker from directing its actions and bypassing user intent. Because retrieved content enters the same context as instructions, a support ticket, email, or web page can influence privileged work the user never authorized. The access check succeeds, but the wrong party shapes the request.

Tool poisoning crosses the same boundary from the supply side. A malicious tool definition embeds instructions that the agent follows under its granted privileges. SSRF can extend that confusion into infrastructure access. CVE-2026-26118, rated CVSS 8.8, affected Microsoft's Azure MCP Server when agent-processed content directed HTTP requests at cloud metadata services. Fixes were released in versions 1.0.2 and 2.0.0-beta.17.

The shared failure is the promotion of attacker-controlled content into authority over a privileged tool. That is why a conventional API assessment cannot fully cover this surface by checking credentials and request parameters alone.

Hardcoded secrets and supply chain compromise: the credential risks that live outside the OAuth flow entirely

Some MCP credentials never enter an OAuth flow. Public coding-agent configuration files have hardcoded secrets that were committed to source control, and more than half of those secrets have no recognizable token shape. That lets them evade gitleaks and GitHub secret scanning. Correct runtime authentication cannot protect a credential already exposed in configuration.

Installing a third-party server gives attackers another way around those controls. Community registries indexed more than 18,000 MCP servers by late 2025, and loading one imports its vulnerabilities and access permissions into the operator's trust boundary. The CSA guide records multiple compromises through malicious npm packages in 2025. A server's distribution package can bring in hostile code before OAuth plays any part.

The Deadbugz campaign showed why initial vetting is insufficient. In September 2026, a malicious MCP server withheld its payload until the third tool call and passed five scanners before activating. Rug pull attacks change tool definitions after they have been approved. For teams vetting MCP servers, the practical consequence is that pre-deployment scanning needs behavioral runtime monitoring and tool-definition integrity verification.

What a real MCP security assessment covers — and where checkbox testing falls short

A real assessment follows the path from tool discovery to demonstrated impact. It begins with tool-surface enumeration, then covers transport testing, per-tool fuzzing and injection, credential and authorization flows, chain exploitation, and reporting. The order serves a purpose beyond organization. Enumeration reveals privileged paths that become visible only after authentication, so an unauthenticated blackbox scan cannot substitute for examining the tool surface.

Greybox access is the appropriate starting point for that work. Tool definitions, scope assignments, and integration credentials require partial access to server internals, while whitebox access to source code and cloud configuration exposes the artifacts that define those permissions. The Vulnerable MCP Project tracker listed 50 MCP-related vulnerabilities, including 13 rated critical, as of August 2026. Assessment scope has to reflect that breadth.

Testing only the agent leaves the privileged MCP server unexamined, while excluding third-party servers ignores components operating inside the same trust boundary. A credible finding also needs a working exploit. An unverified possible injection point does not establish that attacker-controlled content can reach a consequential action.

Retesting must examine configuration as well as package versions. The TypeScript SDK reproduction showed that credentials could still leak after an upgrade unless expectedIssuer was explicitly passed. Continuous pull-request scanning extends this work between assessments because tool definitions, scopes, and integration credentials change with deployments.

How MCP pen testing fits into SOC 2, HIPAA, and ISO 27001 compliance programs

For SaaS teams, these tests also produce evidence about access controls. The LiteLLM KEV listing gives monitoring and response programs a known-exploited MCP authentication failure to account for. Under SOC 2, that connects the technical assessment to whether controls operate in practice. A report about an untested agent integration cannot establish protection for the server's downstream access.

HIPAA makes the access boundary especially concrete. When covered entities and business associates connect MCP servers to systems that handle protected health information, they run an access control surface under 45 CFR § 164.312(a). Under ISO 27001 Annex A.9 and A.14, tool permissions, scope enforcement, and token handling are also part of access control and system development.

An assessment that proves exploit paths, checks tool definitions, and includes third-party servers gives auditors evidence of what is in the deployment. Between annual assessments, continuous pull-request scanning and on-demand retesting of specific changes provide a practical way to follow changing tools, credentials, and scopes. A letter of attestation describes a point in time, while the access decisions continue changing with the software.