CVE-2026-27124 — fastmcp
CVE-2026-27124 is a CWE-441 vulnerability in fastmcp. A fix is available for fastmcp — see the affected versions and patch details below.
FastMCP: Missing Consent Verification in OAuth Proxy Callback Facilitates Confused Deputy Vulnerabilities
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-27124.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Real-World Exposure
fastmcpReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
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
- Set up an MCP server using the GitHubProvider integration.
- Connect a benign MCP client to this MCP server.
- Configure your default browser to route all traffic through an interception proxy such as Burp Suite.
- In a private browsing window or a second browser, log into the GitHub account used in step 2.
- As the attacker, connect a new (malicious) MCP client to the MCP server from step 1.
- When the browser opens for the attacker’s client, enable interception in your proxy.
- In the browser, confirm the consent prompt.
- In the proxy, forward all requests up to the authorization request to the GitHub authorization server.
- Copy the authorization URL and drop the intercepted request.
- Simulate luring the victim onto the URL by opening this URL in the browser window opened in step 4.
- 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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | fastmcp | all versions | 3.2.0pip install --upgrade 'fastmcp==3.2.0' |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for fastmcp, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update fastmcp to 3.2.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-27124 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2026-27124 can be triaged on real exposure rather than presence alone.
Tailored to CVE-2026-27124. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-27124 in your dependencies?
O3 Security finds CVE-2026-27124 across PyPI dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.