Token Passthrough Vulnerability in MCP is the security flaw where an MCP server accepts an access token and then forwards it, unmodified, to downstream APIs without checking whether the token was actually intended for those APIs. It looks convenient. A user’s GitHub token arrives at the MCP server; the server proxies it to GitHub’s API; everything works. The problem is that the same token might also work against other services that share the authorization server, and downstream APIs may assume the MCP server validated the token before forwarding. The MCP specification calls token passthrough out as a critical risk because it turns the MCP server into a perfect confused deputy.
How Token Passthrough Creates Cross-Service Risk
The attacker obtains a legitimate-looking token through the normal OAuth flow, then targets an MCP server known to passthrough tokens. The MCP server accepts the token without validating the audience, then forwards it to a downstream API. The downstream API sees a token with a valid signature and scope, assumes the upstream service validated it, and processes the request. The attacker gains access to any service the token can reach, not just the one originally targeted. If the MCP server happens to hold OAuth tokens for many users, a single bypass can expose data across the entire tenant.
Certified MCP Security Expert
Attack, defend, and pen test MCP servers in 30+ hands-on labs. Get certified.
Why Token Passthrough Is So Common in MCP Deployments
Early MCP server implementations treated authentication as a checkbox: accept a bearer token, forward it downstream, move on. The pattern came from API gateway architectures where audience binding was rarely enforced. Obsidian Security demonstrated in 2025 that most production MCP servers running as OAuth proxies suffered from this exact issue. Servers that act as proxies for GitHub, Slack, Google Workspace, or any cloud SaaS are the highest-risk category, because their forwarded tokens unlock major data sources. Without explicit audience validation and resource indicators, the bypass is essentially the default behavior, not the exception.
How to Eliminate Token Passthrough Vulnerabilities
Never forward a user-supplied token to a downstream API. Instead, exchange the incoming token for a new token specifically scoped for the downstream service using OAuth token exchange (RFC 8693). Validate the AUD claim on every incoming token. Use resource indicators (RFC 8707) so authorization servers issue audience-scoped tokens from the start. Apply the least-privilege principle: the MCP server should hold its own service credentials for downstream APIs, not reuse user tokens.
Summary
Token Passthrough Vulnerability turns an MCP server into a confused deputy by forwarding incoming tokens to downstream APIs without audience validation. The fix is token exchange: never reuse user tokens across services. The Certified MCP Security Expert (CMCPSE) certification trains engineers to implement RFC 8693 token exchange patterns that eliminate passthrough risk from MCP deployments end to end.