GHSA-8q49-2h5h-434x

## Summary 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: ```ts // libs/adapters/src/openapi/openapi.adapter.ts — initializeGenerator() return await OpenAPIToolGenerator.fromURL(this.options.url, { // ... followRedirects: this.options.loadOptions?.followRedirects ?? false, refResolution, // secure default: external $refs off, internal targets blocked }); ``` But the poller — which re-fetches **the same URL** on every interval — did not: ```ts // libs/adapters/src/openapi/openapi-spec-poller.ts — doFetch() (vulnerable, <= 1.5.5) const controller = new AbortController(); const timeout = setTimeout(() => controller.abort(), this.fetchTimeoutMs); try { const response = await fetch(this.url, { // <-- raw global fetch, no SSRF guard headers, signal: controller.signal, }); // ...hash the body, fire onChanged... } ``` 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 internal/private/loopback/link-local/CGNAT/cloud-metadata IP blocking; - no DNS resolution of the hostname (so a DNS name that resolves to an internal IP, e.g. `http://127.0.0.1.nip.io/`, was reached); - no connection **pinning** to the validated IP (DNS-rebinding TOCTOU); -