Security: mcp-server-fetch lacks SSRF protection; cloud-hosted agent hosts can leak IAM credentials

[desledishant10]

Summary

Two PyPI-published Python MCP servers — mcp-server-fetch (Anthropic reference) and mcp-server-http-request (community) — accept arbitrary URLs from agent tool calls and pass them to httpx.get() with no scheme allowlist, no host denylist, and no protection against link-local cloud-metadata addresses. On cloud-hosted agent hosts (EC2, GCP, Azure VMs, ECS tasks), an agent coerced via prompt injection into calling these tools with a metadata-service URL will exfiltrate IAM credentials.

The vulnerability is fully mitigated on Amazon Linux 2023 instances launched with default IMDSv2-Required metadata options (the AL2023 default since 2024), but remains exploitable on:

• Instances explicitly configured HttpTokens=optional
• Instances launched from older AMIs (AL2 and earlier)
• GCP and Azure metadata services (different default postures)
• Internal HTTP services reachable from the agent host (RFC 1918 ranges, in-cluster service IPs)

The same root cause — no in-package scheme/host validation — means host-level mitigation is insufficient as defense-in-depth. The fix belongs in the package itself.

Demonstration

Performed against mcp-server-fetch v2025.4.7 on an EC2 t3.micro (Amazon Linux 2023 AMI, region us-east-1) with IMDSv2 set to Optional. Full reproduction runbook: https://github.com/desledishant10/mcp-scan/blob/main/docs/audit-runbook-ec2-ssrf-verification.md

Reproduction in summary:

1. Launch a t3.micro AL2023 instance with any IAM role attached (we used a role with AmazonEC2ReadOnlyAccess).
2. Console → instance → Modify metadata options → IMDSv2: Optional.
3. SSH in; install Python 3.11+ and mcp-server-fetch.
4. Run a 15-line MCP client harness asking fetch to retrieve http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name>/.

Result (redacted): the tool returned the JSON {"Code":"Success", "AccessKeyId":"ASIA****", "SecretAccessKey":"wJal****", "Token":"AQoD****", "Expiration":"..."} — a complete, valid AWS IAM credential triplet. Same outcome expected on mcp-server-http-request because the root cause is identical (we didn't separately verify on EC2 in the same session).

Why this is a class issue, not a single-package issue

The same scanning workflow (run mcp-scan-analyze against the captured tools/list of each package) flags both with MCP-S-009 — "URL-fetching tool with no apparent allowlist" — based solely on the absence of a JSON Schema pattern constraint and the absence of validation keywords in the tool descriptions. Both packages are symptomatic of an ecosystem norm in which MCP server authors model the URL parameter as an unconstrained string and trust the agent to be responsible. That norm is wrong: the threat model for MCP servers explicitly includes adversarially-influenced tool arguments via prompt injection.

Suggested remediation

A small mcp-server-url-safety utility module (or an inline check in each affected package) that:

1. Allowlists http:// and https:// only.
2. Resolves the hostname to its IP and rejects RFC-reserved ranges before making the request:
   • 169.254.0.0/16 (link-local, all cloud-metadata addresses)
   • 127.0.0.0/8, ::1 (loopback)
   • 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 (RFC 1918 private)
   • fc00::/7 (IPv6 ULA)
   • 0.0.0.0/8 (current network)
3. Allows an environment-variable opt-in to a customizable allowlist for users who legitimately need to fetch from internal services.

The opt-in pattern is what mcp-server-fetch's existing --ignore-robots-txt flag models. The default should be safe; users who know what they're doing can opt out explicitly.

Embargo

I'd like to coordinate disclosure with the standard 90-day window. Public release planned for 2026-08-10 unless a fix is in active development, in which case happy to extend. Public release would include this writeup plus the reproduction runbook (no exploit payloads beyond what's already in the public scanner).

I'm happy to test a candidate fix against both packages if you'd like a verification round before release.

Tooling

Findings produced by MCP-Scan, an open-source security scanner for MCP servers and AI agents I'm building as a capstone project. Code and full audit trail: https://github.com/desledishant10/mcp-scan

Contact

Dishant Desle - didesle7@gmail.com

Thanks for taking a look.

[policylayer-dan]

The root-cause fix does belong in the package, but it's worth being clear about the defence-in-depth layers available today while that fix lands.

In-package: scheme allowlist (https only), host denylist covering 169.254.0.0/16, fd00:ec2::254, GCP metadata.google.internal, Azure 168.63.129.16, and RFC 1918 ranges. IMDSv2 enforcement is a useful cloud-level control but not a substitute, as you correctly note for GCP/Azure and older AMIs.

At the agent host: iptables/nftables rules dropping egress to link-local and metadata ranges provide a host-level backstop that survives package upgrades breaking the allowlist.

At the tool-call layer: if you're running agents against MCP servers you don't control, a deny-by-default tool allowlist with scoped credentials per agent means a compromised or coerced fetch tool call can't reach credentials it was never provisioned to use. That enforcement-at-call-time layer is what PolicyLayer provides for multi-server MCP deployments.

The prompt-injection vector you describe is the hardest to close at the package level alone; layered controls are the only realistic posture.