CVE-2026-90474: MCPHub OAuth 2.0 Auth Bypass Vulnerability

CVE-2026-90474 Overview

CVE-2026-90474 is an authentication bypass vulnerability in MCPHub versions prior to 1.0.32. The flaw resides in the project's embedded OAuth 2.0 authorization server, where client authentication is disabled by default and Proof Key for Code Exchange (PKCE) enforcement is optional. An attacker who intercepts an authorization code can redeem it for access tokens without presenting a client secret or PKCE verifier. Successful exploitation grants the attacker access to the victim's MCPHub account and its associated privileges. The weakness is classified under [CWE-287: Improper Authentication].

Critical Impact
Attackers who intercept an OAuth authorization code can obtain valid access tokens and fully impersonate the victim within MCPHub, bypassing account authentication.

Affected Products

MCPHub versions prior to 1.0.32
MCPHub v1.0.31 (confirmed vulnerable via src/services/oauthServerService.ts)
Deployments exposing the embedded OAuth 2.0 authorization server

Discovery Timeline

2026-09-12 - CVE-2026-90474 published to the National Vulnerability Database
2026-09-15 - Last updated in NVD database
Release v1.0.32 - Patched release published on GitHub with the GHSA-3m7m-37xf-xp9x advisory

Technical Details for CVE-2026-90474

Vulnerability Analysis

MCPHub embeds an OAuth 2.0 authorization server to broker access to protected resources. In versions before 1.0.32, the authorization code grant flow accepts token exchange requests without verifying the client's identity. Two protections that normally close this gap were both disabled by default. First, client authentication (validation of a registered client_secret) was optional. Second, PKCE enforcement, defined in RFC 7636, was not required for public clients. An attacker who captures an authorization code from a redirect, log, referer header, or proxy can present it to the token endpoint alone. The server returns access tokens tied to the victim account, allowing full account takeover within the scope of the granted OAuth privileges.

Root Cause

The root cause is insecure default configuration in the OAuth server logic located in src/services/oauthServerService.ts (lines 26-38 of v1.0.31). The token endpoint did not require confidential clients to authenticate and did not require public clients to complete a PKCE challenge with code_challenge_method=S256. This violates the RFC 6749 and RFC 7636 recommendations that authorization codes must be bound to a client identity or a proof of possession value.

Attack Vector

Exploitation requires the attacker to obtain an authorization code intended for a victim. Common interception paths include open redirect abuse, malicious client applications, network traffic capture on non-HTTPS legs, browser history or referer leakage, and server-side log exposure. User interaction is required to trigger the initial authorization flow. Once the code is captured, the attacker submits it to the MCPHub token endpoint and receives access tokens without further validation.

typescript

// Security patch applied in src/controllers/oauthServerController.ts
// fix(security): enforce OAuth client auth and S256-only PKCE policy
      return;
    }

    // RFC 7636 + GHSA-3m7m: public clients (no registered secret) must present
    // an S256 code challenge up front. Confidential clients may omit PKCE.
    if (!client.clientSecret && (!code_challenge || code_challenge_method !== 'S256')) {
      res.status(400).json({
        error: 'invalid_request',
        error_description: 'PKCE with code_challenge_method=S256 is required for public clients',
      });
      return;
    }

    // Check if user is authenticated (including via JWT token)
    let user = (req as any).user;
    if (!user) {

Source: GitHub Commit e927620. The patch adds an early rejection path that forces public OAuth clients to supply an S256code_challenge before token issuance can proceed.

Detection Methods for CVE-2026-90474

Indicators of Compromise

Successful /oauth/token exchanges where the request body lacks both a client_secret and a code_verifier parameter.
Authorization codes redeemed from a client IP address that differs from the IP that initiated the /authorize request.
Newly issued access tokens for accounts that did not perform an interactive login in the same session window.
MCPHub instances running versions listed as prior to 1.0.32 in build manifests or container images.

Detection Strategies

Enable verbose OAuth server logging on MCPHub and alert on token grants where client_authentication=false and pkce=none.
Correlate /authorize and /token events by session identifier to flag mismatched user agents or source addresses.
Inventory MCPHub deployments across the environment and cross-reference the running version against the fixed release v1.0.32.
Baseline OAuth clients registered with MCPHub and alert on any client entries created without a clientSecret value.

Monitoring Recommendations

Forward MCPHub application logs to a central analytics platform and retain OAuth transaction records for at least 90 days.
Monitor egress proxies and reverse proxies for authorization code values appearing in URL query strings or referer headers.
Alert on privilege changes and API activity occurring immediately after a token issuance event with no prior user login.

How to Mitigate CVE-2026-90474

Immediate Actions Required

Upgrade all MCPHub instances to release 1.0.32 or later without delay.
Rotate all OAuth client secrets and revoke active access and refresh tokens issued by vulnerable versions.
Audit registered OAuth clients and remove entries that lack a clientSecret unless they are required public clients using PKCE.
Review authentication logs for the past 90 days for token exchanges that match the indicators listed above.

Patch Information

The fix is delivered in MCPHub release v1.0.32 and tracked in the GHSA-3m7m-37xf-xp9x advisory. The corrective commit e927620 enforces client authentication for confidential clients and mandates S256 PKCE for public clients at the token endpoint. Additional context is available in the VulnCheck Security Advisory.

Workarounds

Restrict network access to the MCPHub OAuth endpoints so that only trusted client applications can reach /authorize and /token.
Terminate all OAuth flows over HTTPS and disable HTTP listeners to reduce authorization code interception risk.
Register every OAuth client with a strong clientSecret and reject clients that cannot store one confidentially.
If upgrading immediately is not possible, take the MCPHub OAuth server offline until the patched release can be deployed.

bash

# Upgrade MCPHub to the patched release
npm install -g mcphub@1.0.32

# Or pull the patched container image and restart the service
docker pull samanhappy/mcphub:1.0.32
docker stop mcphub && docker rm mcphub
docker run -d --name mcphub -p 3000:3000 samanhappy/mcphub:1.0.32

# Verify the running version
curl -s http://localhost:3000/api/version