FastMCP flaw could leak OAuth secrets to rogue MCP servers

A security advisory published on 23 October 2026 confirms that FastMCP's OAuth client credential providers can send a client secret to an attacker-controlled authorisation server. The flaw affects stable versions 4.0.0 to 4.1.1 of the fastmcp and fastmcp-slim Python packages, and is fixed in version 4.1.2, according to the advisory GHSA-vqqp-x5qm-5qp4.

The problem is one of missing issuer binding. In OAuth, the issuer identifies the authorisation server that owns a set of credentials. The advisory states that the affected versions of ClientCredentialsOAuthProvider and PrivateKeyJWTOAuthProvider do not expose the issuer that owns pre-registered credentials. As a result, a client connecting to an untrusted or compromised Model Context Protocol server will accept whichever authorisation server that server advertises in its metadata, and will exchange its credentials there.

The original report describes the sequence plainly. The client builds a provider with a client ID and secret, the provider binds to the server URL and discovers OAuth metadata, and the client then exchanges credentials at the advertised token endpoint. If the server URL is attacker-supplied or the server has been compromised, the attacker receives the client ID and secret in the Basic authentication header and can impersonate the client against the legitimate authorisation server. The report includes a proof of concept using an attacker-run server that advertises its own token endpoint.

According to the report, the underlying MCP SDK already supported an issuer parameter in its client credentials extension, but FastMCP's wrapper layer neither accepted nor forwarded it. The report names the affected code as fastmcp/client/auth/client_credentials.py, where the constructors lack an issuer argument and the internal _bind() call passes only the server URL to the parent class. The wrappers were introduced in 4.0.0a1, so the 3.x line does not include them.

The maintainers accepted the report as a credential-binding vulnerability. Their assessment notes that signing keys themselves remain local, and that whether a signed assertion can be replayed depends on the assertion source and the audience policy. The reporter rated the impact medium to high.

The 4.1.2 fix adds an issuer argument to both providers and requires MCP SDK 2.2.0. It also discards refresh credentials from reloaded tokens, because without persisted authorisation-server metadata an inherited refresh could transmit credentials before issuer discovery — including the case where a cached token was valid at startup but expired later. Cached tokens are isolated by configured issuer, so setting or changing the issuer forces a new token, while valid cached access tokens for the same issuer keep their expiry.

The advisory is explicit that upgrading alone is not enough. Omitting the issuer remains supported for compatibility and only emits an MCPDeprecationWarning, so operators must configure issuer with the identifier of the authorisation server that issued their credentials. The maintainers also advise rotating client secrets or other reusable credentials that may already have been sent to an untrusted endpoint.

The report describes this as the same vulnerability class as earlier advisories against the Python and TypeScript MCP SDKs, GHSA-qx49-fqc8-xw99 and GHSA-6qxp-vccf-f47h, applied to FastMCP's wrapper layer. It lists affected parties as Prefect Cloud users running agents with FastMCP that connect to user-provided MCP servers, and any deployment using FastMCP's machine-to-machine authentication where the server URL is attacker-controllable or the server is compromised.