ContextForge MCP Gateway EUVD-2026-104673

Requires an authenticated account with gateway-creation privileges (PR:L) and that the target gateway is being registered with OAuth client-credentials authentication - the attacker supplies a crafted oauth_config.token_url during OAuth-enabled gateway registration. Exploitation is NOT possible against the gateway.url field (which already has SSRF protections); it works specifically because those validations are not applied to OAuth configuration parameters. Limiting factors: valid credentials with gateway-creation rights are mandatory, the OAuth registration flow must be used, data return is constrained to ~256 characters reflected only when the response fails OAuth token parsing (so blind/limited exfiltration), and the request is a fixed form-encoded POST. Impact is maximized only where internal services or cloud metadata endpoints (notably AWS IMDSv1) are reachable from the gateway host.

This is a moderate-severity, low-priority issue that multiple signals agree should NOT be treated as an emergency. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N, base 5.4) requires an authenticated attacker who already holds gateway-creation privileges (PR:L), which substantially narrows the viable attacker population to trusted/semi-trusted insiders or accounts that have been compromised. EPSS is very low at 0.18% (7th percentile), and CISA SSVC scores Exploitation=none, Automatable=no, Technical Impact=partial - all consistent with a flaw that is real but not opportunistically scannable or wormable. There is no KEV listing and no public exploit identified, so there is no evidence of active exploitation. These signals are mutually consistent (low EPSS + SSVC none + no KEV + PR:L), so there is no conflict to flag. The genuine concern that elevates this above a trivial finding is the SSRF reach to cloud metadata endpoints (AWS IMDSv1, GCP, Azure): a successful hit against IMDSv1 could expose IAM/role credentials, but exploitation is constrained because only up to 256 characters of a non-OAuth-parseable response are reflected in the 502 error, and the request is a POST with form-encoded credentials rather than a flexible GET - limiting blind data exfiltration. Net: prioritize patching on internet-exposed or multi-tenant deployments, but this does not warrant out-of-band emergency response.

An authenticated user with gateway-creation rights registers a new OAuth-enabled gateway and sets oauth_config.token_url to a malicious internal URL such as http://169.254.169.254/latest/meta-data/iam/security-credentials/ (AWS IMDSv1) or an internal admin service. The gateway immediately issues an HTTP POST to that URL, and if the response is not a valid OAuth token it reflects up to 256 characters of the body back in a 502 error, letting the attacker probe internal services and potentially harvest cloud metadata. No public exploit code has been identified at time of analysis.