- Sources: advisory GHSA-8q49-2h5h-434x, FrontMCP v1.5.6 release
- Summary: An advisory published 2026-07-24 reports that FrontMCP's OpenAPI adapter guarded the initial spec load through
safeFetch but let its spec-change poller re-fetch the same URL on a timer using the raw global fetch. None of the guard's protections applied to the polled request: no allow-list or block-list enforcement, no blocking of private, loopback, link-local, CGNAT or cloud-metadata addresses, no DNS resolution of the hostname so a name resolving to an internal address was reached, no pinning to the validated IP against DNS rebinding, and no per-hop revalidation of redirects. Exploitation requires both that polling is enabled, which is off by default and needs the URL-based option, and that the spec URL is untrusted or attacker-influenceable. The poller issues GET requests only, so the advisory puts the primary impact on confidentiality, including reading cloud-instance metadata endpoints and probing internal services. It is rated medium at CVSS 3.1 5.9 under CWE-918. Affected versions are 1.5.5 and below of @frontmcp/adapters, and 1.5.6 routes the poller through the same guard with the same policy. No CVE identifier is listed. - Why it matters: A guarded fetch that a background refresh path bypasses is a recurring shape in server-side request forgery, and here the bypassed path runs on a timer against an operator-supplied URL.
- Follow-up: Watch for a CVE assignment and for whether other MCP adapters expose the same poller path.
send feedback on this story