No. The MCP security guidance says PKCE alone does not prevent a mix-up attack, because the client sends its code verifier to the attacker's token endpoint. The defense is to record the expected issuer before redirecting, then compare the iss value in the response before sending the authorization code anywhere.
What a mix-up attack is
An MCP client talks to many authorization servers over its life. If an attacker controls one of them, they may try to make the client send a code or token meant for an honest server to the attacker's server instead. The attack is described in RFC 9207.
PKCE protects against a stolen authorization code being used by someone without the verifier. In a mix-up, the client itself hands over the verifier, so PKCE cannot help. Resource indicators do not help either when the attacker's server intercepts requests before they reach the honest one.
The draft's defense
The authorization section requires clients to record the issuer from the validated metadata of the chosen authorization server before redirecting the user, and store it with the PKCE verifier and state. When the response comes back, they must validate it before transmitting the code to any token endpoint.
| Server advertises iss support | iss in response | Client action |
|---|---|---|
| Yes | Present | Compare with the recorded issuer |
| Yes | Absent | Reject |
| No or unknown | Present | Compare with the recorded issuer |
| No or unknown | Absent | Proceed |
The comparison is a simple string comparison with no case folding, port elision, trailing slash or percent encoding normalization. On a mismatch, the client must not act on or display the error fields either.
Limits to know
The protection depends on the recorded issuer being authentic, so it must come from validated metadata. It also depends on honest servers emitting iss. The guidance states it gives no protection against an honest server that does not. The draft expects a future revision to raise server inclusion of iss from should to must.
What to do
The fix is small for client builders and cheap to test. Keep the checklist short and make it part of release checks.
- If you build a client, implement issuer recording and validation now.
- If you run an authorization server, emit iss and advertise support in your metadata.
- If you buy a client, ask whether it validates iss before sending codes.
- Keep the allowed list of authorization servers short.
- Test with a mismatched issuer and confirm the client refuses.
- Log refusals, since a mismatch is a signal worth looking at.
Safeguard includes agent identity and policies, gates and guardrails, plus a free scan at https://gold.safeguard.sh/scan.
Quick check
Should I drop PKCE then?
No. PKCE still stops a different attack, the use of a stolen code. Keep it and add issuer validation.
Who must implement the check?
The client. The authorization server helps by sending iss and advertising it in its metadata.
Sources
Last reviewed: 19 October 2026.
