MCPHub Bearer Key Group-Scope Privilege Escalation

Technical Analysis

The vulnerability lies in the isBearerKeyAllowedForRequest function, which validates bearer keys of accessType 'servers' or 'custom' against group routes. Instead of confirming that every server a request touches is present in the key's allowedServers list, the check passes as soon as ANY single server in the group matches, and it never re-validates allowedServers once the group-level connection is established. This means a key issued for narrow, single-server access is treated as valid for the entire group, granting lateral access to MCP servers/APIs the key owner was never authorized to reach. Because MCPHub centrally proxies and routes requests to downstream MCP servers, this flaw crosses a trust boundary between tenants or scoped integrations, potentially exposing tools, data, or credentials belonging to other services in the same group.

Affected Systems

MCPHub; protocols: MCP

Detection Signatures

• Audit logs showing bearer key access to MCP servers outside its documented allowedServers scope
• Requests to group routes where the authenticated key's allowedServers list contains only a subset of servers actually accessed
• Unexpected cross-server tool invocations shortly after a single group-level authorization event
• MCPHub version < 1.0.31 in deployment inventory

Remediation Steps

1. 1

   Upgrade MCPHub

   Update to MCPHub version 1.0.31 or later, which patches the isBearerKeyAllowedForRequest logic to enforce per-server checks.

2. 2

   Audit bearer key scopes

   Review all issued bearer keys with accessType 'servers' or 'custom' and verify actual access logs against intended allowedServers scope to detect prior misuse.

3. 3

   Rotate potentially exposed keys

   Rotate bearer keys that were scoped to servers within shared groups, since their effective access may have exceeded documented intent prior to patching.

4. 4

   Enforce per-request re-validation

   Where custom deployments exist, ensure authorization middleware re-checks allowedServers on every downstream request rather than relying on a single group-level authorization decision.

5. 5

   Segment high-sensitivity servers

   Avoid grouping MCP servers with differing trust or sensitivity levels under the same routing group to limit blast radius of similar flaws.