CVE-2026-123272

mcp-go accepts a different OAuth resource from well-known metadata

Mark3labs · mcp-go OAuth client transport

First documented disclosure · Review checkpoint

Summary

A malicious MCP endpoint can receive a token intended for another protected resource.

Severity and exploitation evidence

Medium · 5.1/10 · CVSS 4.0. Severity source.

Exploitation not established: The maintainer documents the flaw and tests. No malicious use is established in the reviewed sources.

Exploitation evidence source

Technical severity is not a measure of observed attacks or of risk to your deployment. Attempts, demonstrations, and successful compromise retain the qualifications in the source.

How the weakness works

The well-known discovery path omits the resource-binding validation used for challenged metadata. The supplied resource flows into registration, authorization, exchange and refresh.

Conditions required

A user authorizes a hostile server and the authorization server issues a token for the nominated resource that can be replayed there.

Potential impact

The recipient can exercise the user’s granted access against the wrong resource.

Affected versions and configurations

0.48.0 through 1.2.0.

Fix and mitigation status

1.2.1.

Practical next steps

Upgrade dependent MCP clients to a release using fixed mcp-go; revoke grants issued through untrusted servers.

Operating lesson

Apply the same identity binding to every discovery path.

Evidence and limits

The public fix and advisory date to October 9. November 5 is CVE publication. VulnCheck assigns 5.1 in CVSS 4.0 and 8.0 in CVSS 3.1; these are separate scales.

Sources