CVE-2026-90474 in MCPHub
Summary
by MITRE • 09/12/2026
MCPHub before 1.0.32 contains an authentication bypass vulnerability in its embedded OAuth 2.0 authorization server where client authentication is disabled by default and PKCE enforcement is optional. Attackers who obtain an authorization code through interception can redeem it for access tokens without providing a client secret or PKCE verifier, gaining access to victim accounts and their privileges.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/12/2026
The vulnerability identified in MCPHub versions prior to 1.0.32 represents a critical failure in the implementation of OAuth 2.0 authentication protocols, specifically within its embedded authorization server component. The core technical flaw stems from two misconfigurations that fundamentally undermine the security model: client authentication is disabled by default, and Proof Key for Code Exchange PKCE enforcement is optional rather than mandatory. In standard OAuth 2.0 flows, particularly those involving public clients such as single-page applications or mobile apps, relying solely on an authorization code without additional verification mechanisms exposes the system to token interception attacks. By disabling client authentication, the server removes a layer of identity verification that typically requires confidential clients to present a secret during the token exchange phase. Furthermore, making PKCE optional allows attackers who have intercepted an authorization code in transit or via browser history to bypass the intended security controls designed to prevent authorization code injection and redirection-based attacks.
From an operational perspective, this vulnerability enables unauthorized access to user accounts by allowing any party with knowledge of a valid authorization code to redeem it for active access tokens without possessing legitimate credentials or secrets. This effectively neutralizes the confidentiality guarantees provided by the OAuth 2.0 framework when used in public client scenarios. An attacker can exploit this flaw through man-in-the-middle attacks, cross-site scripting vulnerabilities that steal codes from browser storage, or malicious extensions and scripts running on the victim's machine. Once the authorization code is obtained, the attacker exchanges it for access tokens at the token endpoint without providing a PKCE verifier or client secret, thereby gaining full privileges associated with the compromised user account. This leads to severe consequences including data exfiltration, unauthorized actions performed under the victim’s identity, and potential lateral movement within connected systems if those accounts have elevated permissions.
This vulnerability aligns closely with CWE-287 Improper Authentication, as the system fails to adequately verify the identity of the client requesting access tokens. It also maps to ATT&CK technique T1078 Valid Accounts, where attackers leverage stolen or intercepted credentials and tokens to maintain persistent access. Additionally, the lack of PKCE enforcement relates to CWE-345 Insufficient Verification of Data Authenticity, as the server accepts token requests based on incomplete proof of possession of the authorization code. The absence of mandatory client authentication further exacerbates this by allowing unauthenticated entities to complete the OAuth flow, violating best practices outlined in RFC 6749 and modern security guidelines for public clients which explicitly recommend PKCE even when client secrets are not feasible.
To mitigate this vulnerability, it is imperative that organizations running MCPHub upgrade immediately to version 1.0.32 or later where these defaults have been corrected. For environments unable to upgrade instantly, administrators should manually enforce strict configuration settings by enabling mandatory client authentication for all confidential clients and enforcing PKCE verification for all public clients regardless of default settings. Security teams must also implement network-level protections such as TLS inspection and intrusion detection systems capable of identifying abnormal token endpoint requests lacking proper cryptographic proofs. Regular audits of OAuth configurations against industry standards like NIST SP 800-63B guidelines on digital identity should be conducted to ensure that authentication flows remain resilient against interception and replay attacks, thereby preserving the integrity and confidentiality of user data and system privileges.