FrontMCP SSRF patch bypassed via DNS tricks and redirects

A GitHub security advisory published on 11 September 2026 says the patch for an earlier server-side request forgery flaw in the npm package mcp-from-openapi can be bypassed, leaving FrontMCP deployments open to backend-origin requests against internal services. The advisory, tracked as GHSA-65h7-9wrw-629c and CVE-2026-59973, covers the npm packages mcp-from-openapi, @frontmcp/adapters and frontmcp.

Server-side request forgery, or SSRF, is where an attacker tricks a server into making network requests on their behalf, often to systems that are not reachable from the outside. According to the advisory, the earlier fix for GHSA-v6ph-xcq9-qxxj and CVE-2026-39885 added a denylist of hostnames for OpenAPI external $ref dereferencing. An external $ref is a pointer inside an OpenAPI document that tells the loader to fetch part of the schema from another URL.

The advisory says that denylist only inspects the hostname string in the URL. It does not resolve hostnames before allowing or denying a request, does not pin the checked address to the actual connection, does not recheck redirect targets before following them, and does not normalise IPv4-mapped IPv6 addresses. As a result, several URL forms that point at the same loopback address are accepted.

The reporter lists the working forms: a DNS name that resolves to 127.0.0.1, such as a nip.io address; the same name serving a redirect to a direct loopback URL; and IPv4-mapped IPv6 addresses written in both dotted and hexadecimal form. A proof-of-concept run recorded on 25 May 2026 shows a direct loopback $ref being blocked with zero hits on a local canary server, while each of the equivalent forms produced one or two recorded requests.

According to the advisory, FrontMCP release v1.2.1 and the current main branch both still depend on mcp-from-openapi 2.3.0, the latest published version, and both still forward untrusted URL, spec and ref-resolution options into the OpenAPI tool generator. The adapter calls the generator's fromURL and fromJSON methods when loading OpenAPI adapters. The reporter adds that fromURL remains unguarded for the initial spec URL as well, though the main report concerns the external $ref path.

The advisory frames the risk as dependent on deployment. If only a local administrator can configure OpenAPI specs, it says, practical severity is lower. If authenticated but untrusted users can import or configure specs in a hosted or multi-user FrontMCP deployment, it describes the issue as a high-impact fix bypass that could expose internal admin APIs, metadata-like services and other endpoints external users cannot reach.

The advisory notes one mitigation that works today: setting refResolution.allowedProtocols to an empty list stops the external request, but this is not the default. Its longer remediation list asks maintainers to stop relying on hostname string checks, resolve names before requesting, reject loopback, private, link-local, multicast, unspecified and metadata ranges, normalise IPv4-mapped IPv6 addresses, revalidate or disable redirects, pin the validated IP to the connection, and apply the same protected client to initial spec loads. It also recommends disabling external refs by default for untrusted specs and adding regression tests for each bypass form. The advisory does not record a fixed version.