FastMCP flaw let low-privilege users call protected tools
PrefectHQ has patched an authorisation bypass in its Model Context Protocol server framework that skipped permission checks on direct component calls.
By The Agentic Times ·

PrefectHQ has fixed an authorisation bypass in FastMCP, its Python framework for building Model Context Protocol servers, after a researcher showed that low-privilege callers could execute protected tools that were hidden from them in listings. The advisory, GHSA-7xgj-8392-5q4r, was published on 23 October 2026 and affects the stable release lines 3.0.0 to 3.4.9 and 4.0.0 to 4.1.1. Both the fastmcp and fastmcp-slim packages are affected.
The problem lies in how FastMCP handles transforms, which are server-side rules that change a component's metadata, such as the tags attached to a tool. According to the advisory, listing operations applied the transform first and then checked authorisation against the transformed component. Direct lookups did not. They checked the original component, applied the transform, and then returned the transformed component without rechecking its policy. A client that knew or guessed the final component identifier could therefore invoke a tool, or retrieve a resource or prompt, that the configured policy was meant to deny.
The reporter said they reproduced the issue against FastMCP 4.1.0 using only an in-process FastMCP server, with no server-side access and no control over the server's configuration. The attacker prerequisites described in the report are modest: the server uses a supported provider, server or session transform together with a metadata-aware authorisation check, and the attacker holds a valid low-privilege identity without the required scope.
The published proof of concept registers a tool tagged public but protected by a rule restricting it to callers with the admin scope, then adds a transform that retags the tool as admin. Listing the server's tools returns an empty list for an unprivileged caller, as expected. Calling the tool by name directly returns its contents anyway. In the recorded output, the direct call returned the string PROTECTED SECRET.
In its assessment, the maintainer accepted the report as a FastMCP authorisation vulnerability. The advisory states that the missing final authorisation check is present in the v3.0.0 history and was reproduced on v3.4.9 and v4.1.0. The impact described by the reporter is that a low-privilege caller can directly execute administrative tools hidden from listing, including their side effects and any secrets they return, and that the same ordering flaw can expose protected resources, templates and prompts.
Fixes are available in FastMCP 3.4.10 and 4.1.2. According to the advisory, the patched versions authorise the final transformed tools, resources, templates and prompts. A denied concrete resource now also shadows a matching resource template at the same URI, which prevents a proxy template being used to fetch the same protected resource from upstream. The maintainer said authorised callers, authorised component versions, and templates for genuinely absent concrete resources continue to work.
For operators who cannot upgrade immediately, the advisory recommends avoiding overlapping proxy templates for protected resources, and enforcing the required authorisation at the handler or server boundary rather than relying on a policy whose inputs a transform can change. The reporter's own recommendation goes further, urging FastMCP to reuse a single ordered resolver for both listing and direct operations so that a lookup can never return a transformed component before its applicable authorisation check has run.
The reporter disclosed that OpenAI Codex assisted with the static analysis, proof of concept and write-up, and said the reproduction was validated against the stated version.
Sources
- github.comhttps://github.com/advisories/GHSA-7xgj-8392-5q4r
