Updated November 14, 2026. Lab run on Linux with Python 3.12: mcp-contextforge-gateway 1.0.11 and 1.1.1 installed from PyPI, each pointed at a local capture server, with an authorization-server metadata document we controlled.
The ContextForge MCP Gateway SSRF flaw, tracked as CVE-2026-110194, is fixed in release 1.1.0: in affected versions the gateway’s OAuth Dynamic Client Registration sent requests to endpoints an outsider chose. IBM ContextForge MCP Gateway is an open source gateway that sits in front of Model Context Protocol (MCP), A2A, and REST servers and gives agents one endpoint with centralized discovery, access control, and OAuth. The project has 4,815 GitHub stars and its PyPI package recorded 38,929 downloads in the last month, checked November 14, 2026. IBM rates the issue Moderate, CVSS 5.4.
Upgrading to ContextForge MCP Gateway 1.1.0 or later closes the hole: in our November 14 lab, version 1.0.11 sent a Dynamic Client Registration request to any endpoint an authorization server named, including a blocked loopback address, and 1.1.1 refused every out-of-origin target. An authenticated user who can register or modify a gateway is the one who triggers it, so review who holds that permission before you decide how fast to patch.
TL;DR
- CVE-2026-110194 is a server-side request forgery flaw in ContextForge MCP Gateway 1.0.0 through 1.0.11, rated Moderate (CVSS 5.4) by IBM and published on November 13, 2026.
- The gateway reads a
registration_endpointfrom an authorization server’s metadata and POSTs client registration to it. Affected versions skipped the gateway’s own SSRF checks on that request. - In our lab, 1.0.11 POSTed the registration to a loopback endpoint the SSRF blocklist should block, and to an endpoint on a different origin than the issuer. Version 1.1.1 refused both.
- The fix landed in 1.1.0 on October 20, 2026, roughly three weeks before the CVE was published, so a deployment already on 1.1.0 or 1.1.1 is not affected.
- If you cannot upgrade, IBM says to disable Dynamic Client Registration with
MCPGATEWAY_DCR_ENABLED=falseor setDCR_ALLOWED_ISSUERS, and limit who can register gateways.
What CVE-2026-110194 Is in ContextForge MCP Gateway
CVE-2026-110194 is a server-side request forgery flaw in ContextForge MCP Gateway versions 1.0.0 through 1.0.11. IBM published it on November 13, 2026 with a CVSS 3.1 base score of 5.4 (Moderate) and classifies it as CWE-918. An authenticated user can make the gateway send requests to internal hosts it should not reach.
The gateway’s CVSS vector, AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N, says the attack is over the network, needs low privileges, and needs no user interaction. The GitHub Advisory Database mirrored the record on November 14, 2026 as GHSA-vwg6-jvc2-rpch, Moderate, with no package named. IBM is the CVE numbering authority here, and NVD lists the entry as awaiting its own enrichment.
How the Dynamic Client Registration Path Leaks Requests
The leak sits in Dynamic Client Registration, the RFC 7591 flow where the gateway registers itself as an OAuth client. The gateway fetches an authorization server’s metadata document, reads the registration_endpoint URL from it, and sends an HTTP POST there. In the affected versions, that outbound POST never passed through the gateway’s SSRF protection.
ContextForge ships an SSRF layer that blocks cloud metadata ranges such as 169.254.169.254 and, by default, loopback and private networks. The DCR service in mcpgateway/services/dcr_service.py predated that protection and called its own HTTP client directly. A metadata document could therefore name any registration_endpoint, and the gateway would POST to it.
The condition that makes this reachable is an attacker-influenced issuer. A low-privilege authenticated user who can register or modify a gateway sets its OAuth issuer, and when that gateway has an issuer but no client ID, ContextForge auto-triggers DCR. The user points the issuer at a metadata document they control, and the document’s registration endpoint aims the gateway’s request at an internal address, which is the network enumeration IBM describes.
What We Found Testing 1.0.11 Against the Fix
We installed ContextForge MCP Gateway 1.0.11 and 1.1.1 from PyPI and ran the DCR service against a local server that published metadata we controlled. Each case named a registration endpoint in that metadata and recorded whether the gateway POSTed to it. The affected build leaked in both abuse cases; the fixed build refused both and completed a legitimate registration.
In case A, the metadata named a registration endpoint on a loopback address that ContextForge’s SSRF blocklist is meant to block, with the default policy in place. Version 1.0.11 POSTed the registration there anyway. Version 1.1.1 stopped with the error “AS metadata discovery URL blocked by URL policy” and sent nothing.
Case B isolated the second half of the fix. With loopback addresses allowed, the metadata named a registration endpoint on a different origin than the issuer. Version 1.0.11 POSTed to the off-origin host, while 1.1.1 refused with “DCR registration_endpoint must share the issuer origin”. Case C kept the registration endpoint on the issuer’s own origin, and both versions completed it, so the patch does not break a correctly configured authorization server.
Why the Fix Shipped Three Weeks Before the CVE
The patch was public well before the CVE. The DCR validation landed in pull request #6961, merged September 29, 2026, and the live SSRF tests in pull request #7081, merged October 8. Both shipped in release 1.1.0 on October 20, 2026, so the fix predates the November 13 CVE publication by more than three weeks.
The fix adds a helper, DcrService._prepare_pinned_request(), that every outbound DCR call now routes through: metadata discovery, client registration, and the registration update and delete requests. It checks that the target shares the configured issuer’s origin, runs the gateway’s URL policy, and pins the connection to the address resolved during validation so a later DNS answer cannot redirect it.
One detail is worth flagging for anyone cross-referencing advisories. IBM published two bulletins: the SSRF bulletin that carries CVE-2026-110194, and an earlier Dynamic Client Registration bulletin whose page shows the identifier CVE-2026-17148 alongside a description that names Langflow, which reads as a copy-paste error in IBM’s template rather than a second product. Match the fix to the gateway version, not to the identifier on a single page.
Who Is Exposed and What to Do Now
You are exposed if you run ContextForge MCP Gateway 1.0.11 or earlier, run Dynamic Client Registration, which is on by default, and allow users who are not fully trusted to register or modify gateways. A deployment already on 1.1.0 or 1.1.1 carries the fix. The clean path is to upgrade, then review who can create gateways.
- Upgrade the package to a fixed release:
pip install -U mcp-contextforge-gatewaybrings in 1.1.0 or later. Confirm the running version before you move on. - If you cannot upgrade immediately, set
MCPGATEWAY_DCR_ENABLED=falseto turn off Dynamic Client Registration, or setDCR_ALLOWED_ISSUERSto an allowlist of trusted issuer origins. IBM notes these reduce exposure but do not patch the underlying bypass. - Restrict the permission to register or modify gateways to trusted accounts, since that permission is what lets a user choose the issuer.
- Review gateway registrations and logs from the period an affected version ran for issuers or endpoints you did not intend, and treat any request that reached an internal address as worth investigating.
Rotate credentials only when your log review cannot rule out that the gateway reached a sensitive internal service such as a cloud metadata endpoint. The CVSS confidentiality and integrity impacts are rated Low, so this is an enumeration and pivot primitive rather than a direct secret dump, but a reachable metadata endpoint changes that calculation.
Where This Fits in MCP Gateway Security
MCP routing bugs keep sending requests to hosts an outsider chose. The mcp-go redirect vulnerability sent a refresh token to another host, and here the gateway sends an OAuth registration to an internal one. A gateway sits in front of many servers, so this control-plane SSRF reaches further than it would in one client.
If you are choosing or hardening a gateway, our MCP gateways guide compares the main options, and the LLM gateways guide covers the model-routing layer that often sits alongside them. For related MCP server flaws this month, see our writeups on the mcp-server-git command execution bug and the AgentScope MCP workspace RCE. Keeping provider and machine credentials out of reach is the broader job our non-human identity tools guide covers.
FAQ
Which ContextForge MCP Gateway versions are affected by CVE-2026-110194?
Versions 1.0.0 through 1.0.11 are affected, according to IBM’s security bulletin and the NVD record published November 13, 2026. The fix shipped in release 1.1.0 on October 20, 2026. Our lab confirmed the leak on 1.0.11 and saw no out-of-origin request from 1.1.1.
How severe is the ContextForge MCP Gateway SSRF?
IBM rates CVE-2026-110194 Moderate, with a CVSS 3.1 base score of 5.4 and confidentiality and integrity impacts of Low. It needs an authenticated, low-privilege user. The practical risk is internal network enumeration and reaching blocked hosts such as cloud metadata endpoints, not a direct data dump.
Do I need to upgrade if I am already on version 1.1.0 or 1.1.1?
No. The DCR validation and connection pinning that fix CVE-2026-110194 shipped in 1.1.0, released October 20, 2026, and carry through to 1.1.1. Only releases from 1.0.0 through 1.0.11 are affected. Confirm the running version, since the CVE was published after the fix.
What if I cannot upgrade ContextForge right away?
IBM recommends disabling Dynamic Client Registration with MCPGATEWAY_DCR_ENABLED=false, or restricting it with a DCR_ALLOWED_ISSUERS allowlist, and limiting who can register gateways. IBM states these mitigations reduce exposure but do not patch the underlying SSRF bypass, so upgrading to 1.1.0 or later remains the real fix.