Breach anatomy
PKCE verification skipped at the token endpoint
The same library implemented PKCE, which OAuth 2.1 and the MCP specification require, but a token request could be shaped so that the code verifier was never compared with the challenge recorded at authorization. Anyone holding an authorization code could then redeem it without the secret the honest client generated. An authorization server must refuse a token request for a code that was issued with a challenge unless the verifier matches; advertising S256 is not the same as enforcing it.
- Class
- PKCE bypass
- Disclosed
- Fixed
- @cloudflare/workers-oauth-provider 0.0.5
- Affects
- @cloudflare/workers-oauth-provider before 0.0.5
- Remote MCP servers built on it
- Sources
The control that was missing
PKCE with S256 advertisedAuthorization serverMUST
The metadata lists code_challenge_methods_supported including S256, which MCP clients require before they will start an authorization flow.
Security Considerations › Authorization Code ProtectionMCP Authorization 2026-07-28
Listed servers under MCP Authorization 2026-07-28: 34 supported, 0 partial, 0 unsupported, 2 unknown, 3 not applicable.
PKCE on every authorization requestClientMUST
The client generates a PKCE verifier and S256 challenge for every authorization request and refuses to proceed when the server does not advertise S256.
Security Considerations › Authorization Code ProtectionMCP Authorization 2026-07-28
A client requirement; the atlas does not observe clients.
Replay in the explorer
An MCP client obtains a token for an MCP server · PKCE verifier not checkedMisconfiguration
The authorization server advertises S256 and records the code challenge, but a token request can be shaped so the verifier is never compared with it. An authorization code that leaked, through a redirect, a log or a referrer, can then be exchanged by whoever has it, without the secret the honest client holds. The check that PKCE exists for is the one that is skipped. This is the pattern behind CVE-2025-4144.