SSRF Bypass in FrontMCP and mcp-from-openapi OpenAPI Import (CVE-2026-59973)

What happened

The OpenAPI adapter in FrontMCP (libs/adapters/src/openapi/openapi.adapter.ts) forwards untrusted OpenAPI url and spec inputs, along with a loadOptions.refResolution setting, to the OpenAPIToolGenerator's fromURL() and fromJSON() functions. The guard intended to block external $ref references to unsafe destinations checks only parsed hostname strings. It does not resolve the actual network address behind a hostname, does not pin the address it validated for subsequent use, does not revalidate redirect targets, and does not normalize IPv4-mapped IPv6 address forms. This combination allows the hostname-based check to be bypassed.

Technical cause

Because validation is based on string-level hostname inspection rather than resolved and pinned network addresses, several bypass techniques are possible: using DNS names that resolve to loopback addresses, using HTTP redirects that point to loopback addresses after the initial hostname check passes, and using IPv4-mapped IPv6 representations of loopback addresses that are not recognized as equivalent to the blocked forms. This is classified as CWE-918 (Server-Side Request Forgery).

Why it matters

An authenticated user who is permitted to import or configure an OpenAPI specification in a hosted or multi-user deployment can exploit this gap to cause the FrontMCP backend to issue requests to internal network destinations on its behalf. This can expose internal administrative APIs, metadata-like services, and other private network endpoints that are not meant to be reachable from outside the trusted backend network. The CVSS vector indicates a scope change (S:C) and a confidentiality impact of High, reflecting that the request forgery can disclose data from internal services beyond the vulnerable component itself.

Who is affected

Deployments of frontmcp and @frontmcp/adapters versions from 1.2.1 up to but not including 1.5.0 are affected, as are deployments of mcp-from-openapi versions from 2.3.0 up to but not including 2.5.0. The practical impact is reduced in deployments where only a trusted local administrator is able to configure OpenAPI specifications, and in deployments where external reference protocols are disabled, since that configuration prevents the external $ref request from being made in the first place.

Affected versions

frontmcp: versions 1.2.1 up to (but not including) 1.5.0. @frontmcp/adapters: versions 1.2.1 up to (but not including) 1.5.0. mcp-from-openapi: versions 2.3.0 up to (but not including) 2.5.0.

Fixes and mitigation

This issue is fixed in frontmcp and @frontmcp/adapters version 1.5.0, and in mcp-from-openapi version 2.5.0. For deployments that cannot update immediately, restricting who is permitted to import or configure OpenAPI specifications to trusted local administrators reduces exposure, as does disabling external reference protocols, which prevents the vulnerable external $ref request from being issued at all.

Recommended action

Update frontmcp and @frontmcp/adapters to version 1.5.0 or later, and update mcp-from-openapi to version 2.5.0 or later. Until updates are applied, limit OpenAPI specification import/configuration privileges to trusted administrators and consider disabling external reference protocol support in affected deployments.