Threats affecting pkg:github/jlowin/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](https://github.com/jlowin/fastmcp/blob/ee5f465a82350e1c5a56c4a2b47cfdc4cd736e76/src/fastmcp/server/auth/oauth_proxy.py#L1762), 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](https://mcp.mintlify.app/specification/2025-11-25/basic/security_best_practices#mitigation) for this vulnerability in the MCP specification.

FastMCP is the standard framework for building MCP applications. Prior to version 2.14.2, the server does not properly respect the resource parameter submitted by the client in the authorization and token request. Instead of issuing the token explicitly for the MCP server, the token is issued for the base_url passed to the OAuthProxy during initialization. This issue has been patched 2.14.2.

### Summary While setting up an oauth client, it was noticed that the callback page hosted by the client during the flow embeds user-controlled content without escaping or sanitizing it. This leads to a reflected Cross-Site-Scripting vulnerability. ### Details The affected code is located in *https://github.com/jlowin/fastmcp/blob/main/src/fastmcp/client/oauth_callback.py*, which embeds all values passed to the `create_callback_html` function via the `message` parameter it into the callback page without escaping them. This can, for example, be abused by calling the callback server with an XSS payload inside the `error` GET parameter, the value of which will then be inserted into the callback page, causing the execution of attacker-controlled JavaScript code in the callback server's origin. Note that besides the `error` parameter, other parameters reaching this function are affected too. ### PoC 1. Setup a simple fastmcp client such as this one (the callback server's port was fixated for simplicity): ``` url="http://127.0.0.1:8000/mcp" oauth = OAuth(mcp_url=url,callback_port=1337) async def main(): async with Client(url, auth=oauth) as client: await client.ping() # List available operations tools = await client.list_tools() print(f"tools: {tools}") asyncio.run(main()) ``` 2. Ensure that the MCP server located at `http://127.0.0.1:8000/mcp` supports oauth. 3. Start the client. 4. As soon as the callback server has been started, access `http://localhost:1337/callback?error=<img/src/onerror=alert(window.origin)>` Note that the exploitation could also for example be initiated by a malicious authorization server by returning the exploitation URL mentioned before in the `authorization_endpoint` field. The client would then automatically open, causing the XSS to trigger immediatly. ### Impact The impact of this XSS vulnerability is the arbitrary JavaScript execution in the victim's browser in the callback server's origin.

### Summary A command-injection vulnerability lets any attacker who can influence the server_name field of an MCP execute arbitrary OS commands on Windows hosts that run fastmcp install cursor ### Details 1. generate_cursor_deeplink(server_name, …) embeds server_name verbatim in a cursor://…?name= query string. 2. open_deeplink() is invoked with shell=True only on Windows. That calls cmd.exe /c start <deeplink>. 3. Any cmd metacharacter inside server_name (&, |, >, ^, …) escapes the start command and spawns an attacker-chosen process. ### PoC server.py ``` import random 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)] if __name__ == "__main__": mcp.run() ``` then run in the terminal: `fastmcp install cursor server.py` ### Impact OS Command / Shell Injection (CWE-78) Every Windows host that runs fastmcp install cursor is at risk. Developers on their local workstations, CI/CD agents and corporate build machines alike.