What happened
The MCP OAuth login flow trusts the server's own advertised protected-resource metadata as the RFC 8707 resource indicator and mints/receives a token scoped to a resource the client did not intend. Because the indicator is not validated against the configured server URL, a malicious MCP server can obtain a bearer token for a different resource on the same authorization server and replay it there.
Why it matters
MCP servers are routinely added by AI agents and coding tools, which obtain long-lived OAuth tokens on the user's behalf. A token-confusion flaw lets a malicious MCP server exfiltrate creds intended for a different resource, enabling unauthorized access to the user's other MCP endpoints / AI services.
Attack vector
Both implementations use server-supplied Protected Resource Metadata / well-known metadata as the RFC 8707 resource indicator without checking it matches the configured server URL. A malicious MCP server declares a different resource (or another MCP server) as the resource indicator, causing the authorization server to mint a bearer token for that target resource; the attacker then replays the stolen token against the other resource.
Affected systems
ChatCLI < v1.215.2 (CVE-2026-123271); Mark3labs mcp-go < v1.2.1 (CVE-2026-123272)
Mitigation
Upgrade ChatCLI to >=v1.215.2 (GHSA-95vg-3r9c-2v5q) and Mark3labs mcp-go to >=v1.2.1 (GHSA-xf6j-693p-wqxx). Verify that client OAuth flows pin the expected resource indicator to the configured server URL.