MCP get-html-skeleton Tool SSRF to Cloud Metadata Exposure

Technical Analysis

The get-html-skeleton tool accepted a caller-supplied URL and passed it to isValidHttpUrl, which only checked for an http/https scheme and valid URL parsing, performing no hostname or IP-range allowlist/denylist checks. This let attackers submit URLs pointing to loopback, link-local, or private IP ranges, notably the well-known cloud metadata address, which the tool's web-browser actor would then fetch on the server's behalf. The fetched response, potentially containing IAM role credentials or other instance metadata, was returned directly in the tool's output to the calling agent or user. This is a classic Server-Side Request Forgery (SSRF) vulnerability exposed through an agentic tool boundary: any entity with access to invoke the MCP tool (including an LLM agent manipulated via prompt injection) gains a network vantage point inside the host's trust boundary, escalating from tool-layer access to infrastructure-level credential theft.

Affected Systems

MCP server (unspecified/generic implementation using src/tools/common/get_html_skeleton.ts); protocols: MCP

Detection Signatures

• Tool requests to URLs resolving to 169.254.169.254 or other link-local/metadata addresses
• Outbound fetch requests from MCP server processes to RFC1918 private ranges or loopback (127.0.0.1, ::1)
• URL validation functions that check only scheme (http/https) without resolving or filtering destination IP
• Tool responses containing metadata service JSON structures (e.g., IAM credential fields) returned to end users
• Log entries showing get-html-skeleton or similar fetch-tool calls with non-public-facing target hosts

Remediation Steps

1. 1

   Upgrade to patched version

   Update the MCP server package to version 0.9.12 or later, which removes the vulnerable tool.

2. 2

   Implement robust SSRF protections

   Validate not just URL scheme but also resolve the hostname and block requests to loopback, link-local, private (RFC1918), and cloud metadata IP ranges before any outbound fetch is performed.

3. 3

   Enforce network-layer egress controls

   Use network policies, firewalls, or a proxy allowlist to block MCP server or agent processes from reaching internal metadata endpoints and private address space regardless of application-layer checks.

4. 4

   Disable IMDSv1 / require token-bound metadata access

   Where running on cloud infrastructure, enforce IMDSv2 or equivalent token-based metadata access to reduce SSRF impact even if a request reaches the metadata service.

5. 5

   Audit and restrict tool capabilities

   Review all MCP tools that perform outbound network fetches on behalf of callers, apply least-privilege network access, and require explicit destination allowlisting for such tools.