FrontMCP OpenAPI $ref SSRF via Insufficient Loopback/Redirect Validation

Technical Analysis

The vulnerability lives in loadOpenAPISpec() within openapi.adapter.ts, which passes untrusted url, spec, and refResolution parameters into OpenAPIToolGenerator.fromURL()/fromJSON() to resolve external $ref references while generating MCP tools from an OpenAPI specification. The hostname-based guard only inspects the parsed hostname string and does not resolve it to an IP address, pin the validated address for the actual outbound request, revalidate redirect targets, or normalize IPv4-mapped IPv6 loopback representations (e.g., ::ffff:127.0.0.1). This allows DNS-to-loopback resolution tricks, HTTP redirect chains that land on loopback/internal addresses, or crafted IPv6 loopback encodings to bypass the filter and cause the MCP server backend to issue requests to internal-only endpoints. Because the MCP tool-generation pipeline executes with the server's network privileges, an attacker with only OpenAPI-import/configuration rights can pivot from a benign-looking tool-authoring workflow into an SSRF primitive that reaches admin APIs, metadata services, or other agents/services on the internal network.

Affected Systems

frontmcp, @frontmcp/adapters, mcp-from-openapi; protocols: MCP

Detection Signatures

• Outbound HTTP/HTTPS requests from MCP server processes to loopback or link-local/private ranges (127.0.0.0/8, 169.254.169.254, ::1, ::ffff:127.0.0.1) immediately following OpenAPI spec import
• OpenAPI $ref fields containing raw IP literals, IPv4-mapped IPv6 addresses, or DNS names known to resolve to loopback/internal addresses
• Redirect responses (3xx) during $ref resolution that change the resolved host/IP from the originally validated hostname
• Logs showing OpenAPIToolGenerator.fromURL/fromJSON invoked with attacker-supplied spec URLs shortly before internal service errors or unexpected internal API calls
• Repeated DNS queries for a single external hostname resolving to different (rebound) IP addresses around the time of spec import

Remediation Steps

1. 1

   Upgrade affected packages

   Update to mcp-from-openapi 2.5.0 or frontmcp/@frontmcp/adapters 1.5.0 or later, which contain the fix for the $ref SSRF guard.

2. 2

   Resolve-then-pin validation

   Ensure any $ref/URL resolution logic resolves hostnames to IP addresses first, validates the resolved address (blocking loopback, link-local, private, and IPv4-mapped IPv6 ranges), and pins that exact address for the outbound connection to prevent DNS rebinding.

3. 3

   Revalidate redirects

   Disable automatic HTTP redirect following for $ref resolution, or re-run full address validation against each redirect target before following it.

4. 4

   Restrict OpenAPI import privileges

   Limit who can import or configure OpenAPI specs to trusted administrators in multi-tenant/hosted deployments, since the practical impact is significantly reduced when only trusted operators can supply specs.

5. 5

   Disable external $ref resolution where unnecessary

   Configure loadOptions.refResolution to disallow external references unless explicitly required, eliminating the network request vector entirely.

6. 6

   Network segmentation

   Place MCP server backends in a network segment without direct access to sensitive internal admin APIs and cloud metadata endpoints, and enforce egress filtering.