`createMcpExpressApp` / `createMcpHonoApp`: non-loopback `host` silently skips Host/Origin checks (only `0.0.0.0`/`::` warn) |

[tiagovilasboas]

Static review of public source at commit 603217008710. No traffic was sent to any MCP environment.

createMcpExpressApp (and the matching Hono helper) auto-arm Host + Origin validation only for loopback hosts. Binding to 0.0.0.0 / :: logs a warning, but any other non-loopback host (LAN IP, container hostname, public DNS name) gets neither middleware nor that warning:

packages/middleware/express/src/express.ts (same ladder in packages/middleware/hono/src/hono.ts):

const localhostHosts = ['127.0.0.1', 'localhost', '::1'];
if (localhostHosts.includes(host)) {
    app.use(localhostHostValidation());
} else if (host === '0.0.0.0' || host === '::') {
    console.warn(
        `Warning: Server is binding to ${host} without DNS rebinding protection. ` +
            'Consider using the allowedHosts option...'
    );
}
// Origin: only armed for loopback or explicit allowedOrigins

So createMcpExpressApp({ host: '192.168.1.10' }) or { host: 'mcp.internal' } serves without Host/Origin checks and without the operator nudge that 0.0.0.0 already gets. DNS rebinding / browser-origin abuse is exactly what those middleware exist for on HTTP MCP endpoints.

Suggested change:

• Treat every non-loopback host like 0.0.0.0: require allowedHosts (and ideally allowedOrigins), or at least emit the same warning.
• Or fail closed: refuse to construct the app for non-loopback binds unless allowlists are provided.
• Keep the explicit opt-out path for demos that truly need an open bind.

Severity: medium as insecure default / defense-in-depth for non-loopback HTTP mounts; not claiming a working exploit against a specific deployment. No proof-of-concept.

Happy to send a focused PR if this direction is useful.