CVE-2026-81094 in mcp-router
Summary
by MITRE • 08/27/2026
The mcp-router CLI served its MCP aggregator on every interface and enforced authentication only when the operator asked for it. The serve command in apps/cli/src/commands/serve.ts defaulted its host to the all-interfaces address on a fixed port, and required a token only when the corresponding flag was supplied, so a default invocation exposed the aggregator, and every MCP server it fronted, to anyone able to reach the port. Release 0.6.3 defaults the host to the loopback address and refuses to start without a token whenever the host it is given is not a loopback address; no earlier release carries either check.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/27/2026
The vulnerability in mcp-router CLI versions prior to 0.6.3 represents a critical misconfiguration of network binding and authentication enforcement, leading to unintended exposure of sensitive aggregation services. The core technical flaw resides in the serve command implementation within apps/cli/src/commands/serve.ts, which defaults its host parameter to zero-dot-zero-dot-zero (all interfaces) rather than restricting access to localhost or loopback addresses. This default behavior causes the MCP aggregator and every Model Context Protocol server it fronts to bind to all available network interfaces on a fixed port. Consequently, any device capable of reaching that specific port over the local area network or potentially wider networks can interact with the service without restriction if no additional security flags are explicitly provided by the operator during invocation.
The authentication mechanism is implemented as an optional feature rather than a mandatory baseline requirement for remote access. The system only enforces token-based authentication when the corresponding flag is supplied at runtime. In default invocations, where operators typically rely on standard startup procedures without explicit security configurations, this results in a complete lack of identity verification and authorization checks. This design flaw allows unauthenticated actors to query the aggregator, potentially accessing sensitive data processed by the connected MCP servers or manipulating system states if write operations are permitted through the protocol interface. The severity is compounded by the fact that earlier releases carry no such check whatsoever, meaning any deployment using default settings was inherently vulnerable to unauthorized access from any reachable network segment.
From an operational impact perspective, this vulnerability facilitates several malicious activities including data exfiltration, service disruption, and potential lateral movement within a network environment. An attacker with network reachability can enumerate the exposed services, extract confidential information processed by the MCP servers, or inject malformed requests to cause denial of service conditions. The exposure also violates fundamental security principles regarding least privilege and defense in depth, as it assumes implicit trust for all network connections rather than requiring explicit verification. This aligns closely with CWE-284 Improper Access Control and CWE-798 Use of Hard-coded Credentials if tokens were hardcoded or easily guessable, though the primary issue here is the absence of access control by default. In terms of MITRE ATT&CK framework mappings, this vulnerability enables Initial Access through T1078 Valid Accounts if credentials are compromised later, but more directly relates to Discovery techniques such as Network Service Scanning (T1046) and potentially Remote Services like T1021 Remote Desktop or custom protocol exploitation depending on the MCP server capabilities.
The remediation strategy implemented in release 0.6.3 addresses these issues by enforcing stricter defaults that align with secure-by-design principles. The host parameter now defaults to the loopback address, ensuring that the service is only accessible from the local machine unless explicitly configured otherwise for specific multi-host scenarios requiring additional security controls. Furthermore, the system refuses to start if a non-loopback host is specified without an accompanying authentication token. This mandatory coupling of network binding scope and access control ensures that any external exposure requires deliberate operator action and proper credential configuration. Organizations running affected versions should immediately upgrade to version 0.6.3 or later. For deployments where remote access is necessary, operators must explicitly configure the host parameter alongside a robust token-based authentication mechanism, ensuring that only authorized users can interact with the MCP aggregator and its underlying servers. Regular audits of network binding configurations and mandatory security flags in deployment scripts are recommended to prevent recurrence of such misconfigurations.