FrontMCP's SSRF patch still lets requests reach loopback

FrontMCP patched a server-side request forgery bug, CVE-2026-39885, by adding a hostname denylist to OpenAPI spec imports. The block was meant to stop external $ref pointers from dereferencing into internal addresses. That block has a new CVE of its own, CVE-2026-59973, covering the bypass. An SSRF filter exists to stop untrusted specs from making the server fetch its own network, and this one still lets that request through.

The underlying dependency, mcp-from-openapi 2.3.0, is still pinned in FrontMCP 1.2.1 and in the project's current main branch, per the GHSA-65h7-9wrw-629c advisory. Both OpenAPIToolGenerator.fromURL() and .fromJSON() take a url or spec argument straight from the caller and pass it into that same resolution path.

A direct 127.0.0.1 in a $ref gets caught by the denylist. localhost doesn't. Neither does a DNS name that resolves to loopback, a redirect chain that ends there, or an IPv4 address written in IPv6-mapped notation. Blocking one spelling of an address doesn't block the address.

The advisory doesn't say whether a config flag can turn off external OpenAPI imports as a stopgap. Anyone running FrontMCP with that feature enabled stays exposed until the maintainers ship a fix that checks the resolved address instead of the hostname text.