CVE-2025-65513: Fetch Mcp Server SSRF Vulnerability

CVE-2025-65513 Overview

CVE-2025-65513 is a Server-Side Request Forgery (SSRF) vulnerability affecting fetch-mcp versions 1.0.2 and earlier. The flaw allows attackers to bypass private IP validation and force the Model Context Protocol (MCP) server to send requests to internal network resources. The vulnerability is tracked under CWE-918 and was published to the National Vulnerability Database on December 9, 2025.

Attackers can exploit this issue remotely without authentication or user interaction. Successful exploitation exposes internal services, cloud metadata endpoints, and other resources that should not be reachable from external networks.

Critical Impact

Unauthenticated remote attackers can bypass private IP filtering in fetch-mcp to probe and access internal network resources, including cloud metadata services and internal HTTP APIs.

Affected Products

• zcaceres/fetch_mcp_server version 1.0.2
• zcaceres/fetch_mcp_server all prior releases
• Applications and agent workflows embedding fetch-mcp as an MCP tool

Discovery Timeline

• 2025-12-09 - CVE-2025-65513 published to NVD
• 2026-01-02 - Last updated in NVD database

Technical Details for CVE-2025-65513

Vulnerability Analysis

The fetch-mcp server exposes a Model Context Protocol tool that allows large language model (LLM) agents to fetch URLs on behalf of the user. To prevent abuse, the server implements a private IP validation routine intended to block requests to RFC1918 addresses, loopback addresses, and other reserved ranges.

The validation logic in versions 1.0.2 and earlier is insufficient. Attackers can craft URLs that bypass these checks and resolve to internal addresses at fetch time. The server then issues the outbound HTTP request and returns the response body to the caller.

This SSRF condition turns the MCP server into a proxy into the internal network. In cloud deployments, attackers can reach instance metadata services such as 169.254.169.254 to retrieve temporary credentials. In on-premises environments, attackers can enumerate internal HTTP services and read responses.

Root Cause

The root cause is incomplete validation of user-supplied URLs before issuing outbound requests. The server checks the hostname or initial IP form against a denylist of private ranges but does not consistently re-validate after DNS resolution or URL normalization. Techniques including DNS rebinding, decimal or hexadecimal IP encoding, IPv6 mapped addresses, and redirect chains can defeat the existing filter.

Attack Vector

An attacker with the ability to influence URLs passed to the fetch-mcp server submits a crafted URL through the MCP fetch tool. The server resolves the URL, fails to detect that it points to an internal address, and performs the request. The response is returned to the attacker through the MCP channel. No authentication is required when the MCP server is exposed without access controls.

The vulnerability mechanism is described in the GitHub CVE-2025-65513 Analysis and the Notion Fetch MCP Documentation. No verified proof-of-concept code is published at this time.

Detection Methods for CVE-2025-65513

Indicators of Compromise

• Outbound HTTP requests from the fetch-mcp process to RFC1918 addresses such as 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16
• Requests from the MCP host to cloud metadata endpoints including 169.254.169.254 or metadata.google.internal
• MCP tool invocations containing URLs with encoded IPs, unusual IPv6 forms, or domains that resolve to internal addresses

Detection Strategies

• Inspect MCP server logs for fetch tool calls whose target hostname resolves to a private, loopback, or link-local address
• Correlate DNS resolutions made by the fetch-mcp process with outbound connection destinations to detect rebinding attempts
• Alert on response payloads returned by fetch-mcp that contain markers of cloud credential responses or internal service banners

Monitoring Recommendations

• Forward network flow data and process-level connection telemetry for the host running fetch-mcp to a central analytics platform
• Baseline normal outbound destinations for the MCP server and alert on first-seen internal destinations
• Monitor for unauthenticated access to the MCP server itself and require client authentication for all tool invocations

How to Mitigate CVE-2025-65513

Immediate Actions Required

• Restrict network egress from the fetch-mcp host so it cannot reach internal subnets, loopback, or cloud metadata addresses
• Place the MCP server behind authentication and limit which clients can invoke the fetch tool
• Disable or remove fetch-mcp in environments where the agent does not require external URL fetching

Patch Information

No fixed version is listed in the NVD entry at publication. Operators should monitor the zcaceres/fetch-mcp repository for an updated release that addresses the SSRF validation gap, and review the GitHub CVE-2025-65513 Analysis for ongoing remediation guidance.

Workarounds

• Run fetch-mcp inside a network namespace or container with an egress policy that denies private address ranges and IMDS endpoints
• Front the MCP server with a forward proxy that performs strict URL validation, post-DNS-resolution IP checks, and disallows HTTP redirects to private targets
• Use cloud provider controls such as IMDSv2 with hop-limit enforcement on AWS to reduce the impact of metadata access from SSRF

# Example egress restriction using iptables to block private and metadata targets
iptables -A OUTPUT -m owner --uid-owner fetch-mcp -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner fetch-mcp -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -m owner --uid-owner fetch-mcp -d 192.168.0.0/16 -j REJECT
iptables -A OUTPUT -m owner --uid-owner fetch-mcp -d 169.254.0.0/16 -j REJECT
iptables -A OUTPUT -m owner --uid-owner fetch-mcp -d 127.0.0.0/8 -j REJECT