OAuth debugger SSRF guard blocks intranet MCP servers on CGNAT (100.64/10) — no opt-out for self-hosted use

[anengineerdude]

Summary

The OAuth debugger's backend proxy (/api/mcp/oauth/debug/proxy) refuses to send requests to MCP servers whose hostname resolves into 100.64.0.0/10 (CGNAT / RFC 6598 shared address space). The SSRF guard in sdk/src/oauth/ssrf-guard.ts classifies that range as disallowed:

if (a === 100 && b >= 64 && b <= 127) return true; // 100.64/10 CGNAT

Every OAuth debugger step then fails at request_without_token with Backend debug proxy error: 400 Bad Request — before any request reaches the server, so from the user's perspective a perfectly healthy server "fails OAuth" with no actionable detail.

Why this matters

Self-hosted Inspector on a corporate network is exactly the environment where an internal MCP server lives behind a load-balancer VIP in shared address space. The server in our case returns a spec-correct 401 + WWW-Authenticate: Bearer resource_metadata=... challenge (verified with curl byte-for-byte against the debugger's request), and other clients (Claude Code, Open WebUI) complete the full OAuth flow against it. Only the Inspector's guarded proxy path is unable to test it.

The SSRF guard is entirely reasonable for the hosted product; for a locally-run Inspector pointed at intranet infrastructure it blocks the primary use case.

Repro

1. Run the Inspector locally (localhost:6274).
2. Add an HTTP MCP server whose DNS resolves to an address in 100.64.0.0/10 (OAuth-protected, returns a standard 401 challenge).
3. Open the OAuth debugger and start the flow.
4. First step fails: Backend debug proxy error: 400 Bad Request; the server never receives a request.

Ask

An explicit opt-out for self-hosted/local mode — e.g. an env var like MCPJAM_ALLOW_PRIVATE_TARGETS=1 (or a per-server "trust this private host" toggle in the UI) that relaxes the SSRF guard for the debug proxy when the Inspector is not running in hosted mode. Even limiting the exemption to 100.64/10 + RFC 1918 while keeping loopback/link-local rules intact would cover the corporate-intranet case.

Happy to test a patch against our environment.

[dosubot]

Hi @anengineerdude! I'm Dosu and I'm helping the MCPJam team.

Your analysis is spot-on. The SSRF guard in ssrf-guard.ts explicitly blocks 100.64.0.0/10, and there is currently no env var, config flag, or UI toggle to relax it for non-loopback private ranges.

Here's the lay of the land:

• The only existing relaxation is allowLoopbackMetadataFetch, which auto-enables when the server URL itself is loopback (127.0.0.0/8, ::1, localhost) [1]. It intentionally never covers LAN, CGNAT, or link-local ranges [2].
• The codebase already distinguishes hosted vs. local contexts via httpsOnly / httpsOnlyProxy flags — the local MCP routes set httpsOnly: false to allow plain-HTTP loopback targets [3], while the hosted web routes enforce HTTPS [4]. An env-var-gated private-IP allowance could follow a similar pattern.
• The guard is applied uniformly at the OAuth state-machine factory level, wrapping all request executors [5], so any bypass would need to flow through the options bag that already carries allowLoopbackMetadataFetch.

No existing issues or PRs track this request, so this is the first time it's been raised.

The approach you suggest (an env var like MCPJAM_ALLOW_PRIVATE_TARGETS=1 that extends the allowance to RFC 1918 + CGNAT while keeping loopback/link-local rules intact) seems well-aligned with how the codebase already handles the hosted-vs-local distinction. The plumbing to thread it through would be: env var → server config (env.ts) → route handler → executeDebugOAuthProxy options → assertOutboundOAuthUrlAllowed.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[ignaciojimenezr]

Hey @anengineerdude, sorry for the late reply. We're looking to this and will give you updates shortly.