CVE-2026-32871 is a critical server side request forgery in the OpenAPIProvider of FastMCP, scored CVSS 10.0. Path parameters were inserted into URLs without encoding, so a caller could escape the intended API prefix and reach other backend endpoints with the provider's credentials. Upgrade FastMCP to 3.2.0.
What's affected
The GitHub advisory lists the pip package fastmcp, versions before 3.2.0, with 3.2.0 as the patched version. The 3.2.0 release was published on 30 March 2026.
The affected component is the OpenAPIProvider, which turns an OpenAPI specification into MCP tools. The flaw is in the _build_url method of the RequestDirector class. If you do not use the OpenAPI provider, the vulnerable code path is not in play.
How to check if you're exposed
Check the installed version:
pip show fastmcp
Then find out whether you use the OpenAPI provider:
grep -rnE "OpenAPIProvider|from_openapi" .
If you use it, list the backend the provider talks to and the credentials it sends. The advisory says requests go out with the authorization headers configured on the provider, which is what makes the issue an authenticated request forgery.
Also consider who supplies the parameter values. In an MCP server, a language model or a remote client often chooses them, so treat them as untrusted input.
What to do now
- Upgrade FastMCP to 3.2.0 or later, for example by asking pip for a fastmcp version of at least 3.2.0.
- Rebuild images and redeploy every MCP server that uses the OpenAPI provider.
- Give the provider's credentials the narrowest scope the tools really need.
- Keep internal admin endpoints on a separate network or behind their own authentication, so one set of credentials does not unlock them.
- Log backend requests made by MCP tools and watch for paths outside the expected prefix.
- Add FastMCP to your dependency inventory so the next advisory shows up quickly.
Think of the MCP server as an API gateway that a language model drives. The model decides which tool to call and which values to pass, and in the OpenAPI provider those values end up inside a URL. That makes the URL builder a security boundary, much like a database query builder.
Three habits reduce the chance of a repeat. Encode every path parameter before it enters a template. Validate values against the type and pattern the specification gives, for example a numeric ID. And check the final URL still sits under the expected base path before sending it.
On the backend side, assume a request that carries your service credentials can be pointed at another route. Keep administrative routes behind separate credentials, and log which paths MCP tools actually call. A sudden call to a path outside the specification is a strong signal worth alerting on.
This is also a good moment to take stock of every MCP server your teams run and which APIs and credentials each one holds.
Why it matters
The class is CWE-918, server side request forgery. The advisory gives the cause plainly. Parameter values were swapped into the URL template as plain strings. Then a standard library function resolved the final address, and that function treats dot dot segments as directory steps. A value meant to be an ID could therefore change which endpoint the request hit.
The request carries the provider's own authorization, so the backend sees a trusted caller. That is why the score is 10.0 and why the right fix is both patching and limiting what those credentials can do.
This is also a sign of where risk is moving. MCP servers connect language models to real APIs, and the glue code that builds requests from model supplied values becomes a security boundary. The record's KEV flag is false.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does URL encoding of parameters solve this class of bug?
It is the core of the fix here, since encoded values cannot act as path steps. Also validate values, and scope credentials narrowly.
Am I exposed if I only use FastMCP for plain tools?
The advisory ties the flaw to the OpenAPIProvider. Check your code for that provider, and upgrade anyway.
Sources
Last reviewed: 19 October 2026.