MCPHub OAuth 2.0 Authorization Code Redemption Without Client Authentication or PKCE

Technical Analysis

The vulnerability stems from insecure default configuration in MCPHub's authorization server: client_secret verification is off by default, and PKCE (Proof Key for Code Exchange) enforcement is not mandatory. In a properly configured OAuth 2.0 flow, PKCE and/or client authentication prevent a stolen authorization code from being redeemed by anyone other than the legitimate client that initiated the flow. Here, an attacker who intercepts the authorization code (via open redirects, malicious browser extensions, network-level interception, or a compromised redirect URI) can directly call the token endpoint and receive access tokens impersonating the victim. Because MCPHub acts as an authorization layer sitting in front of MCP servers/tools, this token grants the attacker the victim's full delegated privileges to invoke tools and access resources exposed through MCP, crossing the trust boundary between the identity provider and every downstream MCP server relying on it. The flaw is entirely server-side configuration/design and requires no client-side compromise beyond intercepting one authorization code.

Affected Systems

MCPHub; protocols: MCP,OAuth 2.0

Detection Signatures

• Token endpoint requests missing client_secret or code_verifier parameters that still succeed
• Anomalous access token issuance correlated with authorization codes not preceded by a matching PKCE challenge in server logs
• Multiple token exchange attempts for the same authorization code from differing IP addresses/user agents
• MCPHub server version < 1.0.32 in deployment inventory
• Configuration audit showing require_client_authentication=false or pkce_required=false

Remediation Steps

1. 1

   Upgrade MCPHub

   Update to MCPHub version 1.0.32 or later where this authentication bypass is patched.

2. 2

   Enforce PKCE mandatorily

   Configure the OAuth server to require PKCE (S256) for all authorization code flows, rejecting any request without a valid code_verifier.

3. 3

   Enable client authentication

   Turn on mandatory client_secret or mTLS-based client authentication for confidential clients; do not rely on defaults.

4. 4

   Rotate credentials and audit tokens

   Rotate client secrets and review recently issued access tokens for signs of anomalous redemption or use from unexpected sources.

5. 5

   Harden redirect URI validation

   Enforce strict, exact-match redirect URI allowlisting to reduce the risk of authorization code interception via open redirects.

6. 6

   Monitor token endpoint logs

   Add alerting for token exchanges lacking client authentication or PKCE parameters, and for reused/duplicate authorization codes.