The mcp-go disclosure, published October 9, 2026, identifies a resource-binding check missing from a particular MCP OAuth discovery path. Validation already existed for challenged metadata, but the well-known discovery route could accept a resource identity supplied by an attacker-controlled server. That identity could influence client registration,…
Inspect the ClaimsCase · DiggingBeagle record
mcp-go trusted the wrong resource identity on its well-known OAuth path
mcp-go validated resource metadata on one discovery route but not its well-known route. Versions 0.48.0 through 1.2.0 are affected; 1.2.1 adds the missing binding check.
Public disclosure: Oct 9, 2026
Scope
Vulnerability reported in a controlled research or disclosure setting. Exact prerequisites, versions and absence of documented exploitation must be preserved.
Assessment profile
Assessment method- Setting
- research demonstration
- Exploitation
- demonstrated
- Evidence
- Grade B
- Remediation
- patch available
- AI role
- AGAINST AI
Basis and provenance
The cited first-party advisory or research establishes the stated mechanism only within its documented conditions. No unrelated production compromise, extended victim scope, financial harm or universal mitigation is inferred.
Assessed Nov 9, 2026 using diggingbeagle.assessment/1.
Evidence basis: CLM-MCPGO-RESOURCE-METADATA · mcp-go OAuth resource identity mix-up advisory
At a glance
OAuth authorization metadata must not redefine the resource identity or destination without a separately authenticated binding.
Read the implicationsRequires a malicious MCP server and successful token issuance or consent; no proven deployed credential theft.
Limits and uncertaintyFull account
The mcp-go disclosure, published October 9, 2026, identifies a resource-binding check missing from a particular MCP OAuth discovery path. Validation already existed for challenged metadata, but the well-known discovery route could accept a resource identity supplied by an attacker-controlled server.
That identity could influence client registration, authorization, token exchange and refresh. With compatible authorization-server behavior and user authorization, the client could obtain a token for an unintended resource and deliver it to the malicious MCP endpoint. Successful replay additionally depends on another service accepting the credential.
A route-specific repair
Affected versions are 0.48.0 through 1.2.0; 1.2.1 is the documented fix. The defect is not evidence that every OAuth flow ignored resource identity, nor does the advisory establish real-world customer token theft.
The separate ChatCLI case describes the same broad confusion between declared metadata and the intended service, but its versions, code and repair are independent. Identity must be bound consistently across every discovery and refresh path, rather than inferred from one route that already validates correctly.
Mechanism and trust boundary
- 01
A client connects to an untrusted or malicious MCP server and receives OAuth protected-resource metadata.
- 02
The server asserts a resource identifier not bound to its actual origin.
- 03
The client enters an authorization flow for that other resource and may deliver an audience-specific bearer token to the malicious endpoint.
Claims & evidence
CLM-MCPGO-RESOURCE-METADATAmcp-go 0.48.0 through 1.2.0 trusted an attacker-advertised protected-resource identity, potentially obtaining bearer credentials for a different target resource; fixed in 1.2.1.supported
Basis: reported finding
- supportsmcp-go OAuth resource identity mix-up advisoryvendor statement
GHSA-xf6j-693p-wqxx, Description, Affected versions and Patched versions
Implications
OAuth authorization metadata must not redefine the resource identity or destination without a separately authenticated binding.
Controls and mitigations
- Upgrade mcp-go to 1.2.1 and bind OAuth resource identity to the protected MCP origin before requesting or forwarding tokens.
Unknowns and contradictions
- Requires a malicious MCP server and successful token issuance or consent; no proven deployed credential theft.
Sources and citation
Material revision history
- Nov 9, 2026 · Published version · first publication · revision 233