JustAppSec
Back to news

FastMCP patches OAuth proxy confused deputy vulnerability

2 min readPublished 03 Apr 2026Updated 03 Apr 2026Source: CVEProject (cvelistV5)

TL;DR — FastMCP’s OAuth proxy callback didn’t verify that the current browser session actually consented, enabling a confused-deputy flow that can yield victim-bound authorization codes/tokens.

What happened

FastMCP is a framework for building Model Context Protocol (MCP) applications, including an OAuthProxy component used to authenticate clients to MCP servers via third-party identity providers.

CVE-2026-27124 describes a High-severity confused deputy issue in FastMCP’s GitHub OAuth integration: the OAuthProxy does not properly validate user consent when handling the IdP callback (authorization code + state). Per the linked GitHub advisory referenced by the CVE record, an attacker can start a login flow with a malicious MCP client, capture the GitHub authorization URL after consenting, and then trick a victim (already logged into GitHub and previously authorized) into opening that URL. Because GitHub may skip the consent screen for previously authorized clients, the victim can be redirected straight into the proxy callback path; the proxy then forwards a valid authorization code to the attacker-controlled client callback.

This matters because OAuth systems commonly optimize UX by skipping repeated consent prompts, and any proxy that fails to bind consent to the initiating browser session can become an account-impersonation primitive in otherwise “standard” OAuth flows.

Who is impacted

  • Deployments using fastmcp’s OAuthProxy with the GitHubProvider OAuth integration.
  • Projects running versions marked as affected in the CVE record: fastmcp < 3.2.0.
  • Highest risk environments are those where users have previously connected MCP clients to the same server and attackers can lure users to open a captured authorization URL.
ComponentAffected versions (per CVE record)Patched version referenced by source
fastmcp (pip)< 3.2.03.2.0

Note: the advisory text indicates the issue was verified in practice for GitHubProvider, and warns the pattern can affect other IdPs that skip consent prompts for previously authorized clients.

What to do now

  • Follow vendor remediation guidance and apply the latest patched release available at the time of writing.
    • "This issue has been patched in version 3.2.0."

  • Inventory MCP servers using fastmcp and identify whether OAuthProxy + GitHub OAuth is enabled (internet-exposed instances should be prioritized).
  • Treat this as an identity boundary issue: review whether compromised access tokens could grant access to tenant data, tool credentials, or downstream APIs reachable from the MCP server.
  • If compromise is suspected, review OAuth redirect/callback logs for anomalous authorization flows and rotate credentials/tokens accessible to impacted MCP server identities.
  • Consider implementing the mitigation pattern described in the advisory:
    • "the OAuthProxy should verify that the browser sending the authorization code has actually given consent"


Content is AI-assisted and reviewed by our team, but issues may be missed and best practices evolve rapidly, send corrections to [email protected]. Always consult official documentation and validate key implementation decisions before making design or security choices.

Need help?Get in touch.