Skip to content

Fix MCP Host validation with --unsafe-http - #40

Merged
dmaivel merged 1 commit into
dmaivel:masterfrom
bluecmd:codex/fix-unsafe-http-host-check
Oct 23, 2026
Merged

dmaivel merged 1 commit into
dmaivel:masterfrom
bluecmd:codex/fix-unsafe-http-host-check

Conversation

@bluecmd

@bluecmd bluecmd commented Oct 23, 2026

Copy link
Copy Markdown
Contributor

Requests to MCP using a network IP or hostname receive HTTP 403 even with --unsafe-http, because the router always installs the loopback Host middleware.

Apply that middleware only when unsafe_http is false, consistent with the existing bind and CORS policies. Extract router construction so a regression test exercises the actual MCP route for localhost, a remote IP, and a DNS hostname under both policies. The test checks that permitted requests reach rmcp's Accept-header validation, while disallowed hosts still receive 403.

Closes #39.

Validation:

  • cargo fmt --all --check
  • git diff --check
  • cargo test --locked --no-default-features --features cli,mcp --lib hosts::mcp::tests — 14 passed.

An initial MCP-only build (--features mcp) encountered an existing missing thread_label import in src/hosts/repl/mod.rs; validation used CLI + MCP instead.

@dmaivel
dmaivel merged commit 79abc39 into dmaivel:master Oct 23, 2026
21 checks passed
dmaivel added a commit that referenced this pull request Oct 23, 2026
…t policy

Follow-up to #40, which answers requests addressed to any host under
`--unsafe-http`:

- CHANGELOG: a Fixed line. The loopback Host check shipped in v0.49.1,
  so the server has been out of the network's reach since.
- `--unsafe-http`'s help and docs/integrations/mcp.md say it also lifts
  the Host check, besides the bind address and browser origins.
- The test sent a bare GET and expected rmcp's 406 for its missing
  Accept header, which pins an rmcp detail rather than the Host policy.
  It now sends a valid initialize and expects the session to open (200)
  for a permitted host, 403 otherwise. With the middleware applied
  unconditionally again, it fails on the first --unsafe-http host.

Checked live: with --unsafe-http on 0.0.0.0, an initialize to the LAN
address and to a DNS name gets 200 (403 before #40); on the default
loopback bind, those Host headers still get 403.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

MCP: --unsafe-http still rejects non-loopback Host headers

2 participants