Add support for host allowlisting to Fetch server

[olaservo]

Is your feature request related to a problem? Please describe.
The fetch MCP server currently allows connections to local/internal IP addresses without any restrictions, which poses a security risk. While the README has been updated with a caution notice, this reference implementation could be misused if deployed without proper safeguards.

Describe the solution you'd like
Implement a host allowlisting mechanism for the fetch server that would:

• Allow administrators to specify which hosts/domains the server can connect to
• By default, block connections to local/internal IP ranges (127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, etc.)
• Provide configuration options to explicitly allow internal IPs if needed for specific use cases
• Implement checks at the socket level to avoid TOCTOU (Time-of-Check-Time-of-Use) vulnerabilities

Describe alternatives you've considered

• Leave as-is with documentation only: Continue with just the warning in the README, but this leaves the reference implementation vulnerable and sets a poor security example

Additional context

• Consider adding example configurations to the Readme showing secure deployment patterns.

[olaservo]

cc @dend @jenn-newton

[olaservo]

@claude lets implement this feature for the Fetch server.

[claude]

Claude finished @olaservo's task —— View job • claude/issue-2317-20250817-1707 • Create PR ➔

---

Implementation Complete ✅

I've successfully implemented the host allowlisting feature for the Fetch server to address the security concerns in issue #2317.

Changes Made

Security Features Implemented:

• Default IP Blocking: Blocks access to local/internal IP ranges by default (127.0.0.0/8, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, link-local, multicast, IPv6 equivalents)
• Host Allowlisting: --allowed-hosts argument supports exact domains and wildcards (*.example.com)
• Development Override: --allow-private-ips flag allows internal IPs when needed
• Custom IP Restrictions: --blocked-ip-ranges for additional CIDR blocks
• TOCTOU Prevention: Socket-level hostname resolution validates IPs before connection

Files Modified:

• src/fetch/src/mcp_server_fetch/server.py: Added IP validation, hostname resolution, and allowlist logic
• src/fetch/src/mcp_server_fetch/__init__.py: Added new command-line arguments
• src/fetch/README.md: Updated with security documentation and configuration examples

Configuration Examples:

// Allow specific domains only
{
  "mcpServers": {
    "fetch": {
      "command": "uvx",
      "args": ["mcp-server-fetch", "--allowed-hosts", "example.com", "*.github.com"]
    }
  }
}

Testing: All IP validation logic verified with comprehensive test cases covering IPv4/IPv6 ranges.

Todo List:

• Read repository structure and CLAUDE.md guidelines
• Locate and analyze existing Fetch server implementation
• Design host allowlisting architecture
• Implement IP range validation and blocking
• Add configuration options for allowlisting
• Implement socket-level checks to avoid TOCTOU vulnerabilities
• Update documentation and README
• Test the implementation
• Commit and push changes

[domdomegg]

Will flag that I think many people (myself included) use the fetch MCP intentionally to hit local endpoints, e.g. for testing out servers on localhost while developing. I don't know what others expect, but changing the default could be a surprise for many people.

[olaservo]

@domdomegg I think thats a good point. If we were doing this from scratch I think that we would offer some kind of 'use dangerously' flag that could get set by the user, vs defaulting to the more open behavior? But I agree that breaking the existing behavior will be disruptive. I think the question is whether we think the disruption is worth the benefit. @jenn-newton @dend what do you think?

[yakuphanycl]

External MCP audit corroborates this gap.

We ran the mcp-audit skill against mcp-server-fetch@0.6.3 on 2026-04-26. The audit confirms the SSRF posture this issue tracks:

• Current state: tool fetches arbitrary URLs with no IP filter, no host allowlist, no --allowed-hosts runtime guard. README [!CAUTION] block warns operators at install time.
• Severity per the audit's framework: SEC-004 (default High) → de-escalated to Low because this is a maintainer-tracked, documented limitation, not a fresh discovery.
• Reference: full case-study at yakuphanycl/wrg-skills/docs/case-studies/fetch-mcp-2026-04-26.md (PR pending merge).

We noted the unmerged branch claude/issue-2317-20250817-1707 (commit a1226d4) which already implements --allowed-hosts, CIDR blocking for private ranges, --allow-private-ips opt-out, and --blocked-ip-ranges. If the reasons it didn't land are addressable, we'd be glad to rebase it onto current main and open a fresh PR. If there's a design reason it shouldn't land in that shape, a pointer to the discussion would help us file the right alternative.

No urgency from our side — this issue's enhancement label matches our severity assessment.

[g-yixuan]

I'd like to pick this up and prepare a fresh PR (with a current base, per the note on #2568).

Design proposal — feedback welcome:

Scope: opt-in host allowlisting only, no change to default behavior.

• New --allowed-hosts HOST [HOST ...] CLI flag. When unset, behavior is exactly as today (all hosts allowed), so users who intentionally fetch localhost/internal endpoints (@domdomegg's point) are unaffected.
• When set, the fetch tool only connects to listed hosts:
  • exact match, case-insensitive: example.com
  • wildcard: *.example.com matches example.com itself and any subdomain
  • IP literals match literally
• Enforced on the initial request and every redirect hop (switching from follow_redirects=True to a bounded manual redirect loop), and on the robots.txt pre-check — so the allowlist can't be bypassed via a 302 from an allowed host.
• Fail-closed with a clear error message that does not echo the configured allowlist.

What I'm deliberately not including:

• Blocking private/loopback IP ranges by default — that's the behavior change still under discussion here, and it's separately proposed in fix(fetch): block SSRF to internal/metadata IPs by default #4497. This PR is designed to compose cleanly with it (--allowed-hosts for an explicit allowlist; fix(fetch): block SSRF to internal/metadata IPs by default #4497's posture for default-deny). It also differs from the stale Add host allowlisting and IP blocking to Fetch server #2568, which changed defaults.

On the TOCTOU bullet: with a hostname allowlist, the validated hostname is exactly what gets connected (SNI/Host), so DNS check-time/connect-time skew does not weaken the control; per-hop re-validation closes the redirect bypass, which is the realistic escalation path.

Will include full unit tests (exact/wildcard/IP matching, redirect-hop enforcement, robots.txt path, unset-flag regression) plus README examples of secure configuration.