CVE-2026-81094: mcp-router CLI before 0.6.3 Binds the MCP Aggregator to All Interfaces Without Requiring Authentication
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
mcp-router CLIto a version that resolves this vulnerability.Fixed in 0.6.3 - Configuration
In the mcp-router CLI, ensure the MCP aggregator host defaults to the loopback address (and refuses to start without a token when the provided host is not a loopback address), as implemented in release 0.6.3.
mcp-router CLI (MCP aggregator) host binding = loopback only - Configuration
Enforce authentication for MCP aggregation when the host is not a loopback address (release 0.6.3 refuses to start without a token in that case).
mcp-router CLI (MCP aggregator) authentication requirement = require token when host is not loopback
Event History
Frequently Asked Questions
Which deployments are exposed by default?
Any pre-0.6.3 deployment started with the default serve command is exposed to hosts that can reach its fixed listening port. The default host bound the aggregator to all network interfaces, and no token was required unless the operator explicitly supplied one.
What does an attacker need to exploit this issue?
An attacker needs only network reachability to the aggregator's listening port. No authentication, credentials, or user interaction is required under the vulnerable default configuration.
What is exposed if the aggregator is reachable?
The MCP aggregator and every MCP server it fronts are exposed to anyone able to reach the port. The issue can affect the confidentiality and integrity of resources available through those servers.
What can be done before upgrading?
Restrict the service to a loopback address or otherwise prevent untrusted network access to its listening port, and require a token. Version 0.6.3 also enforces a token whenever a non-loopback host is configured.
How can operators determine whether they are affected?
Check whether the installed mcp-router version is earlier than 0.6.3 and whether the service was started without an explicit loopback host and token. Earlier releases do not include either the loopback default or the non-loopback token requirement.