CVE-2026-59973: High-Severity Server-Side Request Forgery in FrontMCP and mcp-from-openapi

FrontMCP is a TypeScript framework that exposes external tools and data resources to artificial intelligence models via the Model Context Protocol (MCP). The platform relies on OpenAPI schemas to dynamically generate client and tool interfaces. To ingest these schemas, FrontMCP implements an adapter framework that loads and parses specifications directly from external web resources or dereferences internal $ref schema definitions. The underlying parsing tasks are delegated to the library mcp-from-openapi.

The attack surface exists in any multi-user deployment where authenticated users can import or register external OpenAPI specifications. Because these specifications frequently contain schema references located on arbitrary remote hosts, the system must perform network fetches to complete the dereferencing process. An attacker can manipulate these remote requests, routing them toward restricted network resources or private endpoints.

This behavior matches the pattern of a Server-Side Request Forgery (SSRF) vulnerability, classified as CWE-918. The earlier mitigation strategy implemented a simple string-based denylist against hostnames, which failed to address fundamental network resolution realities. Consequently, an attacker can bypass the filters, triggering network operations on behalf of the FrontMCP container to probe and exploit the internal ecosystem.

The underlying security flaw resides in the validation design of the HTTP resolver. The logic historically evaluated the literal hostname extracted from the $ref URL before conducting any DNS lookup or network negotiation. This approach assumes that a domain name resolves exclusively to its literal string representation and ignores the standard behavior of the operating system DNS client.

Because the HTTP client resolves domain names to IP addresses directly at the socket level, several specific techniques can bypass the string filter. For example, wildcard DNS systems such as nip.io map arbitrary subdomains to designated IP addresses. If an attacker passes 127.0.0.1.nip.io, the string parser evaluates it as a public domain and permits the request, while the DNS resolution step maps the target directly to the local loopback interface.

HTTP redirects introduce a secondary bypass vector. The validator assesses the original URL, confirms that it points to an allowed public resource, and starts the HTTP request. If the target server responds with an HTTP redirect status (e.g., 302 Found) pointing to an internal resource, the client follows the redirect automatically. The internal validation routine is bypassed because the redirect occurs within the client runtime without re-triggering the resolver's boundary checks.

IPv4-mapped IPv6 representations are also a factor. Standard regex pattern matching often fails to normalize variations such as [::ffff:127.0.0.1] or hexadecimal variants like [::ffff:7f00:1]. These variants resolve directly to local interfaces while bypassing standard string filters. Additionally, the main endpoint loader fromURL lacked any validation, making the initial specification retrieval process entirely vulnerable.

The following diagram illustrates the vulnerable validation flow where the security checks are decoupled from the physical connection target:

The vulnerability is addressed in the be3409cce6e97642696d4ee5a4e4e2712490b277 commit for mcp-from-openapi and the 96a78eaa5c6c4bc51cced557d83d1a03344cb03d commit for frontmcp. Below is the essential implementation of the new, secure validation loop within the updated src/ssrf.ts module:

// Secure validation resolves DNS and checks IP ranges recursively
export async function assertUrlSafe(
  url: string,
  ssrf: ResolvedSsrfOptions,
  lookup: SsrfHostLookup = defaultLookup,
): Promise<void> {
  let parsed: URL;
  try {
    parsed = new URL(url);
  } catch {
    throw new SsrfError(`Invalid spec URL: ${url}`, { url });
  }
 
  const protocol = parsed.protocol.replace(/:$/, '');
  if (protocol !== 'http' && protocol !== 'https') {
    throw new SsrfError(`Protocol "${protocol}" is not allowed`, { url });
  }
 
  const hostname = parsed.hostname;
  if (!isIpLiteral(hostname)) {
    let addresses: ResolvedAddress[];
    try {
      addresses = await lookup(hostname);
    } catch {
      return;
    }
    for (const { address } of addresses) {
      if (isBlockedAddress(address)) {
        throw new SsrfError(`Host "${hostname}" resolves to blocked address ${address}`, { url });
      }
    }
  }
}

