MCPHub Missing Authorization Leading to Arbitrary Command Execution via MCP Server Config

Technical Analysis

The POST /api/servers and PUT /api/servers/:name endpoints accept a server configuration and pass its command/args fields directly into child_process.spawn to launch a stdio-based MCP server process. While the endpoints require authentication, they lack any authorization check ensuring only admins can create or modify server configs, and there is no allowlist or sanitization of the command/args fields. A low-privileged authenticated attacker can submit a configuration specifying an arbitrary binary (e.g., /bin/sh) with attacker-controlled arguments, causing MCPHub to spawn that process under its own OS privileges — commonly root in default Docker/npx/systemd deployments. This crosses a critical trust boundary: the MCP orchestration layer, intended only to route/manage trusted MCP server processes, becomes a direct code execution primitive reachable by any authenticated user, effectively turning a management API into a privilege escalation and host compromise vector.

Affected Systems

MCPHub; protocols: MCP

Detection Signatures

• Unexpected child_process.spawn calls with command values like /bin/sh, /bin/bash, cmd.exe, or unusual binaries from non-admin accounts
• POST /api/servers or PUT /api/servers/:name requests from non-admin user tokens/roles
• Server configuration entries with anomalous args fields containing shell metacharacters, reverse shell payloads, or download-and-execute patterns
• MCPHub audit logs showing server creation/update immediately followed by process spawn events
• MCP server processes running as root/unexpected UID shortly after API-driven config changes

Remediation Steps

1. 1

   Upgrade MCPHub

   Update to version 0.12.15 or later, which patches the missing authorization check on server configuration endpoints.

2. 2

   Enforce admin-only authorization

   Ensure POST/PUT server configuration endpoints require and verify admin-level role/permission, not just authentication.

3. 3

   Sanitize and allowlist command execution

   Restrict the command field to a predefined allowlist of vetted MCP server binaries; reject arbitrary shells or interpreters and validate/sanitize args.

4. 4

   Run with least privilege

   Avoid running MCPHub and spawned MCP server processes as root; use a dedicated low-privilege service account and container user.

5. 5

   Audit and monitor

   Review audit logs for recent server configuration changes by non-admin users and monitor process spawn events for anomalous commands.

6. 6

   Network and deployment hardening

   In Docker/npx/systemd deployments, apply seccomp/AppArmor profiles and drop unnecessary capabilities to limit blast radius of any successful exploitation.