# FastMCP: an MCP server could redirect a client's OAuth secret

> FastMCP's machine-to-machine OAuth providers never pinned the issuer, so a hostile MCP server could choose who receives the client secret.

- **Severity:** Medium: Real and reproducible, but needs unusual setup, user help or a narrow audience. Plan a fix.
- **Category:** Vulnerability
- **Published by:** FastMCP
- **Disclosed:** 2026-10-20
- **CVSS:** 5.9
- **Affects:** FastMCP, fastmcp (PyPI), fastmcp-slim (PyPI)
- **Research by:** [Leroy H. Mason](https://github.com/LHMisme420)
- **Primary source:** https://github.com/PrefectHQ/fastmcp/security/advisories/GHSA-vqqp-x5qm-5qp4
- **Page:** https://theinjection.dev/items/fastmcp-m2m-oauth-issuer-binding/

FastMCP's machine-to-machine OAuth providers did not pin the issuer that owns their credentials, so an untrusted MCP server could advertise its own authorization server and receive the client secret. Fixed in 4.1.2.

## What happened

FastMCP maintainers published advisory GHSA-vqqp-x5qm-5qp4 on 20 October 2026, reporting that two client-side OAuth providers would send pre-registered credentials to whichever authorization server an MCP server advertised. The reporter, credited on the advisory as LHMisme420, built a proof of concept using an attacker MCP server whose RFC 9728 metadata pointed at an attacker-controlled token endpoint. GitHub added the advisory to its database on 23 October, and no CVE is assigned.

## How it works

ClientCredentialsOAuthProvider and PrivateKeyJWTOAuthProvider accepted a client id and secret but exposed no issuer, so a provider bound only to the MCP server URL and then trusted that server's OAuth metadata discovery. A malicious or compromised MCP server could advertise its own authorization server, and the client would post the secret there in a Basic auth header. The reporter notes the underlying MCP SDK extension already supported an issuer parameter that FastMCP's wrappers neither accepted nor forwarded. Signing keys stay local, so for the private-key provider the exposure is a signed assertion rather than the key itself.

## Who is affected

Applications on fastmcp or fastmcp-slim 4.0.0a1 through 4.1.1 that use the two machine-to-machine OAuth providers to reach MCP server URLs they do not fully control. FastMCP 3.x never shipped these wrappers and is not affected. The advisory lists misconfigured MCP URLs in Prefect agent configuration, unvalidated user-supplied URLs, and a compromised legitimate or SaaS MCP provider as the exposed cases.

## What to do

Upgrade to FastMCP 4.1.2, then set the new issuer parameter to the authorization server that issued the credentials: the advisory and the release notes both state that upgrading alone is insufficient. Rotate any client secret or reusable credential that may have reached an untrusted endpoint. Omitting issuer still works but now emits MCPDeprecationWarning.

## Quick facts

- **Affected:** fastmcp and fastmcp-slim 4.0.0a1 up to 4.1.2, covering stable 4.0.0 to 4.1.1
- **Fixed in:** FastMCP 4.1.2, released 20 October 2026, which also requires MCP SDK 2.2.0
- **CVE:** None assigned
- **CVSS:** 5.9 (v3.1), Moderate
- **Attack type:** Improper authentication, CWE-287 and CWE-522
- **Extra step:** Upgrading alone is not enough: set the issuer parameter
- **Found by:** Reported to the maintainers, credited as LHMisme420

## Questions

### Which FastMCP versions are affected by the OAuth issuer flaw?

FastMCP and fastmcp-slim from 4.0.0a1 up to 4.1.2 are affected, which covers stable releases 4.0.0 through 4.1.1. The wrappers were introduced in 4.0.0a1, so FastMCP 3.x does not include them and is not affected. Only the ClientCredentialsOAuthProvider and PrivateKeyJWTOAuthProvider machine-to-machine providers are in scope, not FastMCP servers.

### Is upgrading FastMCP to 4.1.2 enough to fix the OAuth flaw?

Upgrading to FastMCP 4.1.2 is not sufficient on its own. The advisory and the 4.1.2 release notes both say users of the two machine-to-machine providers must set the new issuer parameter to the identifier of the authorization server that issued their credentials. Omitting issuer remains supported for compatibility but emits an MCPDeprecationWarning instead of enforcing the binding.

### Should I rotate credentials after the FastMCP OAuth advisory?

Rotate any client secret or reusable credential that may have reached an untrusted endpoint, as the FastMCP advisory advises. Release 4.1.2 also discards refresh credentials from reloaded tokens, which could otherwise be sent before issuer discovery, and isolates cached tokens by configured issuer. Valid cached access tokens for the same issuer stay usable until they expire.

## Sources

1. [FastMCP Advisory](https://github.com/PrefectHQ/fastmcp/security/advisories/GHSA-vqqp-x5qm-5qp4)
2. [GitHub Advisory DB](https://github.com/advisories/GHSA-vqqp-x5qm-5qp4)
3. [FastMCP 4.1.2 Release](https://github.com/PrefectHQ/fastmcp/releases/tag/v4.1.2)