Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The published fix for GHSA-v6ph-xcq9-qxxj / CVE-2026-39885 added a direct hostname denylist for OpenAPI external $ref dereferencing, but the latest patched dependency mcp-from-openapi 2.3.0 still makes backend-origin requests to loopback when the target is reached through hostname resolution, redirects, or IPv4-mapped IPv6 syntax. FrontMCP latest release v1.2.1 and current main still call OpenAPIToolGenerator.fromURL() and OpenAPIToolGenerator.fromJSON() from mcp-from-openapi 2.3.0 when loading OpenAPI adapters. An attacker who can cause a hosted or multi-user FrontMCP deployment to load an untrusted OpenAPI spec can trigger requests from the server to localhost or private services during tool generation. This is a latest-version bypass of the previous fix. A direct http://127.0.0.1 $ref control is now denied and produces zero canary hits, while semantically equivalent loopback targets still reach the canary. Latest versions checked - frontmcp npm latest: 1.2.1 -…
Recommended action: Upgrade to 1.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The OpenAPI adapter's spec-change poller (OpenApiSpecPoller) re-fetched the configured spec url on a timer using a raw global fetch(), bypassing the SSRF guard (safeFetch / assertUrlSafe) that OpenAPIToolGenerator.fromURL() applies to the initial spec load. As a result, the pinning/DNS-resolution hardening delivered via mcp-from-openapi = 2.5.0 (advisory GHSA-65h7-9wrw-629c) protected the initial load but not the recurring poll of the same URL. When polling is enabled against an untrusted or attacker-influenceable spec URL, this is an unguarded SSRF vector. Details The initial spec load is guarded. OpenapiAdapter resolves a secure refResolution policy and passes it to the guarded loader: But the poller — which re-fetches the same URL on every interval — did not: Because doFetch() never called safeFetch, none of the guard's protections applied to the polled request: - no allow-list / block-list enforcement (allowedHosts / blockedHosts); - no…
Recommended action: Upgrade to 1.5.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The mcp-from-openapi library uses @apidevtools/json-schema-ref-parser to dereference $ref pointers in OpenAPI specifications without configuring any URL restrictions or custom resolvers. A malicious OpenAPI specification containing $ref values pointing to internal network addresses, cloud metadata endpoints, or local files will cause the library to fetch those resources during the initialize() call. This enables Server-Side Request Forgery (SSRF) and local file read attacks when processing untrusted OpenAPI specifications. Affected Versions <= 2.1.2 (latest) CWE CWE-918: Server-Side Request Forgery (SSRF) Vulnerability Details File: index.js lines 870-875 When OpenAPIToolGenerator.initialize() is called, it dereferences the OpenAPI document using json-schema-ref-parser: No options are passed to .dereference() — no URL allowlist, no custom resolvers, no protocol restrictions. The ref parser fetches any URL it encounters in $ref values, including: - http:// and https:// URLs…
Recommended action: Upgrade to 1.0.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.