Repository navigation
CIMD loopback HTTPS exemption is host-string-based, not resolution-aware #2409
Description
Which version line?
v2 — current (@modelcontextprotocol/inspector@latest)
Which client?
All / shared core
Inspector version
2.7.0 (git tag) — static code-review finding, not run locally
Node version
N/A — static code review, no live run performed
Operating system (and browser, for the web client)
N/A — static code review
Transport
Streamable HTTP
MCP server under inspection
N/A — this is a static code-review finding against the 2.7.0 tag source (CIMD/OAuth loopback exemption logic), not a live reproduction against a running MCP server.
Steps to reproduce
Found via static review of the 2.7.0 tag source and its fix history, not a live run.
- The CIMD (client metadata document) fix history shows several rounds hardening "exempt loopback hosts from the CIMD metadata URL HTTPS requirement."
- The exemption appears to match on the literal hostname string rather than on what the hostname actually resolves to.
- A non-loopback hostname that resolves to a loopback address (a /etc/hosts alias, or a public DNS name registered to resolve to 127.0.0.1, e.g. an nip.io/localtest.me-style service) would not be caught by a literal-string check.
I have not built a live DNS-rebinding proof-of-concept against a running Inspector instance; flagging based on the code path and its own fix history, which already treats this exact shape of problem (DNS pointing at loopback) as a real concern elsewhere (see the v1.0.2 release notes).
Expected behavior
A non-loopback-named host that resolves to a loopback address is NOT granted the CIMD metadata URL's HTTPS exemption — the exemption check is resolution-aware, not a literal hostname-string match.
Actual behavior
The exemption (per the fix-history comments in the CIMD/OAuth loopback handling) appears to be a literal hostname-string match, so a non-loopback-named host that resolves to loopback may still slip through — the same class of DNS-rebinding-shaped gap this project has already had to fix once (v1.0.2 release notes).
Suggested fix: add a test asserting a non-loopback-named host that resolves to a loopback address is NOT granted the HTTPS exemption, and confirm the exemption check happens against the resolved address, not the literal string.
Logs, errors, or screenshots
No response
Already prototyped a fix?
No response
Before you submit
- I searched existing issues and this is not a duplicate.
- This is not a security vulnerability report (those go through the private advisory process).
Activity
cliffhall commentedon Sep 18, 2026
Triage: Priority Medium (total 6)
buglabelLabels applied at triage:
v2.Board: #28, Status
Incoming(awaiting maintainer review — no milestone yet).CloneOfAlex commentedon Sep 18, 2026
Closing this — on deeper investigation while preparing a private security report, I found this finding was misattributed to this repository.
The loopback/HTTPS-exemption decision for CIMD/OAuth token endpoints is not implemented in this codebase. It's implemented entirely inside the external
@modelcontextprotocol/clientSDK dependency. This repo'score/auth/insecureTokenEndpoint.tsonly recognizes and classifies the SDK'sInsecureTokenEndpointErrorfor UI display purposes — it doesn't perform the exemption check itself. Its own doc comment says as much: "the exemption list lives in the SDK and takes no options, so widening it has to happen upstream (typescript-sdk#2591)."I also checked whether this repo's own
isLoopbackHost()helper (core/node/hostUrl.ts) was the actual mechanism in play — it isn't. Its only real call site (core/auth/node/runner-oauth-callback.ts) validates the operator's own--callback-url/MCP_OAUTH_CALLBACK_URLconfiguration before binding a local OAuth callback listener (per RFC 8252 §7.3), not a remote/attacker-controlled hostname. So the DNS-rebinding-shaped threat model I described here doesn't apply to that code path either. A test fixture comment (clients/web/src/test/integration/mcp/oauth-cimd-fixture.test.ts) further corroborates that the loopback literals being exempted are "the same three loopback literals the SDK exempts for token endpoints."Net result: there's no host-string-vs-resolution gap to fix in this repository, because this repository doesn't own the exemption logic at all. If this is still a concern, it would need to be reported against
typescript-sdk(@modelcontextprotocol/client) instead, since that's where the exemption list and its matching logic actually live.Apologies for the noise — thank you for the triage, @cliffhall.
docs: address Copilot review round 5 on #2444
docs: add the security-advisory skill and carve advisory drafts out o…