CVE-2026-8355: IBM ContextForge MCP Gateway is affected by server-side request forgery
IBM ContextForge MCP Gateway 0.1.0 through 1.0.5 is vulnerable to a server-side request Forgery (SSRF) that allows authenticated users with gateway creation privileges to perform arbitrary HTTP POST requests to internal network resources and cloud metadata endpoints. The vulnerability occurs during OAuth-enabled gateway registration when the system fails to validate the oauthconfig.tokenurl parameter. When registering a gateway with OAuth client credentials authentication, an attacker can supply a malicious tokenurl pointing to internal services, cloud metadata endpoints (AWS IMDSv1, GCP, Azure), or localhost-bound services. The application immediately performs an HTTP POST request to the attacker-controlled URL with form-encoded credentials in the body. If the response cannot be parsed as a valid OAuth token response, up to 256 characters of the response body are reflected back to the attacker in the HTTP 502 error message. This vulnerability bypasses existing SSRF protections that are applied to the gateway.url field but not to OAuth configuration parameters.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
IBM ContextForge MCP Gatewayto a version that resolves this vulnerability.Fixed in 1.0.6
Event History
Frequently Asked Questions
What level of access does an attacker need?
An attacker must be authenticated and have privileges to create gateways. Exploitation occurs when they register a gateway using OAuth client credentials and control the oauth_config.token_url value.
Which requests can be induced, and what data may be exposed?
The gateway can be induced to make arbitrary HTTP POST requests to internal resources, cloud metadata endpoints, or localhost-bound services. The POST body contains form-encoded OAuth client credentials, and up to 256 characters of an unparsable response body may be returned in an HTTP 502 error.
Does existing SSRF protection prevent this attack?
No. The existing protections apply to the gateway.url field, while this issue is in the OAuth configuration token_url parameter.
What can be restricted while a remediation is being planned?
Limit gateway-creation privileges to trusted users and restrict OAuth-enabled gateway registrations that use untrusted token_url values. This directly reduces the access needed to trigger the vulnerable request path.