CVE-2026-8355 in ContextForge MCP Gateway
Summary
by MITRE • 10/20/2026
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 oauth_config.token_url parameter. When registering a gateway with OAuth client credentials authentication, an attacker can supply a malicious token_url 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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/20/2026
IBM ContextForge MCP Gateway versions ranging from 0.1.0 through 1.0.5 contain a critical server-side request forgery vulnerability within its OAuth-enabled gateway registration mechanism. This flaw allows authenticated users who possess the privilege to create gateways to manipulate internal network resources and access sensitive cloud metadata endpoints. The root cause of this vulnerability lies in the insufficient validation of the oauth_config.token_url parameter during the authentication configuration process. When an administrator or authorized user registers a new gateway using OAuth client credentials, the system is designed to exchange client secrets for access tokens by posting form-encoded credentials to the specified token URL. However, the application fails to enforce strict allowlists or perform adequate destination validation on this specific endpoint, creating a direct vector for server-side request forgery attacks that bypass existing security controls applied to other gateway configuration fields such as the primary gateway.url parameter.
The operational impact of this vulnerability is severe due to its ability to interact with internal infrastructure and cloud provider metadata services. An attacker can craft a malicious token_url pointing towards localhost-bound services, internal API endpoints, or well-known cloud metadata addresses including AWS Instance Metadata Service version one (IMDSv1), Google Cloud Platform metadata server, and Azure managed identity endpoints. Upon receiving the registration request, the vulnerable application immediately initiates an HTTP POST request to the attacker-controlled destination, transmitting sensitive client credentials in the body of the request. This behavior effectively turns the gateway service into a proxy that can be abused to pivot attacks against internal systems or exfiltrate cloud instance metadata, which often contains temporary security tokens and configuration details necessary for further compromise of the underlying infrastructure.
A significant aspect of this vulnerability is its data leakage potential through error handling mechanisms. If the malicious endpoint returns a response that cannot be parsed as a valid OAuth token response, the application does not silently fail but instead reflects up to 256 characters of the response body back to the attacker within an HTTP 502 Bad Gateway error message. This blind SSRF variant with data exfiltration capability allows attackers to read sensitive information from internal services that would otherwise be inaccessible from external networks. The reflection of even a small portion of the response can reveal service versions, internal IP addresses, or partial authentication tokens, providing valuable intelligence for subsequent stages of an attack chain such as privilege escalation or lateral movement within the network environment.
From a classification perspective, this vulnerability aligns with CWE-918 Server-Side Request Forgery and specifically relates to CWE-643 Improper Mitigation of SSRF Vulnerability in REST API due to insufficient validation of user-controlled input used for server-side requests. In terms of offensive security frameworks, the exploitation technique maps to ATT&CK T1572 Protocol Tunneling as it leverages legitimate application protocols to establish a covert channel to internal resources, and potentially ATT&CK T1098.004 SSH Authorized Keys if cloud metadata is used to deploy keys for persistent access. The vulnerability highlights a common architectural flaw where security controls are applied inconsistently across different configuration parameters within the same service module.
To mitigate this risk, organizations should immediately upgrade IBM ContextForge MCP Gateway to version 1.0.6 or later, which addresses these validation deficiencies. In environments where upgrading is not immediately feasible, network-level mitigations such as implementing strict egress filtering rules can help restrict outbound connections from the gateway host to only known and necessary external endpoints. Additionally, enforcing IMDSv2 on AWS instances by requiring session tokens for metadata access renders the exploitation of cloud metadata endpoints significantly more difficult, although it does not fully eliminate the risk if other internal services are targeted. Security teams should also audit existing gateway configurations to ensure that no malicious token_url entries have been persisted in the system database and review logs for any unauthorized registration attempts or unusual outbound traffic patterns originating from the ContextForge service account.