Submit #944364: mcphub <= 1.0.31 Improper Authentication

Summary
MCPHub ships an OAuth 2.0 authorization server (@node-oauth/oauth2-server) whose default configuration (requireClientSecret:false, dynamicRegistration.requiresAuthentication:false) disables client authentication at the token endpoint and exposes unauthenticated, unthrottled client registration. This default posture produces three weaknesses in the same subsystem:

PKCE is never enforced — code_challenge is optional and no branch rejects its absence for public/dynamically-registered clients.
Client-secret verification is skipped when the secret is omitted — even a confidential client that was issued a client_secret can be driven through /oauth/token with no secret.
Dynamic client registration (/oauth/register) is unauthenticated and unthrottled — an anonymous attacker can freely mint the public client used to drive the flow, and can flood the in-memory client store (resource exhaustion).
In the shipped default posture, an OAuth flow can be driven with no client secret and no code_challenge, leaving the authorization code as the only protection. Anyone who intercepts a code (open redirect, browser history, Referer, shared device) can redeem it at /oauth/token with no secret and no verifier, obtaining an access token bound to the victim's identity and carrying the victim's privileges. When the victim is an administrator the token is accepted as an isAdmin bearer credential on the dashboard API; when the victim is a regular user the token carries only that user's non-admin privileges. Maximum impact (admin takeover) requires an admin victim, reflected in the CVSS below.

• Source: ⚠️ https://github.com/samanhappy/mcphub/security/advisories/GHSA-3m7m-37xf-xp9x
• User: wshi.24 (UID 98607)
• Submission: 08/24/2026 03:31 (27 days ago)
• Moderation: 09/19/2026 11:31 (26 days later)
• Status: Duplicate
• VulDB entry: 403121 [samanhappy MCPHub up to 1.0.31 OAuth 2.0 Authorization Server improper authorization]
• Points: 0