Keep local MCP HTTP servers off browser-reachable networks and validate Host headers
You will confirm your local MCP HTTP servers are not reachable from web pages and that they validate Host headers. This matters because a DNS rebinding flaw in DBHub let malicious websites invoke its database tools from a victim's browser.
Before hardening
- Server binds to all interfaces
- Origin checked only against Host hostname
- readonly flag relied on alone
- Browser pages can reach tools
After hardening
- Server bound to 127.0.0.1 or socket
- Host header checked against allowlist
- Database user has only needed privileges
- Upgraded to @bytebase/dbhub 0.22.6 or later
Why it matters
A local MCP HTTP server listens on a port your browser can reach, so a web page you visit can try to talk to it. DBHub's HTTP transport compared only the Origin hostname to the Host hostname, which did not stop DNS rebinding (CVE-2026-61742 (opens external site)). A malicious website could then invoke its tools from your browser, and SELECT statements calling side-effecting database functions could still write or execute commands. Setting readonly = true on execute_sql also left the database-level read-only setting unpopulated, relying only on a first-keyword check (CVE-2026-61788 (opens external site)).
Steps
- List every MCP server you run over HTTP rather than stdio, and note the host and port each one binds to.
- Bind local servers to 127.0.0.1 or a Unix socket instead of all interfaces, so other machines on your network cannot reach them.
- Check that the server validates the Host header against an allowlist of names you expect, such as localhost and 127.0.0.1, and rejects anything else.
- Do not rely on an Origin-versus-Host comparison alone. Treat it as one layer, because a rebinding attack can make both headers look local.
- If you use DBHub, upgrade @bytebase/dbhub to 0.22.6 or later. DNS rebinding protection was fixed in 0.22.5 and read-only enforcement in 0.22.6 (advisory (opens external site)).
- Do not treat a readonly flag in the tool config as your only database protection. Use a database user with only the privileges the tools need, so a SELECT cannot call functions that write.
- Test from a browser: load a page on a different hostname that resolves to your machine and confirm the request is rejected.
Common mistakes
- Binding to 0.0.0.0 for convenience and assuming a firewall will cover it.
- Trusting a read-only flag in the tool config without checking database permissions.
- Skipping the upgrade because the server only runs on your laptop, since browsers can reach localhost too.
- Allowing any Host value because the client connects from localhost.
Checklist
0 of 8 done