When an MCP wrapper learns OAuth server details from a peer, the peer is not permitted to choose where the client secret is sent. The advisory describes an issuer-binding omission that lets an attacker-advertised authorization server receive a machine-to-machine credential. A TLS connection would not fix the logical error if the client had already accepted…
Inspect the ClaimsCase · DiggingBeagle record
FastMCP machine-to-machine OAuth wrappers lacked issuer binding
An MCP peer could advertise an attacker-chosen authorization server and receive client credentials through affected FastMCP M2M OAuth wrapper behavior.
Scope
FastMCP 4.0.0a1 to before 4.1.2 with affected MCP client wrapper configuration.
Assessment profile
Assessment method- Setting
- research demonstration
- Exploitation
- demonstrated
- Evidence
- Grade B
- Remediation
- patch available
- AI role
- AGAINST AI
Basis and provenance
CASE-2026-FASTMCP-ISSUER-SECRET: GHSA-vqqp-x5qm-5qp4 describes issuer-unbound M2M OAuth wrappers and a fix in FastMCP 4.1.2. Evidence comes from SRC-2026-FAST-MCP-ISSUER-GHSA. Published technical statements or controlled results are not verified production-loss counts. No impact band is assigned because the observed outcome and its denominator do not establish a comparable severity measure.
Assessed Oct 24, 2026 using diggingbeagle.assessment/1.
Evidence basis: CLM-FASTMCP-ISSUER-01 · FastMCP GHSA-vqqp-x5qm-5qp4 OAuth issuer mismatch
At a glance
TLS protects the connection to whichever token endpoint the client selected; it does not establish that the endpoint is the one for which the client credential was issued. A stolen client secret and a misdirected private-key JWT assertion have different replay and key-exposure consequences.
Read the implicationsNo verified evidence of production losses or a broader exploitation campaign has been presented in the cited material.
Limits and uncertaintyFull account
When an MCP wrapper learns OAuth server details from a peer, the peer is not permitted to choose where the client secret is sent. The advisory describes an issuer-binding omission that lets an attacker-advertised authorization server receive a machine-to-machine credential. A TLS connection would not fix the logical error if the client had already accepted a fraudulent issuer. FastMCP 4.1.2 patches this v4 issue, while earlier FastMCP 3.x versions are not listed in this particular advisory. The weakness is separate from the post-transform component authorization bug, which can expose tools without stealing an OAuth secret.
Here the server advertised an OAuth authority that the client was meant to evaluate against an already trusted issuer. The vulnerable machine-to-machine wrappers instead accepted metadata without that binding, so a remote MCP peer could redirect sensitive credential material toward a different authorization server. This is not the same as a malicious tool response persuading an LLM to disclose secrets: the software's authentication discovery mechanism made the routing decision before the model needed to reason about it. A patched client must use an explicitly trusted issuer, and a valid token audience is an additional, not interchangeable, check. Maintainer advisory.
Mechanism and trust boundary
- 01
Configure machine-to-machine OAuth credentials
An MCP client wrapper holds a pre-registered secret or signing capability associated with a known authorization-server issuer.
Boundary: Local configuration / M2M secret
- 02
Accept untrusted server-advertised metadata
A malicious or compromised MCP server advertises a different authorization server or token endpoint.
Boundary: Remote discovery metadata / OAuth issuer selection
- 03
Present the credential to the attacker endpoint
An affected wrapper lacks issuer binding, enabling disclosure of a client secret or a signed assertion; the private signing key itself does not have to leave the client.
Boundary: OAuth token endpoint / credential and assertion audience
Timeline
- 2026-10 (month precision)Event type unspecified
FastMCP OAuth issuer flaw disclosed
A machine-to-machine issuer mismatch was disclosed and corrected for the affected 4.x wrappers.
- Oct 20, 2026disclosure
Public disclosure
Claims & evidence
CLM-FASTMCP-ISSUER-01GHSA-vqqp-x5qm-5qp4 describes issuer-unbound M2M OAuth wrappers and a fix in FastMCP 4.1.2.supported
Basis: reported finding
- supportsFastMCP GHSA-vqqp-x5qm-5qp4 OAuth issuer mismatchprimary disclosure
Description; Affected versions; Patched versions
CLM-FASTMCP-ENRICH-KEYThe maintainer says a malicious MCP server can receive the client secret or signed assertion, but not necessarily the signing key; JWT replay depends on audience and source policy.supported
Basis: reported finding
- supportsFastMCP GHSA-vqqp-x5qm-5qp4 OAuth issuer mismatchprimary disclosure
Maintainer assessment: secret redirect, assertions and signing keys
CLM-FASTMCP-ENRICH-VERSIONFastMCP and fastmcp-slim OAuth client-credential wrappers introduced in 4.0.0a1 were affected before 4.1.2; 3.x never included these wrappers.supported
Basis: reported finding
- supportsFastMCP GHSA-vqqp-x5qm-5qp4 OAuth issuer mismatchprimary disclosure
Affected versions; Maintainer assessment and remediation
Implications
TLS protects the connection to whichever token endpoint the client selected; it does not establish that the endpoint is the one for which the client credential was issued. A stolen client secret and a misdirected private-key JWT assertion have different replay and key-exposure consequences.
Controls and mitigations
- Upgrade to FastMCP 4.1.2 or later and explicitly configure or constrain the expected OAuth issuer for every M2M credential. Review token/audience logs rather than assuming a client certificate or HTTPS URL proves correct issuer binding.
Unknowns and contradictions
- No verified evidence of production losses or a broader exploitation campaign has been presented in the cited material.
Sources and citation
Material revision history
- Oct 24, 2026 · Canonical change recorded · new in release · revision 188