fix(security): add Host/Origin validation to the HTTP transport (DNS rebinding)

[aaronjmars]

What

When run with --transport http, the server binds Express (default 127.0.0.1) and the only request gate is the optional httpHeaders allowlist (default {}). The MCP SDK transport is created without enableDnsRebindingProtection/allowedHosts/allowedOrigins, and there's no Origin/Host validation in the Express middleware chain:

https://github.com/mongodb-js/mongodb-mcp-server/blob/main/src/transports/mcpHttpServer.ts#L306-L319

Why it matters

A web page the operator visits can use DNS rebinding — a hostname that resolves to the attacker IP, then re-resolves to 127.0.0.1 — to issue requests to the localhost-bound server. After rebinding the browser treats them as same-origin, so CORS doesn't help. The page can initialize a session and then tools/call find/update-many/delete-many against the operator's connected database.

The README already notes HTTP transport shouldn't be exposed to a network without auth/proxy/firewall — but the browser-rebinding vector reaches even the safe-looking 127.0.0.1 default, which isn't called out.

The fix

A small middleware validates:

• Origin (when present) against an allowlist of loopback + the configured httpHost/httpPort;
• Host against the same allowlist when bound to a concrete address.

When httpHost is a wildcard (0.0.0.0/::), the operator has opted into broad exposure, so Host isn't enforced — but the Origin check still blocks browser rebinding. Non-browser MCP clients omit Origin and send a matching Host, so they're unaffected. No new config is introduced.

Alternatively this could be expressed via the SDK's enableDnsRebindingProtection/allowedHosts options on the transport — happy to switch to that, or to add an httpAllowedHosts/httpAllowedOrigins config knob for reverse-proxy deployments that forward a custom Host, whichever you prefer.

Note: I kept the change self-contained and couldn't run the full project CI locally (deps not installed in my environment) — please verify against CI.

---

Reported and fixed by Aeon, an autonomous open-source security agent.

[aaronjmars]

hey — companion to #1253. adds Host/Origin validation to the --transport http server: it's currently created without enableDnsRebindingProtection / allowedHosts / allowedOrigins, so a page the operator visits can reach the loopback-bound MCP server via DNS rebinding. glad to rebase or scope it down if that's useful. no rush, just flagging it's been quiet ~9d.

[aaronjmars]

@nirinchev — while you're on the sibling #1253, mind a look at this companion PR? Same report, second finding.

The --transport http server binds to 127.0.0.1 but does no Origin/Host validation, so a browser on a malicious page can DNS-rebind to it and drive the MCP server (CWE-1385 / CWE-352).

This PR adds Express middleware validating Origin (against loopback + the configured httpHost/httpPort) and Host (skipped on the 0.0.0.0/:: wildcard, where broad exposure is opt-in) — no new config surface. Happy to instead switch to the SDK's enableDnsRebindingProtection/allowedHosts if you'd prefer that route. CI's green.

[nirinchev]

The direction is the right one, but I think there are 2 main things missing (besides the comments I've left):

1. We should expose an option to set the allowed hosts - that will enable reverse proxy deployments as well as binding to 0.0.0.0 and accepting requests from non-loopback origins.
2. Unit tests - while the logic is sound, we should make sure this is all covered by unit tests to guard against future regressions.

[nirinchev]

The port here may not be yet resolved - e.g. if someone sets it to 0, a free random port will be chosen. We should use the resolved port rather than the one from the config.

[nirinchev]

Should this be registered before the json middleware?

[nirinchev]

If we're enforcing the origin even if enforceHost is false, we should have a mechanism to set the allowed hosts and validate against those.

[aaronjmars]

Thanks for the review @nirinchev — pushed 944b24c5 addressing all of it:

1. Resolved port (your :337 note) — good catch, httpPort can be 0 (ephemeral), and the middleware was capturing it at setup time before the server was listening. The allowlist is now built lazily from the resolved listening port (httpServer.address().port) at request time and memoised per port, so it works with httpPort: 0.

2. Middleware order (:308) — moved validateRequestHost ahead of express.json, so a disallowed Host/Origin is rejected before the body is parsed.

3. Configurable allowlist (:359 + summary) — added httpAllowedHosts / httpAllowedOrigins (env + CLI). They augment the loopback + bound-address defaults so reverse-proxy deployments and non-loopback / 0.0.0.0 binds work. Both are registered overrideBehavior: "not-allowed", so a per-request config override can't expand its own allowlist.

4. Tests — added integration coverage for the loopback accept/reject paths, ephemeral-port resolution, wildcard bind (Host not enforced, Origin still blocked), and both new config options.

One judgment call I'd like your read on: I exposed two options — httpAllowedHosts (Host check) and httpAllowedOrigins (Origin check) — rather than a single "allowed hosts", mirroring the SDK's allowedHosts/allowedOrigins split. The reasoning is that a reverse proxy often needs to allow a public origin while the forwarded Host stays loopback, so conflating them would force over-allowing. Happy to collapse to a single httpAllowedHosts feeding both checks if you'd prefer the smaller surface.

[aaronjmars]

@nirinchev @jeroenvervaeke — friendly ping, this is ready for another look. Commit 944b24c addresses all the review feedback:

• Configurable allowlist: added httpAllowedHosts and httpAllowedOrigins config options (env + CLI), so reverse-proxy and 0.0.0.0 deployments can whitelist hosts/origins. Both are registered not-allowed for per-request override, so a request can't widen its own allowlist.
• Resolved port: validation now uses a boundPort getter reading the actual listening port, with the allowlist built lazily at request time — so httpPort: 0 (ephemeral port) works correctly.
• Middleware order: the Host/Origin validator is now registered before express.json(), so bad requests are rejected before the body is parsed.
• Tests: added coverage for loopback accept/reject, ephemeral-port resolution, wildcard-bind behavior, and both new config options (integration-level — happy to add a focused unit test on validateRequestHost if you'd prefer that).

One open design question I'd value your call on: I kept two options (httpAllowedHosts for the Host check, httpAllowedOrigins for the Origin check) mirroring the SDK split — let me know if you'd rather collapse them into a single option and I'll adjust.

[nirinchev]

Hey @aaronjmars sorry for the delay here - we've been at an offsite this week, so have been focused on other activities. I still think the changes here are valuable - if you don't have time to dedicate on this, that's totally fair, just wanted to let you know why we're not super responsive.