CVE-2026-79746: MCPHub: Server-scoped bearer key gains access to an entire group via partial (any-overlap) server matching
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
MCPHubto a version that resolves this vulnerability.Fixed in 1.0.31
Event History
Frequently Asked Questions
Which deployments are exposed to this access-control issue?
Deployments running MCPHub before version 1.0.31 are exposed if they use group routes and bearer keys with accessType set to 'servers' or 'custom'. The issue matters when an allowed server shares a group with servers that are not included in that key's allowedServers list.
What access does an attacker need to exploit it?
An attacker needs a bearer key scoped to at least one server in a group and must be able to send requests to that group's route. No user interaction is required.
What is the impact of a successful exploit?
The bearer key can gain full access to every server in the matching group, including servers outside the key's explicit allowedServers scope. The affected authorization path does not re-check allowedServers after authorizing the group-level connection.
What should be done if patching cannot happen immediately?
Avoid placing servers with different authorization requirements in the same group route. Restrict or revoke bearer keys using 'servers' or 'custom' access types where a key's allowed server shares a group with unauthorized servers.