TLDR Tech / InfoSec
OAuth mix-up attacks and RFC 9207: The issuer check that never made it to token exchange
WorkOS traces the OAuth mix-up attack (a client talking to multiple authorization servers gets confused about which server sent a response and routes a code or token to the wrong one) and how RFC 9207's 2022 fix, an iss parameter the client must compare against the expected issuer and reject when absent, only covers redirect flows and never extended to back-channel grants. That gap is what CVE-2026-59208 exploited in n8n's token exchange: the endpoint confirmed a subject_token's signature matched a trusted key but never confirmed the key belonged to the issuer named in the token's iss claim, so a token from one tenant resolved to a same-named account in another because signature validation and account-namespace scoping were treated as separate questions. Defenders should enforce RFC 9207 client-side (reject a missing iss when the server supports it), partition trusted signing keys per issuer rather than pooling them flat across RFC 8693/7523/7522 grants, and scope sub account lookups to the confirmed issuer's namespace, the single check that would have stopped the CVE, treating this as first-class in MCP and agent architectures where multi-issuer topologies are becoming default.
Read the full story