Breach anatomy
Authorization codes sent to an unchecked redirect URI
The OAuth provider library behind many remote MCP servers on Cloudflare Workers checked the redirect URI against the client's registered URIs at the token endpoint, but not at the authorization endpoint. An authorization request could therefore name any redirect URI, and a server that re-approves clients it has seen before would send the authorization code there without asking the person again. Checking the redirect URI where the request arrives, before any consent decision, is the control that was missing.
- Class
- Unchecked redirect URI
- Disclosed
- Fixed
- @cloudflare/workers-oauth-provider 0.0.5
- Affects
- @cloudflare/workers-oauth-provider before 0.0.5
- Remote MCP servers built on it whose consent step re-approves known clients
- Sources
The control that was missing
No requirement in the MCP auth atlas stands for this control yet. The summary above says what it is; a requirement is added to the atlas when a specification revision states it, not before.
Replay in the explorer
An MCP client obtains a token for an MCP server · Redirect URI not checked at authorizationMisconfiguration
The authorization server compares the redirect URI with the client's registered URIs only when the code is exchanged, not when the authorization request arrives. A request that names a redirect URI the client never registered is still processed, and a server that re-approves a client Alex has authorized before sends the code to that URI without asking. Whoever controls the URI now holds a code for Alex's grant. This is the pattern behind CVE-2025-4143.