FastMCP's October advisories: which versions to run and what upgrading misses

Between 16 and 20 October 2026 the maintainers of FastMCP, a widely used Python framework for building MCP servers and clients, published 16 security advisories. One is rated critical: a FastMCP client that calls a tool on a malicious MCP server can be made to run the server's code, and the call still looks successful. Others cover authorisation checks that were skipped, credentials that could be sent to the wrong place, and denial of service. If your team builds agents, gateways or internal MCP servers in Python, this article sets out which versions close everything, and the steps that an upgrade alone does not take.

What was disclosed

The advisory list for the repository shows the batch. Most fixes shipped before the advisories went public: 3.4.8 and 4.0.11 were released on 4 October, and the rest followed between 8 and 20 October, with 3.4.9 arriving about three hours after the first advisories on 16 October, according to the PyPI release history. The advisories that matter most fall into four groups.

Code execution in the client. GHSA-gpgx-58w2-xwwf, rated critical and published on 16 October, affects fastmcp from 2.10.0 before 3.4.8, and from 4.0.0a1 before 4.0.11. A server can declare a tool outputSchema containing a self-reference whose title the client evaluates as Python when it parses a structured result or an elicitation form schema; the advisory says that path is covered by the same fix. The advisory notes that an exception handler only logs, so "exploitation leaves the tool call looking successful". It names the high-risk case directly: "Agent hosts and gateways that connect to user-supplied MCP servers". There is no fixed 2.x release; the fix is in 3.4.8 and 4.0.11. At the time of writing, no CVE identifier was listed for it, and none of the three advisories cited here appeared in the GitHub Advisory Database, so dependency scanners that rely on it may not flag them yet.

Authorisation that wasn't applied. GHSA-mhwm-p596-p7q4 (high, CVSS 8.1) shows that tools added through ToolInjectionMiddleware skipped their per-tool scope checks for both listing and calling, so a low-privilege token could run an admin-only tool. Related advisories cover post-transform authorisation skipped on direct calls (medium, 6.8, fixed in 3.4.10 and 4.1.2), component enable and disable routes that skipped the auth provider when no scopes were set (medium, 6.5), hashed app tool calls that bypassed disable and allowlist rules, and confusion between independent providers in MultiAuth.

Credentials sent to the wrong place. GHSA-vqqp-x5qm-5qp4 (medium, 5.9) affects the machine-to-machine OAuth providers from 4.0.0a1 before 4.1.2, pre-releases included. Without issuer binding, a malicious or compromised MCP server could advertise its own authorisation server and receive the client secret. Two OpenAPI-integration advisories are similar in spirit: one forwarded the incoming Cookie header to third-party backends (medium, 6.1), another let clients override configured upstream credentials through undeclared header, cookie and query arguments.

Resource exhaustion and older fixes. High-severity advisories cover an attacker-controlled regular expression that can block a worker (CVSS 7.5), unknown JWT key IDs that each trigger a fetch of the identity provider's key set, and an unbounded cache in OAuthProxy. Two are incomplete fixes for earlier issues: a Windows command injection in the installers that write Claude Code and Gemini CLI configuration (high), and OpenAPI path parameters set to .. reaching other backend routes (medium). A low-severity one lets a skill provider follow a symlinked SKILL.md outside its folder.

Some advisories also list the fastmcp-slim package; check both names in your dependency tree.

Which versions close everything

Taking the highest fixed version per line across the batch:

• 4.x: 4.1.2 or later. The newest release at the time of writing is 4.1.3, from 20 October.
• 3.x: 3.4.10 or later; the newest is 3.4.11, also from 20 October.
• 2.x: no fix. Anything from 2.10.0 is exposed to the client-side code execution issue, so the patched routes are 3.4.10 or later, or 4.1.2 or later.

Note that 4.1.2 requires MCP SDK 2.2.0, so the upgrade may pull a protocol SDK update with it.

What upgrading does not do

The issuer-binding advisory is explicit that "Upgrading alone is insufficient". Version 4.1.2 adds an issuer setting to ClientCredentialsOAuthProvider and PrivateKeyJWTOAuthProvider, but leaving it out is still allowed for compatibility and only produces a deprecation warning. Protection depends on setting issuer to the authorisation server that issued your credentials. The maintainers also advise rotating client secrets or other reusable credentials that may already have gone to an untrusted endpoint.

For the critical client issue, the advisory's workaround before upgrading is to connect only to trusted servers. Because the exploit leaves no error, you can't rely on failed calls in logs to tell you whether it happened. If a client process connected to servers you don't control, treat the secrets that process could reach as possibly exposed.

What it means for engineering and security leaders

The pattern is familiar from earlier MCP advisories, such as the token audience checks in the MCP SDKs: the client side of MCP is attack surface too. Tool descriptions, schemas and metadata arrive from the server and are processed by code with the client's privileges and credentials. A gateway or agent host that lets users add arbitrary MCP servers is, in effect, running code paths chosen by whoever operates those servers.

Two governance points follow. First, keep an inventory of which internal services embed FastMCP and on which release line, because the fixes are spread across several releases and the 2.x line has none. Second, treat the list of MCP servers a client may reach as configuration that needs approval, as we argued in MCP server entries are commands.

Practical takeaways

1. Search your dependency manifests and lock files for fastmcp and fastmcp-slim, including transitive dependencies of agent frameworks. Do it by hand for now, since automated scanners may not list these advisories yet.
2. Move 4.x to 4.1.2 or later and 3.x to 3.4.10 or later. Plan a migration for anything still on 2.x.
3. Where you use the client credentials or private key JWT providers, set issuer explicitly and rotate secrets that may have reached an unknown authorisation server.
4. Restrict agent hosts and gateways to MCP servers you trust until every client is upgraded.
5. Re-test authorisation: list and call each scope-protected tool with a low-privilege token, especially tools added through middleware or transforms.
6. If you generate Claude Code or Gemini CLI configuration with FastMCP's installers on Windows, upgrade before running them again.

For AI coding tools on developers' computers, the same principle of a short list of known servers is what SpanDock's MCP gateway is designed for. Each tool gets SpanDock's MCP server; your server checks permissions and rules before calling a connector; and in the Enforced setting SpanDock also reports, or moves aside, the tools' other MCP servers. The MCP gateway is on the Premium and Enterprise plans.