Episode 198: Mix-Up Attacks in MCP: Multi-Issuer Confusion and Mitigations

MCP deployments increasingly involve multiple authorization servers / identity providers across tools, registries, gateways, and enterprise environments. That flexibility introduces a classic but under-discussed class of failures: mix up attacks. A mix-up attack is where a client or intermediary confuses which issuer/authorization server it’s interacting with and misroutes sign-in artifacts, such as tokens, to the wrong party, potentially a malicious one. Emily uses her pets to build a threat model for mix-up in MCP-style topologies (client↔server↔auth server). No animals were harmed in the creation of this model!

#Speakers

• Host: Mike Schwartz, Founder/CEO Gluu
• Guest: Emily Lauber,

#Homework

• MCP Dev Summit Slides
• RFC 9207: OAuth 2.0 Authorization Server Issuer Identification
• RFC 9068: JWT Access Tokens
• RFC 8414: OAuth 2.0 Authorization Server Metadata

#Takeaways

• MCP attacks are possible when one trusted OAuth Authorization Server (Cat) manipulates an OAuth client to return a code for a different Authorization Server (Guinea Pigs). With MCP servers interacting with multiple Authorization Servers, this hard to detect attack will become more common.
• PKCE doesn't stop mix-up attacks. PKCE proves the client relationship, but it doesn't verify that the response came from the authorization server the client intended to use.
• Issuer validation is the critical mitigation. Clients must remember which authorization server they started with and verify that the same issuer completes the flow.
• Not all OAuth Authorization Server JWTs contain an iss claim--right Auth0? But RFC 9068 "JWT Access Tokens" defines iss as REQUIRED, and RFC 9207 "OAuth 2.0 Authorization Server Issuer Identification", adds the issuer as a "response parameter", similar to the state param.
• Vibe coding probably won't help, unless the developer specifies the exact OAuth RFCs and profiles to use.