Skip to main content
Vulnerability Database/CVE-2026-79746

CVE-2026-79746: MCPHub Authorization Bypass Vulnerability

CVE-2026-79746 is an authorization bypass flaw in MCPHub that allows attackers with limited server access to gain unauthorized access to all servers within a group. This post explains its impact, affected versions, and mitigation steps.

Published:

CVE-2026-79746 Overview

CVE-2026-79746 is a broken authorization vulnerability [CWE-863] in MCPHub, a unified hub for centrally managing and dynamically orchestrating multiple Model Context Protocol (MCP) servers into separate endpoints. Versions prior to 1.0.31 improperly validate bearer keys scoped with accessType: 'servers' or 'custom' when those keys are used against group routes. The isBearerKeyAllowedForRequest function grants access to an entire group if any single server in the group appears in the key's allowedServers list. Access is never re-checked once the group-level connection is authorized. A key scoped to one specific server therefore grants full access to every other server sharing that group.

Critical Impact

A bearer key scoped to a single MCP server can be used to reach every other server in the same group, bypassing the intended per-server authorization boundary.

Affected Products

  • MCPHub versions prior to 1.0.31
  • Deployments using group routes with bearer keys of accessType: 'servers'
  • Deployments using group routes with bearer keys of accessType: 'custom'

Discovery Timeline

  • 2026-08-31 - CVE-2026-79746 published to NVD
  • 2026-09-01 - Last updated in NVD database

Technical Details for CVE-2026-79746

Vulnerability Analysis

MCPHub allows administrators to issue bearer keys scoped to specific MCP servers. When a client authenticates against a group route, MCPHub evaluates whether the key can access the group. The pre-patch logic in isBearerKeyAllowedForRequest (in src/services/sseService.ts) accepts the request when at least one server in the target group matches the key's allowedServers list. After the initial group authorization succeeds, subsequent per-server operations within that connection are not re-evaluated against allowedServers.

The result is a horizontal privilege escalation across servers grouped together. A caller holding a key scoped to server-A can invoke tools, resources, and prompts belonging to server-B and server-C provided those servers share a group with server-A. Servers were never audited to be equivalent trust boundaries, so proxied MCP servers exposing sensitive tools or credentials become reachable from any key touching the same group.

Root Cause

The underlying flaw is missing full-containment authorization on group routes. The check evaluates set intersection between allowed servers and group members instead of set containment. It also caches the authorization decision at connection time and skips per-request re-validation, violating least-privilege enforcement across grouped resources.

Attack Vector

An authenticated attacker holding a low-privilege bearer key sends requests to a group route that includes their authorized server alongside additional servers. MCPHub authorizes the group connection and then routes cross-server calls without further checks. The attack requires network access to the MCPHub endpoint and low privileges (a valid, narrowly scoped key), and yields high confidentiality and integrity impact.

typescript
      }

      if (key.accessType === 'servers') {
-        // For server-scoped keys, check if any server in the group is allowed
+        // For server-scoped keys, the group is only accessible when every
+        // server in it is allowed (full containment). A key scoped to one
+        // group member must not gain access to the whole group (GHSA-454m-4vm6-842f).
         const allowedServers = key.allowedServers || [];
         if (allowedServers.length === 0) {
           return false;

Source: GitHub Commit 2b10ae3 — the patch replaces the permissive "any match" check with a full-containment requirement so that group access is granted only when every member server is present in allowedServers.

Detect Identity Attacks the Moment Authentication Fails

Singularity™ Identity surfaces credential misuse, lateral movement, and privilege escalation in real time, so you can contain the breach before it spreads.

Stop Identity Attacks

Detection Methods for CVE-2026-79746

Indicators of Compromise

  • Bearer key usage on group routes where the invoked server identifier does not appear in the key's allowedServers list.
  • MCPHub audit entries showing a single key accessing multiple distinct MCP servers within a short window.
  • Unexpected tool or resource invocations on MCP servers that were not enumerated as scopes for the calling key.

Detection Strategies

  • Parse MCPHub server logs and correlate keyId with the server field on each downstream MCP call, alerting when the target server is outside the key's original scope.
  • Compare the running MCPHub version against 1.0.31 across deployments and flag any instance below the fixed release.
  • Baseline expected server access per bearer key and generate alerts when a key expands its access footprint across group members.

Monitoring Recommendations

  • Enable verbose request logging on group route handlers and forward events to a centralized SIEM for authorization anomaly analysis.
  • Track creation and use of bearer keys with accessType: 'servers' or 'custom' and review any keys attached to groups containing more than one server.
  • Monitor MCP server endpoints for calls originating from clients that were previously scoped only to unrelated servers.

How to Mitigate CVE-2026-79746

Immediate Actions Required

  • Upgrade MCPHub to version 1.0.31 or later, which enforces full containment on group route authorization (GitHub Release v1.0.31).
  • Audit existing bearer keys and rotate any key that was used against multi-server groups while the vulnerable version was deployed.
  • Review group membership and remove servers that do not share the same trust boundary as other members.

Patch Information

The fix was merged in Pull Request #1059 and shipped in version 1.0.31. The change in src/services/sseService.ts requires that every server in a group appear in the key's allowedServers list before group access is granted, as documented in the GitHub Security Advisory GHSA-454m-4vm6-842f.

Workarounds

  • Reconfigure bearer keys so their allowedServers list fully contains every server present in any group route they authenticate against.
  • Split multi-server groups into single-server groups until upgrading, eliminating the cross-server escalation surface.
  • Restrict network access to MCPHub endpoints so only trusted clients can present bearer keys against group routes.
bash
# Verify installed MCPHub version and upgrade
npm ls @samanhappy/mcphub
npm install @samanhappy/mcphub@1.0.31

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.