mcp-from-openapi EUVD-2026-108958

Exploitation requires the caller to pass credential headers (Authorization and/or Cookie) to fromURL(); followRedirects defaults to true in the affected code. The attacker must control the spec host or abuse an open redirect on it so that the spec request is redirected to an attacker-controlled origin, at which point the manual redirect loop in safeFetch() re-sends the caller's headers unchanged. Limiting factors: if no credential headers are supplied to fromURL(), or if followRedirects is set to false, no credentials leak; the impact is bounded to the single token/cookie the caller provided (higher only if that token is high-privilege). The bundled CWE-183 blockedHosts trailing-dot bypass additionally requires an operator who relies on blockedHosts. The fix in 2.9.0 drops all caller headers on any cross-origin hop (and on https→http downgrade), which is the vendor-stated complete remedy alongside loading the final URL directly or setting followRedirects:false.

This is a medium-severity, confidentiality-only credential-leak flaw (CWE-522) rated CVSS 4.0 6.3 by the vendor (AV:N/AC:L/AT:P/PR:N/UI:N/VC:L only). The vector's AT:P correctly signals that exploitation is not unconditional: it depends on a specific attack requirement - the caller must have supplied credential headers to fromURL() and the attacker must control the spec host or abuse an open redirect on it. No EPSS score was provided and the CVE is NOT in CISA KEV, so there is no signal of active or widespread exploitation. The vuln.today decision label is 'this_month' (not act_now/emergency), consistent with a real-but-not-urgent issue. The reporting researcher (VulnCheck) independently scored the core issue CVSS 3.1 3.7 (AC:H), emphasizing the precondition that the caller must pass headers - this aligns with the vendor's AT:P. Net: a genuine credential-exposure bug worth patching this month, but the real-world risk is moderated by the dual precondition (caller passes headers AND attacker controls/redirects the spec origin) and the impact ceiling of a single low-privilege token/cookie unless high-privilege tokens are in use. No conflicting severity signals; the main uncertainty is exploitation likelihood, as no EPSS/KEV data is available.

An attacker who controls the spec host (or finds an open redirect on it) configures it to redirect the legitimate spec URL to an attacker-owned origin. When a developer or service loads that private spec via fromURL() with an Authorization bearer token or Cookie header, safeFetch() follows the cross-origin redirect and re-sends those headers to the attacker's origin, leaking the credential. The reporter (VulnCheck) demonstrated the token reaching the second origin with a private PoC confirmed by execution; no public exploit code is published, and reproduction detail appears only in the vendor advisory and fix tests.