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

> mcp-go's OAuth client trusted the resource an MCP server declared at its well-known path, letting a hostile server claim another's token.

- **Severity:** Medium: Real and reproducible, but needs unusual setup, user help or a narrow audience. Plan a fix.
- **Category:** Vulnerability
- **Published by:** mark3labs
- **Disclosed:** 2026-11-05
- **CVE:** CVE-2026-123272
- **CVSS:** 5.1
- **Affects:** mcp-go, github.com/mark3labs/mcp-go
- **Research by:** [Theodoros Lampropoulos](https://github.com/GimmyDatBeeR)
- **Primary source:** https://github.com/mark3labs/mcp-go/security/advisories/GHSA-xf6j-693p-wqxx
- **Page:** https://theinjection.dev/items/mcp-go-oauth-resource-validation/

mcp-go before v1.2.1 let a malicious MCP server declare another server as the OAuth resource, so the client asked for a token scoped to that server and handed it over. VulnCheck published CVE-2026-123272 on November 5.

## What 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.

## How 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.

## Who 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.

## What 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.

## Quick facts

- **Affected:** mcp-go v0.48.0 through v1.2.0
- **Fixed in:** v1.2.1, released October 9, 2026
- **CVE:** CVE-2026-123272, assigned by VulnCheck and published November 5, 2026
- **CVSS:** 5.1 CVSS v4.0 and 8.0 CVSS v3.1, both published by VulnCheck
- **Attack type:** CWE-346, origin validation error
- **Found by:** Theodoros Lampropoulos
- **Status:** Fixed; CISA's Vulnrichment entry records no known exploitation

## Sources

1. [mcp-go Advisory](https://github.com/mark3labs/mcp-go/security/advisories/GHSA-xf6j-693p-wqxx)
2. [CVE Record](https://www.cve.org/CVERecord?id=CVE-2026-123272)
3. [v1.2.1 Release](https://github.com/mark3labs/mcp-go/releases/tag/v1.2.1)
4. [Fix Pull Request](https://github.com/mark3labs/mcp-go/pull/1053)