mcp-go: a hostile MCP server can claim another server's token

01What happened

VulnCheck published CVE-2026-123272 for mcp-go on November 5, 2026, with official severity scores for a flaw the project had already fixed on October 9. Theodoros Lampropoulos reported the OAuth issue privately, and maintainer Ed Zynda shipped the fix in v1.2.1. The release notes describe it only as an OAuth fix and do not mark it as security, so anyone reading the changelog alone could have missed it.

02How it works

The OAuth client fetches Protected Resource Metadata from an MCP server's well-known path, as RFC 9728 describes. mcp-go checked that the declared resource matched the server actually addressed only when the metadata arrived through the WWW-Authenticate header, not when it came from the well-known path. The unvalidated resource then flowed into dynamic client registration, the authorization request, the token exchange and token refresh, so the authorization server minted a token scoped to whatever server the attacker named.

03Who is affected

Go programs that act as MCP clients and use mcp-go's OAuth handler are exposed. Exposure needs the client to connect to an MCP server the attacker runs or has compromised, and the affected version range is listed below. Servers built with mcp-go are not the target of this flaw.

04What to do

Upgrade to mcp-go v1.2.1, which rejects metadata whose declared resource does not bind to the server being addressed. Review which MCP servers your Go clients connect to, and rotate any OAuth token issued while a client was talking to a server you do not control.

Sources 4 links, all fetched

1. 1github.commcp-go Advisory
2. 2cve.orgCVE Record
3. 3github.comv1.2.1 Release
4. 4github.comFix Pull Request