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.30, MCPHub scopes non-admin users to servers they own (list views and config edits enforce ownership), but the tool-execution API does not. Any authenticated non-admin user can invoke tools on MCP servers owned by other users — servers they cannot even see in GET /api/servers. Because connected MCP servers carry real capability (filesystem, HTTP fetch, cloud APIs with the owner's keys), this is cross-tenant compromise: demonstrated arbitrary host file read (/etc/passwd, another user's secrets) and SSRF. This issue has been patched in version 1.0.30.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.7",
  "pubDate": "2026-08-31T18:17:20.627Z",
  "pubdate": "2026-08-31T18:17:20.627Z",
  "executiveSummary": "MCPHub, prior to version 1.0.30, contains a critical broken access control vulnerability that enables cross-tenant unauthorized tool execution. While the application correctly enforces ownership scoping for configuration and list views, the tool-execution API lacks corresponding authorization checks. This design flaw allows any authenticated non-admin user to invoke tools on MCP servers owned by other users, despite these servers being hidden from the unauthorized user's interface.\nThe vulnerability poses a severe security risk, as MCP servers frequently hold sensitive capabilities, including local filesystem access, HTTP request generation, and cloud API integrations authenticated with the server owner's credentials. An attacker can exploit this to achieve arbitrary host file reads or perform Server-Side Request Forgery (SSRF) against internal infrastructure. Given that the tool-execution interface does not validate ownership, an attacker does not need to know the specific server ID to initiate malicious operations, provided they can guess or discover valid tool signatures. Successful exploitation results in complete compromise of the affected MCP server's resources and the identity of the owning user, fundamentally undermining the multi-tenancy model of the platform.",
  "technicalDetails": "The root cause of this vulnerability is an Insecure Direct Object Reference (IDOR) and a failure in authorization enforcement within the tool-execution API component of MCPHub. While the developers successfully implemented access control lists (ACLs) and ownership validation for administrative endpoints, such as 'GET /api/servers' and server configuration modification endpoints, these controls were entirely omitted from the tool-execution pipeline.\nThe attack flow begins with an authenticated non-admin user accessing the system. Although the UI properly filters out servers owned by other tenants, the API backend for executing tools fails to verify if the user is authorized to interact with the target MCP server ID. An attacker can manually craft requests to the tool-execution API targeting valid servers that exist within the system but are not associated with their account. Because the API processes these requests without verifying ownership of the target server, the request is executed with the context of the configured MCP server.\nThe impact of this vulnerability is significant due to the nature of MCP (Model Context Protocol) servers. These servers typically act as bridges for LLM agents, often configured with high-privilege credentials. If a targeted MCP server has filesystem read permissions, the attacker can execute tools to read sensitive system files, such as '/etc/passwd', or extract configuration files and secrets belonging to other users stored on the host. Furthermore, if the server is equipped with HTTP fetch capabilities, the attacker can use the server as a proxy to conduct SSRF attacks, potentially reaching internal network services that are otherwise protected by firewalls. The vulnerability does not require administrative privileges, only a standard authenticated session. Consequently, any malicious actor within the authenticated user base can leverage this flaw to perform unauthorized actions across the entire multi-tenant environment, escalating their privileges to those of any other user's MCP server configuration."
}