CVE-2026-59973: 
JavaScript vulnerability analysis and mitigation

CVE-2026-59973 is a Server-Side Request Forgery (SSRF) fix bypass affecting FrontMCP and its dependency mcp-from-openapi, classified as High severity with a CVSS v3.1 score of 8.5. It bypasses the previously published fix for GHSA-v6ph-xcq9-qxxj / CVE-2026-39885, which added a hostname denylist for OpenAPI external $ref dereferencing. The vulnerability affects frontmcp and @frontmcp/adapters versions >= 1.2.1 and < 1.5.0, and mcp-from-openapi versions >= 2.3.0 and < 2.5.0. It was originally published on June 22, 2026, and added to the GitHub Advisory Database on September 11, 2026 (GitHub Advisory).

The root cause is CWE-918 (Server-Side Request Forgery), stemming from an incomplete denylist implementation in mcp-from-openapi 2.3.0's external $ref HTTP resolver. The guard checks the parsed URL hostname string against deny patterns but does not resolve hostnames to IPs before making allow/deny decisions, does not pin the validated IP to the actual fetch, does not revalidate redirect targets, and fails to normalize IPv4-mapped IPv6 addresses. As a result, three bypass techniques are confirmed: (1) DNS-based loopback via hostnames like 127.0.0.1.nip.io that resolve to 127.0.0.1; (2) open redirect chains where an allowed host redirects to a loopback address; and (3) IPv4-mapped IPv6 syntax such as [::ffff:127.0.0.1] or [::ffff:7f00:1]. FrontMCP's openapi.adapter.ts forwards untrusted url, spec, and loadOptions.refResolution directly into OpenAPIToolGenerator.fromURL() and OpenAPIToolGenerator.fromJSON(), and fromURL() itself remains unguarded for the initial spec load (GitHub Advisory, FrontMCP Advisory).

Successful exploitation allows an authenticated attacker with low privileges to trigger backend-origin HTTP requests from the FrontMCP server to loopback addresses or private network services during OpenAPI tool generation. This can expose internal admin APIs, cloud metadata services (e.g., AWS IMDSv1), and other internal endpoints that are inaccessible to external users, resulting in high confidentiality impact and low integrity impact. The practical severity is highest in hosted or multi-user FrontMCP deployments where untrusted authenticated users can import or configure OpenAPI specs; deployments restricted to trusted administrators face lower risk (GitHub Advisory).

A proof-of-concept (PoC) script (repro-frontmcp-latest-ssrf-bypasses.mjs) was developed and confirmed working against mcp-from-openapi 2.3.0 as of May 25, 2026, demonstrating successful loopback canary hits via DNS-to-loopback, redirect-to-loopback, and IPv4-mapped IPv6 bypass techniques. No in-the-wild exploitation or threat actor attribution has been reported. The CVE status is listed as Reserved, and no EPSS score or CISA KEV catalog entry is currently available (GitHub Advisory, FrontMCP Advisory).

1. Identify a vulnerable deployment: Locate a hosted or multi-user FrontMCP instance running frontmcp/@frontmcp/adapters >= 1.2.1 and < 1.5.0 with mcp-from-openapi >= 2.3.0 and < 2.5.0 that allows authenticated users to import or configure OpenAPI specs.
2. Craft a malicious OpenAPI spec: Create an OpenAPI JSON/YAML document containing an external $ref pointing to a loopback bypass URL. Example bypass payloads:
   • DNS-to-loopback: http://127.0.0.1.nip.io:<port>/schema.json
   • Redirect-to-loopback: http://127.0.0.1.nip.io:<port>/redirect (where /redirect issues a 302 to http://127.0.0.1:<port>/schema.json)
   • IPv4-mapped IPv6: http://[::ffff:127.0.0.1]:<port>/schema.json or http://[::ffff:7f00:1]:<port>/schema.json
3. Load the spec into FrontMCP: Submit the malicious OpenAPI spec via the adapter configuration interface (e.g., setting url or spec in the OpenAPI adapter options), triggering loadOpenAPISpec() which calls OpenAPIToolGenerator.fromURL() or OpenAPIToolGenerator.fromJSON().
4. Trigger SSRF: During tool generation, mcp-from-openapi 2.3.0's resolver fetches the external $ref, bypassing the hostname denylist and issuing a backend-origin HTTP request to the loopback or private target.
5. Exfiltrate internal data: The response from the internal service (e.g., cloud metadata at 169.254.169.254, internal admin APIs) is processed by the server, potentially exposing credentials, tokens, or sensitive configuration data (GitHub Advisory, FrontMCP Advisory).

• Network: Outbound HTTP requests from the FrontMCP server process to 127.0.0.1, ::1, or private IP ranges (10.x, 172.16–31.x, 192.168.x) on unexpected ports; DNS lookups for hostnames like 127.0.0.1.nip.io or similar wildcard DNS-to-loopback services from the server.
• Logs: FrontMCP or Node.js application logs showing OpenAPIToolGenerator.fromURL() or fromJSON() calls with external $ref URLs containing nip.io, xip.io, IPv6-mapped addresses (::ffff:), or redirect chains; HTTP access logs on internal services showing requests with Host headers matching bypass patterns.
• Process: Unexpected outbound connections initiated by the Node.js FrontMCP process to loopback or private addresses during OpenAPI adapter loading or tool generation phases.

Upgrade to the patched versions: frontmcp and @frontmcp/adapters >= 1.5.0, and mcp-from-openapi >= 2.5.0. As an immediate workaround, set refResolution.allowedProtocols: [] in the OpenAPI adapter configuration to prevent external $ref resolution entirely. Restrict OpenAPI adapter configuration to trusted administrators only in multi-user deployments to reduce the attack surface. The advisory recommends that the fix implement pre-request hostname resolution with IP range validation, redirect revalidation, IPv4-mapped IPv6 normalization, and connect-time IP pinning rather than relying on hostname string denylist checks (GitHub Advisory, FrontMCP Advisory).