FastMCP OAuth client credentials could follow attacker-advertised issuers

A client that trusts a server’s OAuth discovery metadata to choose its token endpoint is letting the counterparty select the destination of its own credentials. In the documented FastMCP path, the machine-to-machine provider did not pin the issuer, so a hostile MCP endpoint could redirect the OAuth exchange. primary evidence distinguishes the SDK repair from the missing-issuer configuration that can preserve exposure.

The advisory demonstrates a credential-routing flaw; it does not establish that leaked JWT assertions were successfully reused in a production identity provider. Effective exploitability depends on provider configuration.

Configure a trusted issuer and token endpoint independent of untrusted discovery; verify audience and issuer through the entire OAuth exchange, and apply the patched FastMCP release.

This is a configuration-sensitive patch. Versions 4.0.0a1 through 4.1.1 of the FastMCP client wrappers could inherit an authorization server advertised by the remote MCP endpoint. Release 4.1.2 adds explicit issuer binding and corrects reuse of stored refresh credentials, but the maintainer warns that the new issuer argument remains optional for compatibility. Therefore merely upgrading does not protect a provider instantiated without the trusted issuer. A signing key remains locally held in the private-key-JWT flow; the attacker could receive a signed assertion, whose replay depends on its audience and token policy. Rotate reusable credentials if an untrusted endpoint was contacted.