Description

FrontMCP is a TypeScript-first framework for the Model Context Protocol (MCP). From mcp-from-openapi 2.3.0 until 2.5.0 and from frontmcp and @frontmcp/adapters 1.2.1 until 1.5.0, libs/adapters/src/openapi/openapi.adapter.ts loadOpenAPISpec() forwards untrusted OpenAPI url and spec inputs and loadOptions.refResolution to OpenAPIToolGenerator.fromURL() and OpenAPIToolGenerator.fromJSON(). The external $ref guard checks parsed hostname strings without resolving addresses, pinning validated addresses, revalidating redirect targets, or normalizing IPv4-mapped IPv6. An authenticated user who can import or configure an OpenAPI specification in a hosted or multi-user deployment can use DNS-to-loopback resolution, redirect-to-loopback behavior, or IPv4-mapped IPv6 loopback forms to cause backend-origin requests to internal services. This can expose internal administrative APIs, metadata-like services, and other private network endpoints. The practical impact is lower when only a trusted local administrator can configure OpenAPI specs, and disabling external reference protocols prevents the external $ref request. This issue is fixed in mcp-from-openapi 2.5.0 and frontmcp and @frontmcp/adapters 1.5.0.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.5",
  "pubDate": "2026-09-15T16:17:18.327Z",
  "pubdate": "2026-09-15T16:17:18.327Z",
  "executiveSummary": "A Server-Side Request Forgery (SSRF) vulnerability exists in FrontMCP, mcp-from-openapi, and @frontmcp/adapters due to insufficient validation of OpenAPI specification references.\nThe vulnerability allows authenticated users in multi-user or hosted environments to force the backend to perform unauthorized requests to internal services, metadata endpoints, or administrative APIs.\nThe root cause involves inadequate sanitization of untrusted URLs and $ref inputs passed to the OpenAPIToolGenerator component. The existing guard mechanism fails to account for DNS-to-loopback resolution, malicious HTTP redirects, and IPv4-mapped IPv6 address variations.\nAn attacker requires authenticated access to configure or import an OpenAPI specification to initiate the attack. By manipulating the input, the attacker bypasses host-based filtering, enabling interaction with services otherwise unreachable from the public internet.\nThis flaw presents significant security risks in cloud or multi-tenant deployments, potentially leading to unauthorized data exposure, interaction with internal control planes, and internal service reconnaissance. The vulnerability is mitigated by upgrading the affected libraries to the specified versions.",
  "technicalDetails": "The vulnerability resides within libs/adapters/src/openapi/openapi.adapter.ts, specifically inside the loadOpenAPISpec() function. This function serves as an entry point for processing OpenAPI specifications, accepting user-provided URLs or JSON payloads, alongside loadOptions.refResolution settings.\nThe primary mechanism of exploitation involves passing these inputs to OpenAPIToolGenerator.fromURL() or OpenAPIToolGenerator.fromJSON(). The application attempts to guard against external $ref references, but the implemented validation logic is critically flawed. It only inspects the literal hostname string without performing active resolution, address pinning, or stateful validation of redirect targets.\nThe vulnerability manifests through several bypass techniques: DNS-to-loopback resolution, where a domain resolves to 127.0.0.1; HTTP redirect-to-loopback, where a seemingly external resource redirects to an internal address; and the use of IPv4-mapped IPv6 addresses (e.g., ::ffff:7f00:1) to obfuscate the destination loopback address.\nThe attack flow begins when an authenticated user supplies a malicious OpenAPI specification containing an external $ref or URL pointing to an internal network target. Because the application logic fails to resolve the target address to its actual endpoint before making the outbound request, the backend library (OpenAPIToolGenerator) proceeds to fetch the resource.\nDuring the request phase, the system executes the fetch operation on behalf of the backend server. The lack of normalization for IPv6 loopback variants and the failure to revalidate targets following 3xx redirects allow the request to bypass the filter and terminate at internal endpoints. This effectively grants the attacker the ability to make authenticated, server-side HTTP requests against internal infrastructure that is typically protected by network boundaries or lack of public exposure.\nAffected versions include mcp-from-openapi (2.3.0 to 2.5.0), frontmcp (1.2.1 to 1.5.0), and @frontmcp/adapters (1.2.1 to 1.5.0). The vulnerability remains potent in scenarios where users are permitted to import arbitrary specifications, as the backend server acts as a proxy for the request, fulfilling the SSRF chain.\nPost-exploitation, an attacker can enumerate internal metadata services (common in cloud environments), probe internal administrative ports, or interact with private network services, potentially leading to privilege escalation or further information disclosure depending on the target environment."
}