MCPHub Broken Object-Level Authorization on Tool Execution API

Technical Analysis

MCPHub centrally manages multiple MCP servers per user and routes tool invocations to the appropriate backend server/API. While GET /api/servers and configuration edit endpoints enforced per-user ownership, the tool-execution endpoint accepted a server identifier without validating that the requesting user actually owned or was authorized to use that server. An attacker only needed to guess or enumerate server IDs belonging to other tenants (servers not even visible to them in listings) to invoke arbitrary tools bound to those servers. Because MCP servers wrap real capabilities such as filesystem access, HTTP fetch, and cloud APIs authenticated with the owner's credentials, this authorization gap allowed attackers to read sensitive host files (e.g., /etc/passwd), exfiltrate other users' secrets, and perform SSRF through the victim's connected integrations — a classic broken object-level authorization (BOLA) crossing tenant and tool boundaries in an agent orchestration layer.

Affected Systems

MCPHub; protocols: MCP

Detection Signatures

• API requests to tool-execution endpoints referencing server IDs not owned by the authenticated user
• Log entries showing tool invocation success for a server absent from that user's /api/servers listing
• Unexpected outbound HTTP requests (SSRF) originating from MCP server tool calls to internal/unlisted hosts
• File read tool invocations targeting sensitive paths like /etc/passwd or credential stores by unauthorized accounts
• Spikes in cross-user server ID enumeration patterns in access logs

Remediation Steps

1. 1

   Upgrade MCPHub

   Update to MCPHub version 1.0.30 or later, which enforces ownership checks on the tool-execution API.

2. 2

   Enforce authorization on all endpoints, not just views

   Audit every API route (list, config, and execution) to ensure consistent object-level authorization checks tied to the authenticated user's ownership or role, following a centralized authorization middleware pattern.

3. 3

   Audit logs for exploitation

   Review historical tool-execution logs for calls referencing server IDs outside a user's ownership scope, and rotate any credentials/API keys potentially exposed through affected MCP servers.

4. 4

   Apply least-privilege to MCP server credentials

   Scope API keys and filesystem/network access granted to each MCP server as narrowly as possible so a single authorization bypass cannot yield broad host or cloud access.

5. 5

   Add tenant isolation tests

   Introduce automated security tests (BOLA/IDOR test suites) covering every endpoint that accepts a resource identifier to catch missing ownership checks before release.