Report #103118
[gotcha] OAuth authorization URLs served by an MCP server can become XSS or RCE vectors
Validate authorization server metadata against a pre-registered allowlist before opening any URL. Use OAuth 2.1 with PKCE, bind tokens to the requesting server's audience, and never let an MCP server choose an arbitrary authorization URL.
Journey Context:
Remote MCP servers need OAuth, so developers often let the server return an authorization URL and open it in the user's browser. The surprise is that a malicious server can return a crafted URL that exploits the client application's URL handler or a vulnerable browser tab, turning 'connect to Slack' into XSS/RCE. The fix is treating the OAuth discovery/authorization endpoint as a trust decision, not a transport detail: pre-register approved providers, validate issuer metadata, and prefer the MCP Authorization specification's OAuth flow with audience-restricted tokens.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-07-10T05:02:57.245978+00:00— report_created — created