Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain limited-scope bearer key via legitimate provisioning
-
DeliveryIdentify group containing both authorized and unauthorized servers
-
ExploitSend POST request to group route endpoint
-
ExecutionPartial-membership check passes, full group access granted
-
PersistInvoke MCP tools against unauthorized servers
-
ImpactExfiltrate data or manipulate restricted server state
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization logic validation
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires possession of a valid bearer key with accessType set to 'servers' or 'custom', with at least one server listed in its allowedServers. The MCPHub instance must have bearer authentication enabled (routing.enableBearerAuth: true) and group name routing enabled (routing.enableGroupNameRoute: true). The targeted group must contain at least one server the key is authorized for and at least one additional server it is NOT authorized for - without this mismatch, no scope escalation occurs. Unauthenticated attackers without any bearer key cannot exploit this flaw. Deployments using only global-scope keys (accessType: 'all'), single-server groups, or no group routing are not affected by this vulnerability. |
| Impact | The CVSS 8.1 score (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N) accurately reflects the attack profile: network-reachable, low complexity, requiring only a valid but limited-scope bearer key with no user interaction. The high confidentiality and integrity impacts arise from the ability to invoke MCP tools and read data from servers the key was never authorized to access. No EPSS data was provided and there is no CISA KEV listing, so empirical exploitation rates are unconfirmed; however, the attack path is straightforward for any insider, contractor, or external integration partner holding a legitimately-issued scoped key - no vulnerability research or exploit development is required beyond knowing a group's membership. Any MCPHub deployment using group routes with server-scoped keys for access segmentation faces silent privilege escalation that leaves no error signals at the improperly-accessed servers, making detection difficult without audit logging of per-server access. Patch availability in v1.0.31 substantially reduces ongoing exposure for operators who upgrade promptly, and the comprehensive regression test suite added in the fix commit provides strong assurance that the corrected logic is well-validated. |
| Exploit ScenarioDerived | An attacker holds a legitimately-issued bearer key scoped to 'public-server' (accessType: 'servers') in a MCPHub deployment where 'public-server' and 'secret-server' share a group called 'team-group'. The attacker sends a POST request to /group/team-group with their token; since 'public-server' is a group member, the authorization check passes and full group access is granted, allowing the attacker to invoke MCP tools against 'secret-server' - a server they were explicitly never authorized to reach. No public exploit code has been identified, but the attack requires only knowledge of group membership, which may be discoverable through normal legitimate API usage. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Aug 31, 2026
Bearer key scope escalation in MCPHub prior to version 1.0.31 allows an authenticated API client holding a server-scoped key to silently access every server within a group, not just the one explicitly authorized. The isBearerKeyAllowedForRequest function performs an any-overlap check at the group level - if any server in the key's allowedServers list belongs to the requested group, the entire group is unlocked for that session with no further per-server re-validation. Exploitation requires only a valid but limited-scope bearer key and knowledge of group membership; no public exploit has been identified at time of analysis, though the CVSS 8.1 High rating reflects substantial confidentiality and integrity exposure.
RemediationAI
Upgrade MCPHub to version 1.0.31 or later, available at https://github.com/samanhappy/mcphub/releases/tag/v1.0.31. The fix, introduced in pull request #1059 (commit 2b10ae36), corrects the group-level authorization check to require that every server in the requested group is present in the key's allowedServers list, not merely any one member. Until patching is possible, administrators should restructure groups so that every server within a group shares the same access classification, eliminating intra-group scope mismatches; this removes the privilege escalation opportunity without disabling group routing entirely. Alternatively, disabling group name routing (routing.enableGroupNameRoute: false) removes the vulnerable code path entirely but will disrupt any workflows that depend on group-based MCP routing. Auditing existing bearer key assignments against group memberships is also recommended to identify whether any over-privileged access has already occurred.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
MCPHub is a TypeScript/Node.js application that acts as a centralized routing and management layer for multiple Model Context Protocol (MCP) servers, exposing them via separate HTTP endpoints with configurable routing strategies. Bearer keys are the authorization mechanism, configurable as accessType 'servers', 'custom', or 'all' to restrict which servers or groups a client may reach. The vulnerable function isBearerKeyAllowedForRequest evaluated group-route authorization using a partial-membership test - checking whether any server in the key's allowedServers list appears in the requested group - rather than requiring that every server within the group be covered by the key's scope. Once the group-level check passed, no further per-server authorization occurred for the lifetime of the connection. CWE-863 (Incorrect Authorization) precisely describes this root cause: the authorization decision is made at insufficient granularity, allowing a legitimately-credentialed client to exceed its intended permission boundary. No formal NVD CPE entry was registered for MCPHub at time of analysis; the project is maintained at github.com/samanhappy/mcphub.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N
Exploitation requires a valid bearer key (PR:L) and group routing enabled; no scope change occurs and availability is unaffected by authorization bypass alone.
Primary rating from Vendor (github).
CVSS VectorVendor: github
Lifecycle Timeline
2DescriptionCVE.org
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.
Technical POC Analysis
CWE-863 (Incorrect Authorization) - a set-containment check implemented as a set-intersection test, plus a missing downstream re-check.
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
MCPHub versions prior to 1.0.31 contain a bearer token scope escalation vulnerability allowing authenticated API clients with limited server authorization to silently access all servers within their group. This directly circumvents access control boundaries and creates unauthorized data access and modification risk across grouped infrastructure. Organizations using MCPHub should immediately audit bearer key deployments and scope assignments.
No vendor-released patch identified at time of analysis. Interim mitigations include: enforcing minimum-necessary scope on bearer keys, implementing additional per-request server-level authorization checks (not relying solely on group-level validation), enabling audit logging of all bearer authentication attempts, establishing mandatory bearer key rotation schedules, and disabling group-level access grants where server-scoped credentials would suffice.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
EUVD-2026-68688
NVD
CVE.org
EPSS
Vulnrichment
GitHub
Exploit-DB