IBM ContextForge: one header overrides the MCP gateway's credentials

01What happened

IBM published security bulletins for IBM ContextForge MCP Gateway on November 12 and 13, 2026, and GitHub listed eight of the resulting CVEs on November 14. Wolfgang Kriesel reported the two flaws IBM rates High, CVE-2026-110279 and CVE-2026-110278. IBM shipped the fixes in v1.1.1, released on November 10.

02How it works

The gateway always renames an incoming X-Upstream-Authorization request header to Authorization before it calls an upstream MCP server, so a caller's header replaces the credential the gateway holds. IBM says OAuth authorization_code and client_credentials gateways are affected, along with bearer and basic ones. The second High flaw, CVE-2026-110278, ignores the per-server identity propagation setting during tool calls and resource reads, so a server configured not to receive user identity still gets the caller's user ID, email, groups and teams.

03Who is affected

Both High flaws reach v1.0.0 through v1.1.0, so the current 1.1.0 release is exposed as well as the whole 1.0 line. The other CVEs, listed below, stop at v1.0.11, apart from the jq filter denial of service. Gateways fronting several tenants or several upstream MCP servers lose the most to a credential swap, because per-user permission checks and audit attribution both rest on which credential is used.

04What to do

Upgrade to IBM ContextForge MCP Gateway v1.1.1. Until then, IBM suggests stripping the X-Upstream-Authorization header at the reverse proxy in front of the MCP endpoints and setting IDENTITY_PROPAGATION_ENABLED=false to stop identity forwarding to upstream servers.

Questions people ask

Which IBM ContextForge versions does CVE-2026-110279 affect?

CVE-2026-110279 affects IBM ContextForge MCP Gateway v1.0.0 through v1.1.0, so the newest 1.1.0 release is vulnerable along with the entire 1.0 line. IBM fixed the flaw in v1.1.1 through pull request 7341 in the mcp-context-forge repository. Most of the other CVEs published alongside it stop at v1.0.11.

Can an unauthenticated attacker use the ContextForge credential override?

No. IBM scores CVE-2026-110279 with privileges required set to low, so the caller needs an authenticated session on the gateway. The value of the flaw is lateral rather than external: a user who should only reach their own upstream servers can present a different credential, which bypasses per-user permission checks and makes audit records name the wrong identity.

How do I stop ContextForge leaking user identity without upgrading?

Set IDENTITY_PROPAGATION_ENABLED=false on the gateway. IBM gives that as the workaround for CVE-2026-110278, and it halts identity forwarding to every upstream MCP server instead of relying on the per-server switch the flaw ignores. IBM also advises restricting gateway access to trusted users, and says upgrading to v1.1.1 is the better answer.

Are all eight ContextForge CVEs fixed in the same release?

Not quite. IBM points the two High flaws and the jq filter denial of service, which all reach v1.1.0, at v1.1.1. The bulletins for the CVEs that stop at v1.0.11, including the server-side request forgery and the bulk import access control flaw, tell operators to install v1.1.0. Upgrading straight to v1.1.1 covers every case.

Sources 4 links, all fetched

1. 1ibm.comIBM: CVE-2026-110279
2. 2ibm.comIBM: CVE-2026-110278
3. 3github.comGitHub Advisory
4. 4github.comRelease v1.1.1