AI
How Mixup Attacks Exploit MCP’s Authorization Flow
A mixup attack requires two conditions. The client interacts with multiple authorization servers. The client uses a single redirect URI for all of them. Emily Lauber illustrated the attack with a pet analogy. A cat authorization server redirects a request meant for the guinea pig server. The cat intercepts the authorization code and obtains access tokens. Each component completes its task correctly. No one detects the attack. The attack has been known since 2016 but MCP’s architecture makes it more likely.
Why MCP Is Especially Vulnerable
MCP has many more clients and authorization servers than typical OAuth ecosystems. That creates the one-to-many relationship needed for mixup attacks. Vibe coding makes it easy to spin up malicious servers. An open-source PR could approve a bad authorization server without review. MCP is also non-deterministic. Clients and servers do not know ahead of time which authorization server they will use. That prevents pre-registration mitigations. These factors make mixup attacks more prevalent in MCP.
Mitigation: Validating the Issuer Parameter
The second mitigation validates the issuer parameter in authorization responses. The issuer is a URL defined in the authorization server’s metadata. RFC 8414 requires the issuer in metadata but not in responses. RFCs 9207 and 9700 recommend sending it only if the client supports multiple authorization servers. The MCP draft SEP 2468 changes that. MCP clients must check if the authorization server supports sending the issuer. If so, they store the issuer when sending the request and validate it in the response. Authorization servers should set the metadata flag and send the issuer.
Call to Action for the MCP Ecosystem
Lauber issued a call to action for three groups. MCP resource builders must think carefully about which authorization servers they trust. MCP clients must validate the issuer parameter when received. MCP SDKs should add support to make adoption easier. Authorization servers should send the issuer parameter in OAuth responses. The goal is to protect the ecosystem from mixup attacks. “Protect the guinea pigs. Use the issuer parameter,” she said.
Q&A
Does resource and audience validation prevent the mixup attack? Lauber explained that it does not stop the 302 redirect because the malicious authorization server can impersonate the client and send the same resource parameter. ▶ Watch (19:59)
Who should check the audience? The MCP server should check the audience to ensure the authorization server is on the same page, but Lauber noted she is less familiar with that validation logic. ▶ Watch (21:41)
Notable Quotes
This attack is not new. It has been known since 2016, probably earlier, but at least published in papers since 2016 with the OOTH 2.1. Emily Lauber · ▶ Watch (9:25)
No one is none the wiser that the cat that is pretending to be the smart home agent for the guinea pigs now has the guinea pig off codes and the guinea pig access tokens. Emily Lauber · ▶ Watch (7:28)
Protect the guinea pigs. Use the issuer parameter. Emily Lauber · ▶ Watch (19:33)
Key Takeaways
- Mixup attacks exploit MCP’s multi-authorization-server architecture and single redirect URI.
- Validating the issuer parameter in authorization responses is the primary mitigation.
- MCP clients, servers, and SDKs must adopt issuer validation to prevent token theft.
About the Speaker(s)
Emily Lauber is a Senior Product Manager at Microsoft focused on identity, authentication, and developer platforms. She works at the intersection of cloud security, browser-based auth, and standards, helping shape how modern apps and agents securely authenticate and access resources.