Furthermore, the patch implements a manual redirection handler safeFetch that prevents the Node runtime from automatically resolving HTTP redirects. By using redirect: 'manual', the application can intercept the target location and run it through the same resolution validation loop:

// Manual redirect loop to enforce SSRF validation at every hop
const isRedirect = status >= 300 && status < 400 && status !== 304;
if (isRedirect && followRedirects) {
  const location = response.headers?.get?.('location');
  if (location) {
    current = new URL(location, current).toString();
    // Recalculates and validates the target on the next loop iteration
  }
}

Exploitation of CVE-2026-59973 requires the ability to register or update an OpenAPI adapter in FrontMCP. This action is typical for authenticated users or administrators configuring integration services. The target platform must have network connectivity to the internet to perform DNS lookups and initial fetches from the external specification sources.

An attacker begins by identifying an internal administrative endpoint or metadata service. For instance, in AWS environments, the Instance Metadata Service (IMDSv1/v2) resides at the link-local address 169.254.169.254. The attacker hosts an OpenAPI schema on a public server that includes an external $ref pointing to a wildcard DNS domain such as http://169.254.169.254.nip.io/latest/meta-data/.

When the system attempts to resolve the external schema, the hostname bypasses the string validation rules. The DNS client resolves the address to the link-local IP, forcing the server to retrieve local AWS metadata credentials. The response containing the AWS credentials is then processed as part of the schema compilation, exposing sensitive data to the attacker.

Alternatively, an attacker can use a redirect server to dynamically transition the request from a public URL to an internal port. The initial validation registers a safe public domain, but the subsequent HTTP redirect targets local loopback addresses (e.g., http://127.0.0.1:8080/admin). This exposes internal microservices that lack separate authentication layers.

The direct impact of successful exploitation is complete or partial compromise of local and internal services. Since the FrontMCP container acts as the initiator of the requests, it possesses the network privileges assigned to its hosting environment. Attackers can leverage this position to access internal APIs, administrative interfaces, and local processes.

The CVSS v3.1 score is evaluated at 8.5 (High), with a vector of CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N. The scope change parameter (S:C) is critical, reflecting that the vulnerability allows the attacker to transition from the application layer of FrontMCP to the underlying network infrastructure. Confidentiality impact is high because arbitrary internal data can be read, while integrity is rated low as arbitrary write operations can sometimes be executed on target endpoints.

In cloud-native environments, the impact is elevated due to the presence of metadata endpoints (IMDS). Gaining access to AWS, GCP, or Azure metadata can result in the leak of temporary IAM credentials, leading to broader lateral movement across the cloud infrastructure.

The primary remediation action is upgrading FrontMCP to version 1.5.0 or higher, which forces mcp-from-openapi to version 2.5.0 or higher. These updates contain the secure-by-default configuration and DNS-resolved filtering capabilities. Administrators must verify their dependency lockfiles to ensure that vulnerable versions of mcp-from-openapi are not cached.

If immediate patching is not possible, several mitigations can protect the system. First, disable external $ref resolution entirely. This can be configured by passing an empty array to allowedProtocols in the OpenAPI adapter options. This stops the server from establishing any outgoing connections during the schema parsing process.

// Workaround: Block all external schema loading
OpenapiAdapter.init({
  name: 'secured-api',
  url: 'https://api.externalpartner.com/openapi.json',
  loadOptions: {
    followRedirects: false,
    refResolution: {
      allowedProtocols: []
    }
  }
});

Second, configure network-level egress controls (firewalls or security groups) to block the FrontMCP runtime from communicating with internal subnets, RFC 1918 address space, loopback interfaces, or cloud metadata endpoints. This network isolation acts as a defense-in-depth barrier against any residual TOCTOU exploits.