GHSA-8Q49-2H5H-434X: Server-Side Request Forgery in FrontMCP OpenAPI Spec Poller

FrontMCP is a TypeScript-first framework designed for the Model Context Protocol (MCP). The framework provides an OpenAPI adapter that allows users to register and consume remote OpenAPI specifications dynamically. During initialization, FrontMCP exposes an external attack surface by accepting remote specification URLs from configuration inputs or network requests.

While the framework implements a hardened wrapper (OpenAPIToolGenerator.fromURL()) for initial registration, background synchronization routines operate under a different security posture. A background poller (OpenApiSpecPoller) is configured to run on a periodic timer to check for changes to the OpenAPI specification files.

This background polling mechanism was identified as vulnerable to Server-Side Request Forgery (SSRF), classified under CWE-918. An attacker who is able to supply or influence the OpenAPI specification URL can bypass initial server constraints, forcing the hosting environment to make requests to arbitrary internal resources, including local networks, loopback interfaces, or cloud metadata endpoints.

The root cause of this vulnerability lies in an architectural inconsistency between the initial loading mechanism and the background update routines. During application initialization, the OpenAPI adapter validates remote resources using a secure fetch implementation from the mcp-from-openapi dependency. This safe helper resolves target hostnames to their underlying IP addresses, matches them against blocklists, and enforces socket pinning to prevent DNS rebinding attacks.

Conversely, the background update routine managed by the OpenApiSpecPoller component did not reuse this validated pipeline. Instead, the doFetch() method within OpenApiSpecPoller executed queries using Node's native global fetch() client. The native client executes HTTP transactions directly via the system network library without applying filtering or security wrappers.

Because the native fetch() client does not enforce routing controls, it fails to inspect intermediate redirect targets or validate target IP addresses post-resolution. Consequently, an attacker can pass initial registration checks using a benign host and then alter the host's resolution or response profile to target internal systems during background execution.

An inspection of the codebase prior to commit 077201e109bf6f45dbc85c36d6bd77ded18ab13e reveals the implementation gap in libs/adapters/src/openapi/openapi-spec-poller.ts. The un-patched version of the poller initialized HTTP requests without applying SSRF policies or carrying adapter configurations.

// Vulnerable code in openapi-spec-poller.ts
const controller = new AbortController();
const timeout = setTimeout(() => controller.abort(), this.fetchTimeoutMs);
 
try {
  const response = await fetch(this.url, {
    headers,
    signal: controller.signal,
  });
  // ...

The patch addresses this gap by importing and integrating safeFetch and normalizeSsrfOptions from the mcp-from-openapi library. The implementation now passes the ssrf options and the followRedirects configuration derived from the main adapter directly into the customized request client.

// Patched code in openapi-spec-poller.ts
const response = await safeFetch(this.url, {
  headers,
  timeoutMs: this.fetchTimeoutMs,
  followRedirects: this.followRedirects,
  ssrf: this.ssrf,
});

Additionally, openapi.adapter.ts was modified to propagate the server security policy down to the poller. The configuration parameters, including the ssrf options normalize function, are now properly populated during poller instantiation. This architectural change ensures that background validation rules align with the primary entrance verification rules.

An attacker can exploit this vulnerability using either an HTTP Redirect or a DNS Rebinding methodology. To initiate the attack, the adversary must register a custom, attacker-controlled URL as the OpenAPI specification source. The target URL is initially mapped to a valid, public OpenAPI document to satisfy the safe checks executed during the initial load.

In an HTTP Redirect scenario, the attacker configures the remote web server to respond to subsequent background polling cycles with an HTTP redirect status, such as a 302 Found. The Location header is set to target internal services, such as http://169.254.169.254/latest/meta-data/ on AWS environments. Because the un-patched poller follows redirects automatically, it queries the local metadata endpoint, returning the response content to the context of the poller execution context.

In a DNS Rebinding scenario, the attacker registers a domain name with a Time-To-Live (TTL) value of zero. The domain initially resolves to a public address during registration. On the next background polling interval, the host DNS record is updated to point to the local loopback address 127.0.0.1 or a private IP within the range 10.0.0.0/8. The standard fetch() call performs a fresh DNS query, resolves the domain to the internal address, and completes the request to the restricted resource.

The security impact of this vulnerability is significant, as it enables unauthenticated remote attackers to bypass network isolation boundaries. By coercing the host server to issue requests to internal networks, attackers can perform network port scanning, locate internal services, and interact with unauthenticated endpoints. This is highly critical in microservice environments where internal tools lack transport-level authentication.

In cloud environments, this flaw can lead to credential extraction from Instance Metadata Services (IMDSv1). An attacker capable of reading or influencing responses can obtain temporary IAM credentials, potentially resulting in complete compromise of the hosting cloud infrastructure.

The CVSS v3.1 score is evaluated at 8.6, with a high confidentiality impact and high availability impact due to the capability of querying arbitrary internal systems. No direct privileges are required to register adapters in insecure or exposed configurations, making the vulnerability highly operational.

The primary remediation strategy is to upgrade FrontMCP to version 1.5.6 or higher, which replaces vulnerable native fetch routines with the safeFetch package. Developers must verify that @frontmcp/sdk and @frontmcp/adapters are both updated in the project's dependency manifest.

When configuring the OpenAPI adapter, security administrators should ensure that allowInternalIPs remains disabled. By default, the patched version prevents requests to loopback, link-local, and RFC 1918 private network spaces. Access should only be expanded when connecting to verified internal services within isolated containerized environments.

Additionally, employing domain allowlists through the allowedHosts option is recommended to restrict outgoing specification polls to a strict list of domains. This minimizes the risk of DNS rebinding by ignoring unauthorized or dynamic DNS configurations provided by third parties.