MCP-Hub Endpoint Exposed Without Auth or Rate Limiting, Relies on Network Isolation

A critical security oversight has been identified in the MCP-Hub server, where its primary JSON-RPC endpoint is exposed without standard authentication or rate-limiting controls. The hub's `POST /` endpoint, which handles sensitive operations like `execute_code`, is bound to `0.0.0.0` and accepts requests from any process on the container network. This vulnerability exists because the hub manually constructs its Express application, bypassing the standard `createMCPServer()` factory function that automatically enforces bearer authentication with timing-safe comparison and sliding-window rate limiting.

The risk is currently assessed as low (P3) due to strong mitigating network controls. The hub does not map its ports to the host machine, a configuration enforced by the absence of `ports:` in the `compose.template.yml`. Furthermore, a `SecurityCheck::check_no_ports_on_workers()` function actively blocks attempts to expose these ports. The architecture confines the hub to a per-project, isolated bridge network, meaning only the Claude process and the five designated MCP workers can communicate with it.

While the network isolation significantly reduces the immediate attack surface, the absence of fundamental application-layer security controls represents a latent risk. The setup creates a security model that is entirely dependent on the integrity and correct configuration of the container network, rather than implementing defense-in-depth with proper endpoint authorization. Any future misconfiguration, container escape, or network compromise could potentially expose the unauthenticated `execute_code` functionality.