MCPHub bug let stolen OAuth codes become tokens

MCPHub versions before 1.0.32 let an attacker who intercepts an OAuth authorization code redeem it for access tokens, no extra proof required. The bug lives in MCPHub's embedded OAuth 2.0 authorization server, where client authentication is off by default and PKCE enforcement is optional rather than mandatory. NVD rates it CVSS 7.6 and published the entry September 12.

The stakes are bigger than one product. MCPHub is an aggregator, the layer that sits between an AI agent and every tool it's allowed to call. That's the worst place in the stack to leave an auth flow half-locked, because a stolen token there doesn't just expose one integration. It exposes whatever the aggregator was holding credentials for.

This is the second time in a week the same shape has shown up. Langflow and ContextForge disclosed comparable auth-bypass issues two days earlier. Three unrelated projects landing on the same missing check, permissive-by-default client auth plus optional PKCE, isn't a coincidence of timing. It's what happens when a category of software gets built fast on a shared reference implementation and nobody hardens the defaults before shipping.

If you're running an MCP aggregator anywhere near production, PKCE and client authentication need to be mandatory, not configurable. Check what your aggregator defaults to before you trust it with real credentials, because the assumption that a spec-compliant OAuth server is a secure one keeps failing in the same spot.