CVE-2026-79746 in MCPHub
Summary
by MITRE • 08/31/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/31/2026
The vulnerability identified within MCPHub prior to version 1.0.31 represents a critical flaw in the access control logic governing server groups and bearer token validation. MCPHub functions as a centralized orchestration layer that manages multiple Model Context Protocol servers, routing requests through flexible strategies while enforcing security policies via bearer keys. The core issue resides in the isBearerKeyAllowedForRequest function, which determines whether an incoming request authenticated by a specific bearer key should be granted access to a target server or group of servers. In versions preceding 1.0.31, the logic for validating access against groups containing multiple servers was fundamentally broken due to an incorrect logical operator and insufficient state re-evaluation during route traversal.
The technical flaw stems from how the system evaluates allowedServers lists when a bearer key with accessType set to 'servers' or 'custom' is applied to a group route. Instead of requiring that every server within the targeted group be explicitly listed in the key's allowedServers attribute, the implementation utilized an OR-based logic check. This means that if any single server present in the target group was included in the bearer key's whitelist, the function would immediately grant access to the entire group. Crucially, once this initial authorization decision is made at the group level, the system does not re-check or validate individual server permissions for subsequent requests within that same session or context. This design oversight effectively bypasses granular permission boundaries intended by the administrator who scoped the key to specific servers only.
The operational impact of this vulnerability allows an attacker possessing a bearer token scoped to a single, potentially low-privilege or isolated MCP server to escalate their privileges and access all other servers within the same logical group. This constitutes a severe authorization bypass where lateral movement across internal services becomes trivial for any entity with valid credentials for just one component in the cluster. The security model assumes isolation between distinct API endpoints based on explicit allowlists, but this flaw collapses that perimeter by treating partial membership as full membership. Consequently, sensitive data or control planes residing on servers not intended to be accessible via a particular key are exposed without additional authentication checks.
This vulnerability aligns with CWE-269, which describes Improper Privilege Assignment, specifically where the system fails to enforce appropriate restrictions for elevated privileges that could lead to compromise of security-critical functionality. Furthermore, from an offensive perspective, this behavior facilitates ATT&CK technique T1078, Valid Accounts, by allowing a compromised or leaked credential with limited scope to be leveraged against broader infrastructure components than originally intended. The lack of per-server re-validation during group-based routing means that the principle of least privilege is violated at the architectural level rather than just through misconfiguration.
The issue has been resolved in version 1.0.31 by correcting the logical evaluation within the access control module to ensure strict adherence to explicit allowlists for each individual server, even when accessed via group routes. Administrators running older versions must upgrade immediately to mitigate this risk. In addition to patching, organizations should audit their bearer key configurations to identify any keys that were scoped narrowly but could have inadvertently granted broad access due to shared grouping structures. Implementing strict separation of groups for critical infrastructure and regularly reviewing token permissions against the actual required scope will further harden the environment against similar logical flaws in future updates.