Description

MCPHub is a unified hub for centrally managing and dynamically orchestrating multiple MCP servers/APIs into separate endpoints with flexible routing strategies. Prior to version 1.0.31, when a bearer key with accessType: 'servers' (or 'custom') is used against a group route, isBearerKeyAllowedForRequest grants access to the entire group as long as any single server in that group appears in the key's allowedServers list — not only when every server the key is scoped to matches, and critically, without ever re-checking allowedServers again once the group-level connection is authorized. A key explicitly scoped to one specific server therefore also grants full access to every other server that happens to share a group with it, including servers the key was never authorized for. This issue has been patched in version 1.0.31.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.1",
  "pubDate": "2026-08-31T18:17:20.057Z",
  "pubdate": "2026-08-31T18:17:20.057Z",
  "executiveSummary": "The vulnerability is a broken access control flaw within MCPHub occurring prior to version 1.0.31, categorized as an authorization bypass.\nThis flaw enables an attacker possessing a bearer key scoped to a specific server to gain unauthorized access to any other server within the same configured group.\nThe root cause lies in the misconfiguration of the isBearerKeyAllowedForRequest function, which fails to perform granular authorization checks during group-level routing.\nAn attacker can escalate privileges by leveraging a key authorized for a single, low-privilege server to interact with sensitive or restricted servers that happen to be co-located within the same group.\nThis represents a significant security risk, as it effectively nullifies the intended scope of bearer keys and enables lateral movement across the managed server infrastructure.\nExploitation requires a valid, albeit restricted, bearer key and the ability to interact with the MCPHub routing interface.\nThe issue is resolved in version 1.0.31 through corrected logic in the authorization flow.",
  "technicalDetails": "The vulnerability exists within the logic of the isBearerKeyAllowedForRequest function in MCPHub versions prior to 1.0.31. The function is responsible for validating whether a provided bearer key, utilizing the accessType 'servers' or 'custom', possesses the necessary permissions to interface with a specific request route.\nThe architectural design of MCPHub allows for the logical grouping of multiple MCP servers/APIs under specific endpoints. When a request is routed through a 'group route', the current authorization logic evaluates the key's allowedServers list against the target group. The implementation flaw occurs when the check returns true if any single server associated with the target group appears within the key's allowedServers configuration. Essentially, the system performs an OR-based validation instead of ensuring that the requested server within the group is explicitly authorized.\nFurthermore, once the group-level connection is successfully authorized, the system fails to re-validate the bearer key's permissions against the specific target server within the group. Consequently, authorization for one member of the group is incorrectly treated as a blanket authorization for the entire group entity. This results in a complete bypass of the principle of least privilege, as a key scoped for a single, non-sensitive server gains full access to all resources within that group context.\nThe attack flow proceeds as follows: 1) An attacker identifies a bearer key with restricted scope (e.g., access permitted only to 'Server-A'). 2) The attacker identifies a group containing 'Server-A' and a sensitive 'Server-B'. 3) The attacker submits a request via the MCPHub group endpoint targeting 'Server-B'. 4) The isBearerKeyAllowedForRequest function checks the key against the group; it detects that the key is allowed for 'Server-A' (a member of the group) and erroneously grants access to the entire group context. 5) The request is routed to 'Server-B' without further server-specific authorization, allowing the attacker to perform operations unauthorized by their original scope.\nThis vulnerability is restricted to environments utilizing group routing configurations. It requires the attacker to hold an existing bearer key, but does not necessitate elevated privileges on the target servers themselves. The impact is critical, as it facilitates unauthorized data access, potential remote code execution, or service disruption depending on the capabilities exposed by the other servers within the group."
}