MCPHub OAuth flaw lets attackers swap codes for tokens

MCPHub, an open-source hub for Model Context Protocol servers, contains an authentication bypass in the OAuth 2.0 authorization server built into the product, according to a National Vulnerability Database entry published on 12 September 2026. The flaw, tracked as CVE-2026-90474, affects all versions before 1.0.32. Anyone who manages to intercept an authorization code can exchange it for an access token and gain access to the victim's account and its privileges, the entry says.

The cause is configuration rather than a coding error in the usual sense. According to the NVD description, client authentication is disabled by default in MCPHub's embedded authorization server, and enforcement of PKCE is optional. PKCE, short for Proof Key for Code Exchange, is the standard mechanism that ties an authorization code to the specific client that requested it, by requiring that client to present a secret verifier when it redeems the code. With both checks off, the token endpoint accepts a code without a client secret and without a PKCE verifier.

That combination removes the two safeguards that normally make a stolen authorization code useless. The NVD entry states that attackers who obtain a code through interception can redeem it for access tokens and take on the victim's privileges. In an MCP hub, those privileges typically cover whatever tool servers the account is allowed to reach, which is why the issue matters beyond a single login.

The NVD record lists several references for the issue. They include a specific range of lines in the project's OAuth server service file at tag v1.0.31, a commit that changes that behaviour, the release notes for version 1.0.32, a GitHub security advisory carrying the identifier GHSA-3m7m-37xf-xp9x, and an advisory published by the security vendor VulnCheck. The fix is available in MCPHub 1.0.32, and operators running any earlier version should treat an upgrade as the remedy.

The practical advice for anyone running MCPHub is straightforward. Check the installed version first. If it is below 1.0.32, upgrade. After upgrading, confirm that client authentication is switched on and that PKCE is required rather than optional, because a default-off setting can survive an upgrade if it has been written into a local configuration file. Because the attack uses valid tokens issued by the server, existing access tokens and refresh tokens issued before the upgrade should be treated as suspect and rotated.

Detection is harder than patching. A successful exploit looks like an ordinary token exchange in server logs, because from the authorization server's point of view nothing invalid happened. Operators may have more luck looking for token redemptions from unexpected network addresses, or for the same authorization code being presented more than once.

No exploitation in the wild has been reported in the listed references, and the NVD entry does not describe any specific affected deployments. It also does not say who reported the issue. The record is marked as confirmed, with the vulnerability discovered on 12 September 2026 and a fixed release already published.